Message ID | cover.1529940601.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 CD484548B; Mon, 25 Jun 2018 18:00:49 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id BCCF74C97 for <dev@dpdk.org>; Mon, 25 Jun 2018 18:00:48 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jun 2018 08:59:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,270,1526367600"; d="scan'208";a="235440244" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by orsmga005.jf.intel.com with ESMTP; 25 Jun 2018 08:59:47 -0700 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 w5PFxkMa032496; Mon, 25 Jun 2018 16:59:46 +0100 Received: from sivswdev01.ir.intel.com (localhost [127.0.0.1]) by sivswdev01.ir.intel.com with ESMTP id w5PFxk9S026571; Mon, 25 Jun 2018 16:59:46 +0100 Received: (from aburakov@localhost) by sivswdev01.ir.intel.com with LOCAL id w5PFxkJQ026567; Mon, 25 Jun 2018 16:59:46 +0100 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 Date: Mon, 25 Jun 2018 16:59:37 +0100 Message-Id: <cover.1529940601.git.anatoly.burakov@intel.com> X-Mailer: git-send-email 1.7.0.7 Subject: [dpdk-dev] [RFC 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
June 25, 2018, 3:59 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 external tools seeking to use the same functionality (bind-unbind, cpu layout, etc) * 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 (and arguably 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? 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. 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 | 414 +++++++++++++++++++ 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 | 518 ++++-------------------- usertools/hugepage-info.py | 32 ++ 10 files changed, 1544 insertions(+), 488 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
On 25-Jun-18 4:59 PM, Anatoly Burakov wrote: > 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 external tools seeking to use the same > functionality (bind-unbind, cpu layout, etc) > * 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 > (and arguably 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? > > 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. > I would like to draw attention to this RFC again :)
On 14-Aug-18 11:11 AM, Burakov, Anatoly wrote: > On 25-Jun-18 4:59 PM, Anatoly Burakov wrote: >> 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 external tools seeking to use the same >> functionality (bind-unbind, cpu layout, etc) >> * 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 >> (and arguably 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? >> >> 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. >> > > I would like to draw attention to this RFC again :) > Ping?