Message ID | cover.1542291869.git.anatoly.burakov@intel.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 259124CB5; Thu, 15 Nov 2018 16:47:28 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 179894C95 for <dev@dpdk.org>; Thu, 15 Nov 2018 16:47:24 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2018 07:47:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,236,1539673200"; d="scan'208";a="249967027" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by orsmga004.jf.intel.com with ESMTP; 15 Nov 2018 07:47:21 -0800 Received: from sivswdev01.ir.intel.com (sivswdev01.ir.intel.com [10.237.217.45]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id wAFFlLWG024789; Thu, 15 Nov 2018 15:47:21 GMT Received: from sivswdev01.ir.intel.com (localhost [127.0.0.1]) by sivswdev01.ir.intel.com with ESMTP id wAFFlLu4028092; Thu, 15 Nov 2018 15:47:21 GMT Received: (from aburakov@localhost) by sivswdev01.ir.intel.com with LOCAL id wAFFlLDO028088; Thu, 15 Nov 2018 15:47:21 GMT From: Anatoly Burakov <anatoly.burakov@intel.com> To: dev@dpdk.org Cc: john.mcnamara@intel.com, bruce.richardson@intel.com, pablo.de.lara.guarch@intel.com, david.hunt@intel.com, mohammad.abdul.awal@intel.com, thomas@monjalon.net, ferruh.yigit@intel.com Date: Thu, 15 Nov 2018 15:47:12 +0000 Message-Id: <cover.1542291869.git.anatoly.burakov@intel.com> X-Mailer: git-send-email 1.7.0.7 In-Reply-To: <cover.1529940601.git.anatoly.burakov@intel.com> References: <cover.1529940601.git.anatoly.burakov@intel.com> Subject: [dpdk-dev] [RFC v2 0/9] Modularize and enhance DPDK Python scripts X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
Modularize and enhance DPDK Python scripts
|
|
Message
Anatoly Burakov
Nov. 15, 2018, 3:47 p.m. UTC
This patchset attempts to create a library out of Python scripts that come with DPDK, with a goal of enabling external tools to get the same information about the system DPDK has, and perhaps configure DPDK. Potential applications include: * Better setup.sh script (it's long overdue, and you know it!) * Easier development of better tools for developers (see hugepage-info example) * Easier gathering of DPDK-centric system information, has potential applications in troubleshooting tools * Reduce code duplication for internal (e.g. quickstart [1], setup.sh) and external tools seeking to use the same functionality * Add cross-platform support for our scripts (see cpu-layout example now working on FreeBSD) There are a few things to mention. First of all, it's an RFC, so the fact that it's unfinished and maybe awkward comes with the territory. I am also aware of the fact that it's a Python library, that it's outside the scope of DPDK and that it's somewhat a Not-Invented-Here kind of proposition where there are a lot of externally available (which are much better designed and implemented) tools that do the same thing. So the first question i would like to ask is, is the community at all interested in something like this? Does it have to be part of DPDK repository? Can it be maintained in a separate repository? How do we handle updates and dependencies? An alternative approach to something like this would be to acknowledge the fact that we cannot do everything on our own, and pull in additional dependencies (preferably automatically - this can be done through pip, everyone has it and it's not that hard!) instead of relying on hacky scripts we currently have. The point is - we do need better tooling, better setup scripts and better OS/machine logging/troubleshooting tools. I should also mention that it is *not* intended to be a replacement for udev or any other method of device binding - if anything, it's the opposite, in that it takes the whole issue out of the question and thus would make switching to udev or any other device binding easier since both internal and external tools can utilize the same Python API. [1] http://patches.dpdk.org/patch/47475/ RFC v2: - Rebased on latest 18.11 master (rc3) - Added compressdev support in DevInfo library Anatoly Burakov (9): usertools: add DPDK config lib python library usertools/lib: add platform info library usertools/cpu_layout: rewrite to use DPDKConfigLib usertools/lib: support FreeBSD for platform info usertools/lib: add device information library usertools/devbind: switch to using DPDKConfigLib usertools/lib: add hugepage information library usertools: add hugepage info script usertools/lib: add GRUB utility library for hugepage config usertools/DPDKConfigLib/DevInfo.py | 424 +++++++++++++++++++ usertools/DPDKConfigLib/DevUtil.py | 242 +++++++++++ usertools/DPDKConfigLib/GrubHugeUtil.py | 175 ++++++++ usertools/DPDKConfigLib/HugeUtil.py | 309 ++++++++++++++ usertools/DPDKConfigLib/PlatformInfo.py | 205 +++++++++ usertools/DPDKConfigLib/Util.py | 84 ++++ usertools/DPDKConfigLib/__init__.py | 0 usertools/cpu_layout.py | 53 +-- usertools/dpdk-devbind.py | 533 ++++-------------------- usertools/hugepage-info.py | 32 ++ 10 files changed, 1558 insertions(+), 499 deletions(-) create mode 100755 usertools/DPDKConfigLib/DevInfo.py create mode 100755 usertools/DPDKConfigLib/DevUtil.py create mode 100755 usertools/DPDKConfigLib/GrubHugeUtil.py create mode 100755 usertools/DPDKConfigLib/HugeUtil.py create mode 100755 usertools/DPDKConfigLib/PlatformInfo.py create mode 100755 usertools/DPDKConfigLib/Util.py create mode 100644 usertools/DPDKConfigLib/__init__.py create mode 100755 usertools/hugepage-info.py
Comments
This is a placeholder for Python library abstracting away many of
mundane details DPDK configuration scripts have to deal with. We
need __init__.py file to make the subdirectory a package so that
Python scripts in usertools/ can find their dependencies.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
usertools/DPDKConfigLib/__init__.py | 0
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 usertools/DPDKConfigLib/__init__.py
diff --git a/usertools/DPDKConfigLib/__init__.py b/usertools/DPDKConfigLib/__init__.py
new file mode 100644
index 000000000..e69de29bb
On Thu, 15 Nov 2018 15:47:13 +0000 Anatoly Burakov <anatoly.burakov@intel.com> wrote: > This is a placeholder for Python library abstracting away many of > mundane details DPDK configuration scripts have to deal with. We > need __init__.py file to make the subdirectory a package so that > Python scripts in usertools/ can find their dependencies. > > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> > --- > usertools/DPDKConfigLib/__init__.py | 0 > 1 file changed, 0 insertions(+), 0 deletions(-) > create mode 100644 usertools/DPDKConfigLib/__init__.py > > diff --git a/usertools/DPDKConfigLib/__init__.py b/usertools/DPDKConfigLib/__init__.py > new file mode 100644 > index 000000000..e69de29bb Doing this a better than current code, but can we go farther? I would like DPDK to get out of doing binds directly and switch to using driverctl which also handles persistent rebind on reboot.
On 16-Nov-18 12:45 AM, Stephen Hemminger wrote: > On Thu, 15 Nov 2018 15:47:13 +0000 > Anatoly Burakov <anatoly.burakov@intel.com> wrote: > >> This is a placeholder for Python library abstracting away many of >> mundane details DPDK configuration scripts have to deal with. We >> need __init__.py file to make the subdirectory a package so that >> Python scripts in usertools/ can find their dependencies. >> >> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> >> --- >> usertools/DPDKConfigLib/__init__.py | 0 >> 1 file changed, 0 insertions(+), 0 deletions(-) >> create mode 100644 usertools/DPDKConfigLib/__init__.py >> >> diff --git a/usertools/DPDKConfigLib/__init__.py b/usertools/DPDKConfigLib/__init__.py >> new file mode 100644 >> index 000000000..e69de29bb > > Doing this a better than current code, but can we go farther? > > I would like DPDK to get out of doing binds directly and switch to using driverctl > which also handles persistent rebind on reboot. > Wasn't the objection that it's not available everywhere? (for the record, i have no horse in the race - i don't much care exactly how it's done)
> On Nov 16, 2018, at 5:49 AM, Burakov, Anatoly <anatoly.burakov@intel.com> wrote: > > On 16-Nov-18 12:45 AM, Stephen Hemminger wrote: >> On Thu, 15 Nov 2018 15:47:13 +0000 >> Anatoly Burakov <anatoly.burakov@intel.com> wrote: >>> This is a placeholder for Python library abstracting away many of >>> mundane details DPDK configuration scripts have to deal with. We >>> need __init__.py file to make the subdirectory a package so that >>> Python scripts in usertools/ can find their dependencies. >>> >>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> >>> --- >>> usertools/DPDKConfigLib/__init__.py | 0 >>> 1 file changed, 0 insertions(+), 0 deletions(-) >>> create mode 100644 usertools/DPDKConfigLib/__init__.py >>> >>> diff --git a/usertools/DPDKConfigLib/__init__.py b/usertools/DPDKConfigLib/__init__.py >>> new file mode 100644 >>> index 000000000..e69de29bb >> Doing this a better than current code, but can we go farther? >> I would like DPDK to get out of doing binds directly and switch to using driverctl >> which also handles persistent rebind on reboot. > > Wasn't the objection that it's not available everywhere? (for the record, i have no horse in the race - i don't much care exactly how it's done) If it works on FreeBSD and Linux then I am all for it. On windows does it support this method too? > > -- > Thanks, > Anatoly Regards, Keith
> -----Original Message----- > From: Wiles, Keith > Sent: Friday, November 16, 2018 2:10 PM > To: Burakov, Anatoly <anatoly.burakov@intel.com> > Cc: Stephen Hemminger <stephen@networkplumber.org>; dev <dev@dpdk.org>; > Mcnamara, John <john.mcnamara@intel.com>; Richardson, Bruce > <bruce.richardson@intel.com>; De Lara Guarch, Pablo > <pablo.de.lara.guarch@intel.com>; Hunt, David <david.hunt@intel.com>; > Awal, Mohammad Abdul <mohammad.abdul.awal@intel.com>; thomas@monjalon.net; > Yigit, Ferruh <ferruh.yigit@intel.com> > Subject: Re: [dpdk-dev] [RFC v2 1/9] usertools: add DPDK config lib python > library > > > > > On Nov 16, 2018, at 5:49 AM, Burakov, Anatoly > <anatoly.burakov@intel.com> wrote: > > > > On 16-Nov-18 12:45 AM, Stephen Hemminger wrote: > >> On Thu, 15 Nov 2018 15:47:13 +0000 > >> Anatoly Burakov <anatoly.burakov@intel.com> wrote: > >>> This is a placeholder for Python library abstracting away many of > >>> mundane details DPDK configuration scripts have to deal with. We > >>> need __init__.py file to make the subdirectory a package so that > >>> Python scripts in usertools/ can find their dependencies. > >>> > >>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> > >>> --- > >>> usertools/DPDKConfigLib/__init__.py | 0 > >>> 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 > >>> usertools/DPDKConfigLib/__init__.py > >>> > >>> diff --git a/usertools/DPDKConfigLib/__init__.py > >>> b/usertools/DPDKConfigLib/__init__.py > >>> new file mode 100644 > >>> index 000000000..e69de29bb > >> Doing this a better than current code, but can we go farther? > >> I would like DPDK to get out of doing binds directly and switch to > >> using driverctl which also handles persistent rebind on reboot. > > > > Wasn't the objection that it's not available everywhere? (for the > > record, i have no horse in the race - i don't much care exactly how > > it's done) > > If it works on FreeBSD and Linux then I am all for it. On windows does it > support this method too? > > Binding and unbinding is completely different on each OS. FreeBSD has no overlap of scripts with Linux, so replacing some of our tools with driverctl won't affect that OS. /Bruce
On 16-Nov-18 2:13 PM, Richardson, Bruce wrote: > > >> -----Original Message----- >> From: Wiles, Keith >> Sent: Friday, November 16, 2018 2:10 PM >> To: Burakov, Anatoly <anatoly.burakov@intel.com> >> Cc: Stephen Hemminger <stephen@networkplumber.org>; dev <dev@dpdk.org>; >> Mcnamara, John <john.mcnamara@intel.com>; Richardson, Bruce >> <bruce.richardson@intel.com>; De Lara Guarch, Pablo >> <pablo.de.lara.guarch@intel.com>; Hunt, David <david.hunt@intel.com>; >> Awal, Mohammad Abdul <mohammad.abdul.awal@intel.com>; thomas@monjalon.net; >> Yigit, Ferruh <ferruh.yigit@intel.com> >> Subject: Re: [dpdk-dev] [RFC v2 1/9] usertools: add DPDK config lib python >> library >> >> >> >>> On Nov 16, 2018, at 5:49 AM, Burakov, Anatoly >> <anatoly.burakov@intel.com> wrote: >>> >>> On 16-Nov-18 12:45 AM, Stephen Hemminger wrote: >>>> On Thu, 15 Nov 2018 15:47:13 +0000 >>>> Anatoly Burakov <anatoly.burakov@intel.com> wrote: >>>>> This is a placeholder for Python library abstracting away many of >>>>> mundane details DPDK configuration scripts have to deal with. We >>>>> need __init__.py file to make the subdirectory a package so that >>>>> Python scripts in usertools/ can find their dependencies. >>>>> >>>>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> >>>>> --- >>>>> usertools/DPDKConfigLib/__init__.py | 0 >>>>> 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 >>>>> usertools/DPDKConfigLib/__init__.py >>>>> >>>>> diff --git a/usertools/DPDKConfigLib/__init__.py >>>>> b/usertools/DPDKConfigLib/__init__.py >>>>> new file mode 100644 >>>>> index 000000000..e69de29bb >>>> Doing this a better than current code, but can we go farther? >>>> I would like DPDK to get out of doing binds directly and switch to >>>> using driverctl which also handles persistent rebind on reboot. >>> >>> Wasn't the objection that it's not available everywhere? (for the >>> record, i have no horse in the race - i don't much care exactly how >>> it's done) >> >> If it works on FreeBSD and Linux then I am all for it. On windows does it >> support this method too? >>> > > Binding and unbinding is completely different on each OS. FreeBSD has no overlap > of scripts with Linux, so replacing some of our tools with driverctl won't affect > that OS. > > /Bruce > ...however, we could abstract that away in our tools, and use OS-appropriate tools independently of what we're running on. There could still be value in fixing devbind everyone knows and love to work on all OS's without too much hassle :)
16/11/2018 15:37, Burakov, Anatoly: > On 16-Nov-18 2:13 PM, Richardson, Bruce wrote: > > From: Wiles, Keith > >>> On Nov 16, 2018, at 5:49 AM, Burakov, Anatoly > >>> On 16-Nov-18 12:45 AM, Stephen Hemminger wrote: > >>>> Anatoly Burakov <anatoly.burakov@intel.com> wrote: > >>>>> This is a placeholder for Python library abstracting away many of > >>>>> mundane details DPDK configuration scripts have to deal with. We > >>>>> need __init__.py file to make the subdirectory a package so that > >>>>> Python scripts in usertools/ can find their dependencies. > >>>>> > >>>>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> > >>>> > >>>> Doing this a better than current code, but can we go farther? > >>>> I would like DPDK to get out of doing binds directly and switch to > >>>> using driverctl which also handles persistent rebind on reboot. > >>> > >>> Wasn't the objection that it's not available everywhere? (for the > >>> record, i have no horse in the race - i don't much care exactly how > >>> it's done) > >> > >> If it works on FreeBSD and Linux then I am all for it. On windows does it > >> support this method too? > > > > Binding and unbinding is completely different on each OS. FreeBSD has no overlap > > of scripts with Linux, so replacing some of our tools with driverctl won't affect > > that OS. > > > > /Bruce > > ...however, we could abstract that away in our tools, and use > OS-appropriate tools independently of what we're running on. There could > still be value in fixing devbind everyone knows and love to work on all > OS's without too much hassle :) Yes, easier script is always better. Another thought, I would like we think about integrating binding/unbinding code inside EAL and bus drivers, and manage it via the PMDs. There could be an option to bind on scan and unbind on rte_dev_remove.
> On Nov 16, 2018, at 8:37 AM, Burakov, Anatoly <anatoly.burakov@intel.com> wrote: > > On 16-Nov-18 2:13 PM, Richardson, Bruce wrote: >>> -----Original Message----- >>> From: Wiles, Keith >>> Sent: Friday, November 16, 2018 2:10 PM >>> To: Burakov, Anatoly <anatoly.burakov@intel.com> >>> Cc: Stephen Hemminger <stephen@networkplumber.org>; dev <dev@dpdk.org>; >>> Mcnamara, John <john.mcnamara@intel.com>; Richardson, Bruce >>> <bruce.richardson@intel.com>; De Lara Guarch, Pablo >>> <pablo.de.lara.guarch@intel.com>; Hunt, David <david.hunt@intel.com>; >>> Awal, Mohammad Abdul <mohammad.abdul.awal@intel.com>; thomas@monjalon.net; >>> Yigit, Ferruh <ferruh.yigit@intel.com> >>> Subject: Re: [dpdk-dev] [RFC v2 1/9] usertools: add DPDK config lib python >>> library >>> >>> >>> >>>> On Nov 16, 2018, at 5:49 AM, Burakov, Anatoly >>> <anatoly.burakov@intel.com> wrote: >>>> >>>> On 16-Nov-18 12:45 AM, Stephen Hemminger wrote: >>>>> On Thu, 15 Nov 2018 15:47:13 +0000 >>>>> Anatoly Burakov <anatoly.burakov@intel.com> wrote: >>>>>> This is a placeholder for Python library abstracting away many of >>>>>> mundane details DPDK configuration scripts have to deal with. We >>>>>> need __init__.py file to make the subdirectory a package so that >>>>>> Python scripts in usertools/ can find their dependencies. >>>>>> >>>>>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> >>>>>> --- >>>>>> usertools/DPDKConfigLib/__init__.py | 0 >>>>>> 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 >>>>>> usertools/DPDKConfigLib/__init__.py >>>>>> >>>>>> diff --git a/usertools/DPDKConfigLib/__init__.py >>>>>> b/usertools/DPDKConfigLib/__init__.py >>>>>> new file mode 100644 >>>>>> index 000000000..e69de29bb >>>>> Doing this a better than current code, but can we go farther? >>>>> I would like DPDK to get out of doing binds directly and switch to >>>>> using driverctl which also handles persistent rebind on reboot. >>>> >>>> Wasn't the objection that it's not available everywhere? (for the >>>> record, i have no horse in the race - i don't much care exactly how >>>> it's done) >>> >>> If it works on FreeBSD and Linux then I am all for it. On windows does it >>> support this method too? >>>> >> Binding and unbinding is completely different on each OS. FreeBSD has no overlap >> of scripts with Linux, so replacing some of our tools with driverctl won't affect >> that OS. >> /Bruce > > ...however, we could abstract that away in our tools, and use OS-appropriate tools independently of what we're running on. There could still be value in fixing devbind everyone knows and love to work on all OS's without too much hassle :) Having one tool to rule them all would be great. The one I worry about is windows, but if it can be done then we should do it. The library code you have done is a great direction to solve these problems. > > -- > Thanks, > Anatoly Regards, Keith
> On Nov 16, 2018, at 8:55 AM, Thomas Monjalon <thomas@monjalon.net> wrote: > > 16/11/2018 15:37, Burakov, Anatoly: >> On 16-Nov-18 2:13 PM, Richardson, Bruce wrote: >>> From: Wiles, Keith >>>>> On Nov 16, 2018, at 5:49 AM, Burakov, Anatoly >>>>> On 16-Nov-18 12:45 AM, Stephen Hemminger wrote: >>>>>> Anatoly Burakov <anatoly.burakov@intel.com> wrote: >>>>>>> This is a placeholder for Python library abstracting away many of >>>>>>> mundane details DPDK configuration scripts have to deal with. We >>>>>>> need __init__.py file to make the subdirectory a package so that >>>>>>> Python scripts in usertools/ can find their dependencies. >>>>>>> >>>>>>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> >>>>>> >>>>>> Doing this a better than current code, but can we go farther? >>>>>> I would like DPDK to get out of doing binds directly and switch to >>>>>> using driverctl which also handles persistent rebind on reboot. >>>>> >>>>> Wasn't the objection that it's not available everywhere? (for the >>>>> record, i have no horse in the race - i don't much care exactly how >>>>> it's done) >>>> >>>> If it works on FreeBSD and Linux then I am all for it. On windows does it >>>> support this method too? >>> >>> Binding and unbinding is completely different on each OS. FreeBSD has no overlap >>> of scripts with Linux, so replacing some of our tools with driverctl won't affect >>> that OS. >>> >>> /Bruce >> >> ...however, we could abstract that away in our tools, and use >> OS-appropriate tools independently of what we're running on. There could >> still be value in fixing devbind everyone knows and love to work on all >> OS's without too much hassle :) > > Yes, easier script is always better. > > Another thought, I would like we think about integrating binding/unbinding > code inside EAL and bus drivers, and manage it via the PMDs. > There could be an option to bind on scan and unbind on rte_dev_remove. > Would it be OK to call the tool from the PMD or are wanting new APIs in DPDK? > Regards, Keith
On 16-Nov-18 2:55 PM, Thomas Monjalon wrote: > 16/11/2018 15:37, Burakov, Anatoly: >> On 16-Nov-18 2:13 PM, Richardson, Bruce wrote: >>> From: Wiles, Keith >>>>> On Nov 16, 2018, at 5:49 AM, Burakov, Anatoly >>>>> On 16-Nov-18 12:45 AM, Stephen Hemminger wrote: >>>>>> Anatoly Burakov <anatoly.burakov@intel.com> wrote: >>>>>>> This is a placeholder for Python library abstracting away many of >>>>>>> mundane details DPDK configuration scripts have to deal with. We >>>>>>> need __init__.py file to make the subdirectory a package so that >>>>>>> Python scripts in usertools/ can find their dependencies. >>>>>>> >>>>>>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> >>>>>> >>>>>> Doing this a better than current code, but can we go farther? >>>>>> I would like DPDK to get out of doing binds directly and switch to >>>>>> using driverctl which also handles persistent rebind on reboot. >>>>> >>>>> Wasn't the objection that it's not available everywhere? (for the >>>>> record, i have no horse in the race - i don't much care exactly how >>>>> it's done) >>>> >>>> If it works on FreeBSD and Linux then I am all for it. On windows does it >>>> support this method too? >>> >>> Binding and unbinding is completely different on each OS. FreeBSD has no overlap >>> of scripts with Linux, so replacing some of our tools with driverctl won't affect >>> that OS. >>> >>> /Bruce >> >> ...however, we could abstract that away in our tools, and use >> OS-appropriate tools independently of what we're running on. There could >> still be value in fixing devbind everyone knows and love to work on all >> OS's without too much hassle :) > > Yes, easier script is always better. > > Another thought, I would like we think about integrating binding/unbinding > code inside EAL and bus drivers, and manage it via the PMDs. > There could be an option to bind on scan and unbind on rte_dev_remove. > I didn't like it back when it was a thing, and i don't particularly like this idea now, to be honest. Port binding should not be under purview of the application, but is firmly in the domain of system administrator IMO. I don't think it's our place to change system configuration while we're running.
16/11/2018 16:43, Burakov, Anatoly: > On 16-Nov-18 2:55 PM, Thomas Monjalon wrote: > > 16/11/2018 15:37, Burakov, Anatoly: > >> On 16-Nov-18 2:13 PM, Richardson, Bruce wrote: > >>> From: Wiles, Keith > >>>>> On Nov 16, 2018, at 5:49 AM, Burakov, Anatoly > >>>>> On 16-Nov-18 12:45 AM, Stephen Hemminger wrote: > >>>>>> Anatoly Burakov <anatoly.burakov@intel.com> wrote: > >>>>>>> This is a placeholder for Python library abstracting away many of > >>>>>>> mundane details DPDK configuration scripts have to deal with. We > >>>>>>> need __init__.py file to make the subdirectory a package so that > >>>>>>> Python scripts in usertools/ can find their dependencies. > >>>>>>> > >>>>>>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> > >>>>>> > >>>>>> Doing this a better than current code, but can we go farther? > >>>>>> I would like DPDK to get out of doing binds directly and switch to > >>>>>> using driverctl which also handles persistent rebind on reboot. > >>>>> > >>>>> Wasn't the objection that it's not available everywhere? (for the > >>>>> record, i have no horse in the race - i don't much care exactly how > >>>>> it's done) > >>>> > >>>> If it works on FreeBSD and Linux then I am all for it. On windows does it > >>>> support this method too? > >>> > >>> Binding and unbinding is completely different on each OS. FreeBSD has no overlap > >>> of scripts with Linux, so replacing some of our tools with driverctl won't affect > >>> that OS. > >>> > >>> /Bruce > >> > >> ...however, we could abstract that away in our tools, and use > >> OS-appropriate tools independently of what we're running on. There could > >> still be value in fixing devbind everyone knows and love to work on all > >> OS's without too much hassle :) > > > > Yes, easier script is always better. > > > > Another thought, I would like we think about integrating binding/unbinding > > code inside EAL and bus drivers, and manage it via the PMDs. > > There could be an option to bind on scan and unbind on rte_dev_remove. > > I didn't like it back when it was a thing, and i don't particularly like > this idea now, to be honest. Port binding should not be under purview of > the application, but is firmly in the domain of system administrator > IMO. I don't think it's our place to change system configuration while > we're running. Yes I agree, administration should be done separately. However, there are 3 scenarios to manage properly: - hotplug: can it be configured in advance? - dynamically release device to kernel - some drivers can share a device with the kernel
On Fri, Nov 16, 2018 at 03:43:57PM +0000, Burakov, Anatoly wrote: > On 16-Nov-18 2:55 PM, Thomas Monjalon wrote: > > 16/11/2018 15:37, Burakov, Anatoly: > > > On 16-Nov-18 2:13 PM, Richardson, Bruce wrote: > > > > From: Wiles, Keith > > > > > > On Nov 16, 2018, at 5:49 AM, Burakov, Anatoly > > > > > > On 16-Nov-18 12:45 AM, Stephen Hemminger wrote: > > > > > > > Anatoly Burakov <anatoly.burakov@intel.com> wrote: > > > > > > > > This is a placeholder for Python library abstracting away many of > > > > > > > > mundane details DPDK configuration scripts have to deal with. We > > > > > > > > need __init__.py file to make the subdirectory a package so that > > > > > > > > Python scripts in usertools/ can find their dependencies. > > > > > > > > > > > > > > > > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> > > > > > > > > > > > > > > Doing this a better than current code, but can we go farther? > > > > > > > I would like DPDK to get out of doing binds directly and switch to > > > > > > > using driverctl which also handles persistent rebind on reboot. > > > > > > > > > > > > Wasn't the objection that it's not available everywhere? (for the > > > > > > record, i have no horse in the race - i don't much care exactly how > > > > > > it's done) > > > > > > > > > > If it works on FreeBSD and Linux then I am all for it. On windows does it > > > > > support this method too? > > > > > > > > Binding and unbinding is completely different on each OS. FreeBSD has no overlap > > > > of scripts with Linux, so replacing some of our tools with driverctl won't affect > > > > that OS. > > > > > > > > /Bruce > > > > > > ...however, we could abstract that away in our tools, and use > > > OS-appropriate tools independently of what we're running on. There could > > > still be value in fixing devbind everyone knows and love to work on all > > > OS's without too much hassle :) > > > > Yes, easier script is always better. > > > > Another thought, I would like we think about integrating binding/unbinding > > code inside EAL and bus drivers, and manage it via the PMDs. > > There could be an option to bind on scan and unbind on rte_dev_remove. > > > > I didn't like it back when it was a thing, and i don't particularly like > this idea now, to be honest. Port binding should not be under purview of the > application, but is firmly in the domain of system administrator IMO. I > don't think it's our place to change system configuration while we're > running. > I tend to agree. I think driverctl is the way to go here.
On Fri, Nov 16, 2018 at 04:58:10PM +0100, Thomas Monjalon wrote: > 16/11/2018 16:43, Burakov, Anatoly: > > On 16-Nov-18 2:55 PM, Thomas Monjalon wrote: > > > 16/11/2018 15:37, Burakov, Anatoly: > > >> On 16-Nov-18 2:13 PM, Richardson, Bruce wrote: > > >>> From: Wiles, Keith > > >>>>> On Nov 16, 2018, at 5:49 AM, Burakov, Anatoly > > >>>>> On 16-Nov-18 12:45 AM, Stephen Hemminger wrote: > > >>>>>> Anatoly Burakov <anatoly.burakov@intel.com> wrote: > > >>>>>>> This is a placeholder for Python library abstracting away many of > > >>>>>>> mundane details DPDK configuration scripts have to deal with. We > > >>>>>>> need __init__.py file to make the subdirectory a package so that > > >>>>>>> Python scripts in usertools/ can find their dependencies. > > >>>>>>> > > >>>>>>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> > > >>>>>> > > >>>>>> Doing this a better than current code, but can we go farther? > > >>>>>> I would like DPDK to get out of doing binds directly and switch to > > >>>>>> using driverctl which also handles persistent rebind on reboot. > > >>>>> > > >>>>> Wasn't the objection that it's not available everywhere? (for the > > >>>>> record, i have no horse in the race - i don't much care exactly how > > >>>>> it's done) > > >>>> > > >>>> If it works on FreeBSD and Linux then I am all for it. On windows does it > > >>>> support this method too? > > >>> > > >>> Binding and unbinding is completely different on each OS. FreeBSD has no overlap > > >>> of scripts with Linux, so replacing some of our tools with driverctl won't affect > > >>> that OS. > > >>> > > >>> /Bruce > > >> > > >> ...however, we could abstract that away in our tools, and use > > >> OS-appropriate tools independently of what we're running on. There could > > >> still be value in fixing devbind everyone knows and love to work on all > > >> OS's without too much hassle :) > > > > > > Yes, easier script is always better. > > > > > > Another thought, I would like we think about integrating binding/unbinding > > > code inside EAL and bus drivers, and manage it via the PMDs. > > > There could be an option to bind on scan and unbind on rte_dev_remove. > > > > I didn't like it back when it was a thing, and i don't particularly like > > this idea now, to be honest. Port binding should not be under purview of > > the application, but is firmly in the domain of system administrator > > IMO. I don't think it's our place to change system configuration while > > we're running. > > Yes I agree, administration should be done separately. > However, there are 3 scenarios to manage properly: > - hotplug: can it be configured in advance? I think using driverctl could help here. Only if a device is automatically bound to a suitable kernel driver, DPDK should hotplug it in. > - dynamically release device to kernel > - some drivers can share a device with the kernel > >