DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Chautru, Nicolas" <nicolas.chautru@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"gakhil@marvell.com" <gakhil@marvell.com>,
	 "maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
	"trix@redhat.com" <trix@redhat.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>,
	"stephen@networkplumber.org" <stephen@networkplumber.org>,
	"Vargas, Hernan" <hernan.vargas@intel.com>
Subject: RE: [PATCH v12 04/16] baseband/acc: introduce PMD for ACC200
Date: Mon, 31 Oct 2022 21:41:10 +0000	[thread overview]
Message-ID: <BY5PR11MB44518754B3B43A48E04E89B4F8379@BY5PR11MB4451.namprd11.prod.outlook.com> (raw)
In-Reply-To: <2968027.687JKscXgg@thomas>

Hi Thomas, 

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> 31/10/2022 16:43, Chautru, Nicolas:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 12/10/2022 19:59, Nicolas Chautru:
> > > > +Bind PF UIO driver(s)
> > > > +~~~~~~~~~~~~~~~~~~~~~
> > > > +
> > > > +Install the DPDK igb_uio driver, bind it with the PF PCI device
> > > > +ID and use ``lspci`` to confirm the PF device is under use by
> > > > +``igb_uio`` DPDK
> > > UIO driver.
> > >
> > > igb_uio is not recommended.
> > > Please focus on VFIO first.
> > >
> > > > +The igb_uio driver may be bound to the PF PCI device using one of
> > > > +two methods for ACC200:
> > > > +
> > > > +
> > > > +1. PCI functions (physical or virtual, depending on the use case)
> > > > +can be bound to the UIO driver by repeating this command for every
> function.
> > > > +
> > > > +.. code-block:: console
> > > > +
> > > > +  cd <dpdk-top-level-directory>
> > > > +  insmod ./build/kmod/igb_uio.ko
> > > > +  echo "8086 57c0" > /sys/bus/pci/drivers/igb_uio/new_id
> > > > +  lspci -vd8086:57c0
> > > > +
> > > > +
> > > > +2. Another way to bind PF with DPDK UIO driver is by using the
> > > > +``dpdk-devbind.py`` tool
> > > > +
> > > > +.. code-block:: console
> > > > +
> > > > +  cd <dpdk-top-level-directory>
> > > > +  ./usertools/dpdk-devbind.py -b igb_uio 0000:f7:00.0
> > > > +
> > > > +where the PCI device ID (example: 0000:f7:00.0) is obtained using
> > > > +lspci -vd8086:57c0
> > >
> > > This binding is not specific to the driver.
> > > It would be better to refer to the Linux guide instead of
> > > duplicating it again and again.
> > >
> > > > +In a similar way the PF may be bound with vfio-pci as any PCIe device.
> > >
> > > You could mention igb_uio here.
> > > Is there any advantage in using igb_uio?
> > >
> >
> > Igb_uio is arguably easier to use to new user tend to start with it or specific
> ecosystem. This is typically the entry point (no iommu, no flr below the bonnet,
> no vfio token...) hence good to have a bit of handholding with a couple of lines
> capturing how to easily run a few tests. I don't believe this is too redundant to
> have these few lines compared to the help in bring to the user not having to
> double guess their steps.
> > More generally there are a number of module drivers combinations that are
> supported based on different deployments. We don't document in too much
> details for the details since that is not too ACC specific and there is more
> documentation no pf_bb_config repo for using the PMD from the VF..
> >
> > Basically Thomas let us know more explicitly what you are suggesting as
> documentation update. You just want more emphasis on vfio-pci flow (which is
> fair, some of it documented on pf_bb_config including the vfio token passing
> but we can reproduce here as well) or something else?
> 
> There are 2 things to change:
> 1/ igb_uio is going to be deprecated, so we must emphasize on VFIO

Is there a date for deprecation? Do you mean to EOL the dpdk-kmods repository itself; or something more specific for DPDK code like removing RTE_PCI_KDRV_IGB_UIO; or last to just take out from documentation?
It tends to be historical but uio has value notably for ease of use. 

2/ for doc
> maintenance, it is better to have common steps described in one place.
> If needed, you can change the common doc and refer to it.

Do you mean to remove these sections and just add a pointer to https://doc.dpdk.org/guides/linux_gsg/linux_drivers.html instead in all these bbdev PMDS?
Please kindly confirm. I see specific steps for binding in many other PMDs docs in DPDK, a bit redundant but provides simple steps specific to a PMD in one place. I don't mind either way. 

Thanks
Nic
 


  reply	other threads:[~2022-10-31 21:41 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-12 17:59 [PATCH v12 00/16] bbdev ACC200 PMD Nicolas Chautru
2022-10-12 17:59 ` [PATCH v12 01/16] baseband/acc100: remove unused registers Nicolas Chautru
2022-10-12 17:59 ` [PATCH v12 02/16] baseband/acc100: refactor to segregate common code Nicolas Chautru
2023-11-16 17:25   ` David Marchand
2022-10-12 17:59 ` [PATCH v12 03/16] baseband/acc: rename directory from acc100 to acc Nicolas Chautru
2022-10-12 17:59 ` [PATCH v12 04/16] baseband/acc: introduce PMD for ACC200 Nicolas Chautru
2022-10-13  9:11   ` [EXT] " Akhil Goyal
2022-10-30 16:02   ` Thomas Monjalon
2022-10-31 15:43     ` Chautru, Nicolas
2022-10-31 15:53       ` Thomas Monjalon
2022-10-31 21:41         ` Chautru, Nicolas [this message]
2022-11-07 23:52           ` Chautru, Nicolas
2022-11-08  8:56             ` Thomas Monjalon
2022-11-08 23:47               ` Chautru, Nicolas
2023-10-24  7:22         ` Chautru, Nicolas
2022-10-12 17:59 ` [PATCH v12 05/16] baseband/acc: add HW register definitions " Nicolas Chautru
2022-10-12 17:59 ` [PATCH v12 06/16] baseband/acc: add info get function " Nicolas Chautru
2022-10-12 20:13   ` [EXT] " Akhil Goyal
2022-10-12 21:33     ` Chautru, Nicolas
2022-10-12 20:19   ` Akhil Goyal
2022-10-12 17:59 ` [PATCH v12 07/16] baseband/acc: add queue configuration " Nicolas Chautru
2022-10-12 17:59 ` [PATCH v12 08/16] baseband/acc: add LDPC processing functions Nicolas Chautru
2022-10-12 17:59 ` [PATCH v12 09/16] baseband/acc: add LTE " Nicolas Chautru
2022-10-12 17:59 ` [PATCH v12 10/16] baseband/acc: add support for FFT operations Nicolas Chautru
2022-10-12 17:59 ` [PATCH v12 11/16] baseband/acc: support interrupt Nicolas Chautru
2022-10-12 17:59 ` [PATCH v12 12/16] baseband/acc: add device status and vf2pf comms Nicolas Chautru
2022-10-12 17:59 ` [PATCH v12 13/16] baseband/acc: add PF configure companion function Nicolas Chautru
2022-10-12 17:59 ` [PATCH v12 14/16] baseband/acc: simplify meson dependency Nicolas Chautru
2022-10-12 17:59 ` [PATCH v12 15/16] baseband/acc: add helper function for descriptor index Nicolas Chautru
2022-10-12 17:59 ` [PATCH v12 16/16] test-bbdev: unit test capability extension Nicolas Chautru
2022-10-13  8:56   ` Maxime Coquelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BY5PR11MB44518754B3B43A48E04E89B4F8379@BY5PR11MB4451.namprd11.prod.outlook.com \
    --to=nicolas.chautru@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=gakhil@marvell.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=hernan.vargas@intel.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    --cc=trix@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).