From: Neil Horman <nhorman@tuxdriver.com>
To: Olivier Matz <olivier.matz@6wind.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
dev@dpdk.org, thomas.monjalon@6wind.com, vido@cesnet.cz,
fiona.trahe@intel.com, adrien.mazarguil@6wind.com
Subject: Re: [dpdk-dev] [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
Date: Fri, 16 Dec 2016 07:37:38 -0500 [thread overview]
Message-ID: <20161216123738.GA2255@hmsreliant.think-freely.org> (raw)
In-Reply-To: <20161216102208.08955321@platinum>
On Fri, Dec 16, 2016 at 10:22:08AM +0100, Olivier Matz wrote:
> Hi,
>
> On Thu, 15 Dec 2016 09:22:07 -0800, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > On Thu, 15 Dec 2016 11:09:12 -0500
> > Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > > On Thu, Dec 15, 2016 at 02:46:39PM +0100, Olivier Matz wrote:
> > > > Add a new macro RTE_PMD_REGISTER_KMOD_DEP() that allows a driver
> > > > to declare the list of kernel modules required to run properly.
> > > >
> > > > Today, most PCI drivers require uio/vfio.
> > > >
> > > > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> > > > Acked-by: Fiona Trahe <fiona.trahe@intel.com>
> > > > ---
> > > >
> > > > v2 -> v3:
> > > > - fix kmods deps advertised by mellanox drivers as pointed out
> > > > by Adrien
> > > >
> > > > v1 ->
> > > > v2:
> > > > - do not advertise uio_pci_generic for vf drivers
> > > > - rebase on top of head: use new driver names and prefix
> > > > macro with
> > > > RTE_
> > > >
> > > > rfc -> v1:
> > > > - the kmod information can be per-device using a modalias-like
> > > > pattern
> > > > - change syntax to use '&' and '|' instead of ',' and ':'
> > > > - remove useless prerequisites in kmod lis: no need to
> > > > specify both uio and uio_pci_generic, only the latter is
> > > > required
> > > > - update kmod list in szedata2 driver
> > > > - remove kmod list in qat driver: it requires more than just
> > > > loading a kmod, which is described in documentation
> > > >
> > > > buildtools/pmdinfogen/pmdinfogen.c | 1 +
> > > > buildtools/pmdinfogen/pmdinfogen.h | 1 +
> > > > drivers/net/bnx2x/bnx2x_ethdev.c | 2 ++
> > > > drivers/net/bnxt/bnxt_ethdev.c | 1 +
> > > > drivers/net/cxgbe/cxgbe_ethdev.c | 1 +
> > > > drivers/net/e1000/em_ethdev.c | 1 +
> > > > drivers/net/e1000/igb_ethdev.c | 2 ++
> > > > drivers/net/ena/ena_ethdev.c | 1 +
> > > > drivers/net/enic/enic_ethdev.c | 1 +
> > > > drivers/net/fm10k/fm10k_ethdev.c | 1 +
> > > > drivers/net/i40e/i40e_ethdev.c | 1 +
> > > > drivers/net/i40e/i40e_ethdev_vf.c | 1 +
> > > > drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++
> > > > drivers/net/mlx4/mlx4.c | 2 ++
> > > > drivers/net/mlx5/mlx5.c | 1 +
> > > > drivers/net/nfp/nfp_net.c | 1 +
> > > > drivers/net/qede/qede_ethdev.c | 2 ++
> > > > drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
> > > > drivers/net/thunderx/nicvf_ethdev.c | 1 +
> > > > drivers/net/virtio/virtio_ethdev.c | 1 +
> > > > drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 +
> > > > lib/librte_eal/common/include/rte_dev.h | 25
> > > > +++++++++++++++++++++++++ tools/dpdk-pmdinfo.py
> > > > | 5 ++++- 23 files changed, 56 insertions(+), 1 deletion(-)
> > > >
> > > Its odd that all devices, regardless of vendor should depend on the
> > > igb_uio module. It seems to me that depending on uio_pci_generic
> > > or vfio is sufficient.
>
> igb_uio is the historical uio module of dpdk. Although it is called
> igb_uio, it is not specific to Intel drivers.
>
> Most drivers declare "igb_uio | uio_pci_generic | vfio", which means
> that any of the 3 kernel modules can be used.
>
> I think there are some cases where people will prefer using igb_uio,
> for instance to use a vf pmd in a vm where there is no iommu,
> and where the kernel vfio module does not support the no-iommu mode.
>
>
> >
> > Yes it seems just a special case extension for Mellanox drivers.
>
> Kmod deps are different whether it's a vf driver or not.
> Mellanox drivers are not the only drivers that do not require uio,
> there is also szedata2.
>
> Is it an argument for not including this patch?
>
Speaking only for myself, I'm not suggesting the patch not be included, only
questioning the need to list igb_uio as an optional dependency. From what I
understand uio_pci_generic is equaly capable of being used in a vf as igb_uio,
and so it seems like its sufficient to list in the deps alone, or am I missing
something?
Additionally, in regards to the comment about rebasing on net-next here, I don't
think thats needed. This patch is built such that you will be able to apply
this tag to additional drivers later, as they get merged into thomas's tree, you
don't need to get them all in one shot. More to the point, there are crypto
drivers that may make use of this module dependency tag, and those are also
missing. I would suggest taking the patch based on it current state (once the
above igb_uio issue is settled), and then adding the tag to new drivers in
subsequent releases as they get merged.
Neil
>
> Regards,
> Olivier
>
next prev parent reply other threads:[~2016-12-16 12:38 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-26 13:20 [dpdk-dev] [RFC] " Olivier Matz
2016-08-30 8:40 ` Matej Vido
2016-08-30 8:56 ` Olivier Matz
2016-08-30 13:23 ` [dpdk-dev] [dpdk-dev, RFC] " Neil Horman
2016-08-31 9:21 ` Olivier Matz
2016-08-31 13:27 ` Neil Horman
2016-08-31 13:39 ` Olivier Matz
2016-09-01 12:55 ` Trahe, Fiona
2016-09-01 17:35 ` Neil Horman
2016-09-01 17:41 ` Stephen Hemminger
2016-09-01 19:15 ` Neil Horman
2016-09-02 9:19 ` Trahe, Fiona
2016-09-02 13:33 ` Neil Horman
2016-09-02 13:52 ` Trahe, Fiona
2016-09-02 14:15 ` Neil Horman
2016-09-02 16:13 ` Olivier Matz
2016-09-02 10:55 ` Thomas Monjalon
2016-09-15 14:22 ` [dpdk-dev] [PATCH] " Olivier Matz
2016-09-16 9:49 ` Trahe, Fiona
2016-09-16 14:26 ` David Marchand
2016-09-19 8:17 ` Bruce Richardson
2016-09-19 12:25 ` Olivier Matz
2016-11-22 9:50 ` [dpdk-dev] [PATCH v2] " Olivier Matz
2016-11-22 10:27 ` Adrien Mazarguil
2016-11-22 10:31 ` Olivier Matz
2016-12-15 13:46 ` [dpdk-dev] [PATCH v3] " Olivier Matz
2016-12-15 14:52 ` Ferruh Yigit
2016-12-16 9:36 ` Olivier Matz
2016-12-19 13:30 ` Thomas Monjalon
2016-12-15 16:09 ` Neil Horman
2016-12-15 17:22 ` Stephen Hemminger
2016-12-16 9:22 ` Olivier Matz
2016-12-16 12:37 ` Neil Horman [this message]
2016-12-16 13:04 ` Bruce Richardson
2016-12-16 14:19 ` Ferruh Yigit
2016-12-19 12:42 ` Neil Horman
2016-12-19 14:12 ` Ferruh Yigit
2016-12-16 8:23 ` Adrien Mazarguil
2016-12-20 17:26 ` Thomas Monjalon
2016-12-21 9:21 ` Andrew Rybchenko
2016-12-21 11:37 ` Neil Horman
2016-12-21 11:40 ` Andrew Rybchenko
2016-12-22 11:04 ` Ferruh Yigit
2016-12-22 11:35 ` Andrew Rybchenko
2016-12-22 12:07 ` Ferruh Yigit
2016-12-22 12:08 ` Andrew Rybchenko
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=20161216123738.GA2255@hmsreliant.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=adrien.mazarguil@6wind.com \
--cc=dev@dpdk.org \
--cc=fiona.trahe@intel.com \
--cc=olivier.matz@6wind.com \
--cc=stephen@networkplumber.org \
--cc=thomas.monjalon@6wind.com \
--cc=vido@cesnet.cz \
/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).