[dpdk-dev,v3] drivers: advertise kmod dependencies in pmdinfo
Checks
Commit Message
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(-)
Comments
Hi Olivier, Thomas,
On 12/15/2016 1:46 PM, 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>
This patch is for master branch, what do you think targeting it to
next-net tree?
So that new PMDs also can be included into patch?
Thanks,
ferruh
<...>
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.
Neil
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.
>
> Neil
>
Yes it seems just a special case extension for Mellanox drivers.
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
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
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?
Regards,
Olivier
Hi Ferruh,
On Thu, 15 Dec 2016 14:52:02 +0000, Ferruh Yigit
<ferruh.yigit@intel.com> wrote:
> Hi Olivier, Thomas,
>
> On 12/15/2016 1:46 PM, 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>
>
> This patch is for master branch, what do you think targeting it to
> next-net tree?
> So that new PMDs also can be included into patch?
That makes sense, I can rebase on next-net.
Thomas, do you agree?
From what I see, the 2 new PMDs are sfc (uio) and tap (nothing).
Regards,
Olivier
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
>
On Fri, Dec 16, 2016 at 07:37:38AM -0500, Neil Horman wrote:
> 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?
>
Unfortunately uio_pci_generic cannot be used with VFs either inside or
outside a VM, as VFs use MSI/MSI-X rather than legacy interrupts. For
newer kernels with vfio-noiommu, that is an option, but for any other
case, igb_uio is needed.
/Bruce
On 12/16/2016 12:37 PM, Neil Horman wrote:
> 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.
Right, more drivers can be added later. But also I don't see any problem
if this patch rebased on next-net and be a more complete patch. That is
why it was a question to the author.
> 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
>>
On Fri, Dec 16, 2016 at 02:19:59PM +0000, Ferruh Yigit wrote:
> On 12/16/2016 12:37 PM, Neil Horman wrote:
> > 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.
>
> Right, more drivers can be added later. But also I don't see any problem
> if this patch rebased on next-net and be a more complete patch. That is
> why it was a question to the author.
>
Right, it certainly doesn't hurt anything to do so, but given that:
1) We're on v3 of this patch
2) Not including information in all drivers isn't catastrophic
3) Rebasing on net-next still leaves the crypto drivers unaccounted for
It seems to me that including the patch now, so that the infrastructure is in
place for driver maintainers to add the macro on their own in their respective
trees seems like the more expiedient course of action.
Best
Neil
2016-12-16 10:36, Olivier Matz:
> Hi Ferruh,
>
> On Thu, 15 Dec 2016 14:52:02 +0000, Ferruh Yigit
> <ferruh.yigit@intel.com> wrote:
> > This patch is for master branch, what do you think targeting it to
> > next-net tree?
> > So that new PMDs also can be included into patch?
>
> That makes sense, I can rebase on next-net.
> Thomas, do you agree?
Yes I agree, this patch is mainly about drivers/net.
On 12/19/2016 12:42 PM, Neil Horman wrote:
> On Fri, Dec 16, 2016 at 02:19:59PM +0000, Ferruh Yigit wrote:
>> On 12/16/2016 12:37 PM, Neil Horman wrote:
>>> 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.
>>
>> Right, more drivers can be added later. But also I don't see any problem
>> if this patch rebased on next-net and be a more complete patch. That is
>> why it was a question to the author.
>>
> Right, it certainly doesn't hurt anything to do so, but given that:
>
> 1) We're on v3 of this patch
> 2) Not including information in all drivers isn't catastrophic
> 3) Rebasing on net-next still leaves the crypto drivers unaccounted for
If this patch will be extended with a new version to include crypto
drivers, yes I agree it fits better into main tree.
>
> It seems to me that including the patch now, so that the infrastructure is in
> place for driver maintainers to add the macro on their own in their respective
> trees seems like the more expiedient course of action.
>
> Best
> Neil
>
> > 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>
>
> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Applied in main tree, thanks
On 12/20/2016 08:26 PM, Thomas Monjalon 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>
>> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Applied in main tree, thanks
Is there any plan on how it will be done/solved for a new drivers in
dpdk-next-net?
Should I care about it for sfc?
Andrew.
On Wed, Dec 21, 2016 at 12:21:14PM +0300, Andrew Rybchenko wrote:
> On 12/20/2016 08:26 PM, Thomas Monjalon 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>
> > > Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > Applied in main tree, thanks
>
> Is there any plan on how it will be done/solved for a new drivers in
> dpdk-next-net?
> Should I care about it for sfc?
>
Given that all pmdinfo information is opt-in (that is to say not obligatory),
you can now wait until net-next does its next rebase, and as you continue your
development of the sfc driver, you can add the use of this macro in at your
leisure. As more people do that, we will arrive at 100% coverage
Neil
> Andrew.
>
>
On 12/21/2016 02:37 PM, Neil Horman wrote:
> On Wed, Dec 21, 2016 at 12:21:14PM +0300, Andrew Rybchenko wrote:
>> On 12/20/2016 08:26 PM, Thomas Monjalon 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>
>>>> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
>>> Applied in main tree, thanks
>> Is there any plan on how it will be done/solved for a new drivers in
>> dpdk-next-net?
>> Should I care about it for sfc?
>>
> Given that all pmdinfo information is opt-in (that is to say not obligatory),
> you can now wait until net-next does its next rebase, and as you continue your
> development of the sfc driver, you can add the use of this macro in at your
> leisure. As more people do that, we will arrive at 100% coverage
I see. Will do. Thanks.
Andrew.
> Neil
>
>> Andrew.
>>
>>
On 12/21/2016 11:40 AM, Andrew Rybchenko wrote:
> On 12/21/2016 02:37 PM, Neil Horman wrote:
>> On Wed, Dec 21, 2016 at 12:21:14PM +0300, Andrew Rybchenko wrote:
>>> On 12/20/2016 08:26 PM, Thomas Monjalon 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>
>>>>> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
>>>> Applied in main tree, thanks
>>> Is there any plan on how it will be done/solved for a new drivers in
>>> dpdk-next-net?
>>> Should I care about it for sfc?
>>>
>> Given that all pmdinfo information is opt-in (that is to say not obligatory),
>> you can now wait until net-next does its next rebase, and as you continue your
>> development of the sfc driver, you can add the use of this macro in at your
>> leisure. As more people do that, we will arrive at 100% coverage
>
> I see. Will do. Thanks.
>
Hi Andrew,
Patch rebased to next-net, would you mind doing the mentioned patch for it?
Thanks,
ferruh
On 12/22/2016 02:04 PM, Ferruh Yigit wrote:
> On 12/21/2016 11:40 AM, Andrew Rybchenko wrote:
>> On 12/21/2016 02:37 PM, Neil Horman wrote:
>>> On Wed, Dec 21, 2016 at 12:21:14PM +0300, Andrew Rybchenko wrote:
>>>> On 12/20/2016 08:26 PM, Thomas Monjalon 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>
>>>>>> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
>>>>> Applied in main tree, thanks
>>>> Is there any plan on how it will be done/solved for a new drivers in
>>>> dpdk-next-net?
>>>> Should I care about it for sfc?
>>>>
>>> Given that all pmdinfo information is opt-in (that is to say not obligatory),
>>> you can now wait until net-next does its next rebase, and as you continue your
>>> development of the sfc driver, you can add the use of this macro in at your
>>> leisure. As more people do that, we will arrive at 100% coverage
>> I see. Will do. Thanks.
>>
> Hi Andrew,
>
> Patch rebased to next-net, would you mind doing the mentioned patch for it?
Hi Ferruh,
done. I was in doubts which changeset to specify in fixes, but finally
chosen the latest from mine and Olivier's. Please, correct me, if it is
wrong.
Andrew.
On 12/22/2016 11:35 AM, Andrew Rybchenko wrote:
> On 12/22/2016 02:04 PM, Ferruh Yigit wrote:
>> On 12/21/2016 11:40 AM, Andrew Rybchenko wrote:
>>> On 12/21/2016 02:37 PM, Neil Horman wrote:
>>>> On Wed, Dec 21, 2016 at 12:21:14PM +0300, Andrew Rybchenko wrote:
>>>>> On 12/20/2016 08:26 PM, Thomas Monjalon 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>
>>>>>>> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
>>>>>> Applied in main tree, thanks
>>>>> Is there any plan on how it will be done/solved for a new drivers in
>>>>> dpdk-next-net?
>>>>> Should I care about it for sfc?
>>>>>
>>>> Given that all pmdinfo information is opt-in (that is to say not obligatory),
>>>> you can now wait until net-next does its next rebase, and as you continue your
>>>> development of the sfc driver, you can add the use of this macro in at your
>>>> leisure. As more people do that, we will arrive at 100% coverage
>>> I see. Will do. Thanks.
>>>
>> Hi Andrew,
>>
>> Patch rebased to next-net, would you mind doing the mentioned patch for it?
>
> Hi Ferruh,
>
> done. I was in doubts which changeset to specify in fixes, but finally
> chosen the latest from mine and Olivier's. Please, correct me, if it is
> wrong.
I think no fixes line required here, this patch is not fixing a defect,
but adding a new support for a pmdinfo tool.
I can remove fixes line while applying.
Thanks,
ferruh
>
> Andrew.
>
On 12/22/2016 03:07 PM, Ferruh Yigit wrote:
> On 12/22/2016 11:35 AM, Andrew Rybchenko wrote:
>> On 12/22/2016 02:04 PM, Ferruh Yigit wrote:
>>> On 12/21/2016 11:40 AM, Andrew Rybchenko wrote:
>>>> On 12/21/2016 02:37 PM, Neil Horman wrote:
>>>>> On Wed, Dec 21, 2016 at 12:21:14PM +0300, Andrew Rybchenko wrote:
>>>>>> On 12/20/2016 08:26 PM, Thomas Monjalon 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>
>>>>>>>> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
>>>>>>> Applied in main tree, thanks
>>>>>> Is there any plan on how it will be done/solved for a new drivers in
>>>>>> dpdk-next-net?
>>>>>> Should I care about it for sfc?
>>>>>>
>>>>> Given that all pmdinfo information is opt-in (that is to say not obligatory),
>>>>> you can now wait until net-next does its next rebase, and as you continue your
>>>>> development of the sfc driver, you can add the use of this macro in at your
>>>>> leisure. As more people do that, we will arrive at 100% coverage
>>>> I see. Will do. Thanks.
>>>>
>>> Hi Andrew,
>>>
>>> Patch rebased to next-net, would you mind doing the mentioned patch for it?
>> Hi Ferruh,
>>
>> done. I was in doubts which changeset to specify in fixes, but finally
>> chosen the latest from mine and Olivier's. Please, correct me, if it is
>> wrong.
> I think no fixes line required here, this patch is not fixing a defect,
> but adding a new support for a pmdinfo tool.
> I can remove fixes line while applying.
OK, I see. Thanks.
Andrew.
> Thanks,
> ferruh
>
>> Andrew.
>>
@@ -269,6 +269,7 @@ struct opt_tag {
static const struct opt_tag opt_tags[] = {
{"_param_string_export", "params"},
+ {"_kmod_dep_export", "kmod"},
};
static int complete_pmd_entry(struct elf_info *info, struct pmd_driver *drv)
@@ -89,6 +89,7 @@ else \
enum opt_params {
PMD_PARAM_STRING = 0,
+ PMD_KMOD_DEP,
PMD_OPT_MAX
};
@@ -643,5 +643,7 @@ static struct eth_driver rte_bnx2xvf_pmd = {
RTE_PMD_REGISTER_PCI(net_bnx2x, rte_bnx2x_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_bnx2x, pci_id_bnx2x_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_bnx2x, "* igb_uio | uio_pci_generic | vfio");
RTE_PMD_REGISTER_PCI(net_bnx2xvf, rte_bnx2xvf_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_bnx2xvf, pci_id_bnx2xvf_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_bnx2xvf, "* igb_uio | vfio");
@@ -1173,3 +1173,4 @@ static struct eth_driver bnxt_rte_pmd = {
RTE_PMD_REGISTER_PCI(net_bnxt, bnxt_rte_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_bnxt, bnxt_pci_id_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_bnxt, "* igb_uio | uio_pci_generic | vfio");
@@ -1050,3 +1050,4 @@ static struct eth_driver rte_cxgbe_pmd = {
RTE_PMD_REGISTER_PCI(net_cxgbe, rte_cxgbe_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_cxgbe, cxgb4_pci_tbl);
+RTE_PMD_REGISTER_KMOD_DEP(net_cxgbe, "* igb_uio | uio_pci_generic | vfio");
@@ -1807,3 +1807,4 @@ eth_em_set_mc_addr_list(struct rte_eth_dev *dev,
RTE_PMD_REGISTER_PCI(net_e1000_em, rte_em_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_e1000_em, pci_id_em_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_e1000_em, "* igb_uio | uio_pci_generic | vfio");
@@ -5240,5 +5240,7 @@ eth_igb_configure_msix_intr(struct rte_eth_dev *dev)
RTE_PMD_REGISTER_PCI(net_e1000_igb, rte_igb_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_e1000_igb, pci_id_igb_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_e1000_igb, "* igb_uio | uio_pci_generic | vfio");
RTE_PMD_REGISTER_PCI(net_e1000_igb_vf, rte_igbvf_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_e1000_igb_vf, pci_id_igbvf_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_e1000_igb_vf, "* igb_uio | vfio");
@@ -1716,3 +1716,4 @@ static struct eth_driver rte_ena_pmd = {
RTE_PMD_REGISTER_PCI(net_ena, rte_ena_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_ena, pci_id_ena_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_ena, "* igb_uio | uio_pci_generic | vfio");
@@ -645,3 +645,4 @@ static struct eth_driver rte_enic_pmd = {
RTE_PMD_REGISTER_PCI(net_enic, rte_enic_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_enic, pci_id_enic_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_enic, "* igb_uio | uio_pci_generic | vfio");
@@ -3074,3 +3074,4 @@ static struct eth_driver rte_pmd_fm10k = {
RTE_PMD_REGISTER_PCI(net_fm10k, rte_pmd_fm10k.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_fm10k, pci_id_fm10k_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_fm10k, "* igb_uio | uio_pci_generic | vfio");
@@ -711,6 +711,7 @@ rte_i40e_dev_atomic_write_link_status(struct rte_eth_dev *dev,
RTE_PMD_REGISTER_PCI(net_i40e, rte_i40e_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_i40e, pci_id_i40e_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_i40e, "* igb_uio | uio_pci_generic | vfio");
#ifndef I40E_GLQF_ORT
#define I40E_GLQF_ORT(_i) (0x00268900 + ((_i) * 4))
@@ -1539,6 +1539,7 @@ static struct eth_driver rte_i40evf_pmd = {
RTE_PMD_REGISTER_PCI(net_i40e_vf, rte_i40evf_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_i40e_vf, pci_id_i40evf_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_i40e_vf, "* igb_uio | vfio");
static int
i40evf_dev_configure(struct rte_eth_dev *dev)
@@ -7594,5 +7594,7 @@ ixgbevf_dev_interrupt_handler(__rte_unused struct rte_intr_handle *handle,
RTE_PMD_REGISTER_PCI(net_ixgbe, rte_ixgbe_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_ixgbe, pci_id_ixgbe_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_ixgbe, "* igb_uio | uio_pci_generic | vfio");
RTE_PMD_REGISTER_PCI(net_ixgbe_vf, rte_ixgbevf_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_ixgbe_vf, pci_id_ixgbevf_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_ixgbe_vf, "* igb_uio | vfio");
@@ -5937,3 +5937,5 @@ rte_mlx4_pmd_init(void)
RTE_PMD_EXPORT_NAME(net_mlx4, __COUNTER__);
RTE_PMD_REGISTER_PCI_TABLE(net_mlx4, mlx4_pci_id_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_mlx4,
+ "* ib_uverbs & mlx4_en & mlx4_core & mlx4_ib");
@@ -759,3 +759,4 @@ rte_mlx5_pmd_init(void)
RTE_PMD_EXPORT_NAME(net_mlx5, __COUNTER__);
RTE_PMD_REGISTER_PCI_TABLE(net_mlx5, mlx5_pci_id_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_mlx5, "* ib_uverbs & mlx5_core & mlx5_ib");
@@ -2481,6 +2481,7 @@ static struct eth_driver rte_nfp_net_pmd = {
RTE_PMD_REGISTER_PCI(net_nfp, rte_nfp_net_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_nfp, pci_id_nfp_net_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_nfp, "* igb_uio | uio_pci_generic | vfio");
/*
* Local variables:
@@ -1668,5 +1668,7 @@ static struct eth_driver rte_qede_pmd = {
RTE_PMD_REGISTER_PCI(net_qede, rte_qede_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_qede, pci_id_qede_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_qede, "* igb_uio | uio_pci_generic | vfio");
RTE_PMD_REGISTER_PCI(net_qede_vf, rte_qedevf_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_qede_vf, pci_id_qedevf_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_qede_vf, "* igb_uio | vfio");
@@ -1583,3 +1583,5 @@ static struct eth_driver szedata2_eth_driver = {
RTE_PMD_REGISTER_PCI(RTE_SZEDATA2_DRIVER_NAME, szedata2_eth_driver.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(RTE_SZEDATA2_DRIVER_NAME, rte_szedata2_pci_id_table);
+RTE_PMD_REGISTER_KMOD_DEP(RTE_SZEDATA2_DRIVER_NAME,
+ "* combo6core & combov3 & szedata2 & szedata2_cv3");
@@ -2121,3 +2121,4 @@ static struct eth_driver rte_nicvf_pmd = {
RTE_PMD_REGISTER_PCI(net_thunderx, rte_nicvf_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_thunderx, pci_id_nicvf_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_thunderx, "* igb_uio | uio_pci_generic | vfio");
@@ -1669,3 +1669,4 @@ __rte_unused uint8_t is_rx)
RTE_PMD_EXPORT_NAME(net_virtio, __COUNTER__);
RTE_PMD_REGISTER_PCI_TABLE(net_virtio, pci_id_virtio_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_virtio, "* igb_uio | uio_pci_generic | vfio");
@@ -962,3 +962,4 @@ vmxnet3_process_events(struct vmxnet3_hw *hw)
RTE_PMD_REGISTER_PCI(net_vmxnet3, rte_vmxnet3_pmd.pci_drv);
RTE_PMD_REGISTER_PCI_TABLE(net_vmxnet3, pci_id_vmxnet3_map);
+RTE_PMD_REGISTER_KMOD_DEP(net_vmxnet3, "* igb_uio | uio_pci_generic | vfio");
@@ -239,6 +239,31 @@ RTE_STR(table)
static const char DRV_EXP_TAG(name, param_string_export)[] \
__attribute__((used)) = str
+/**
+ * Advertise the list of kernel modules required to run this driver
+ *
+ * This string lists the kernel modules required for the devices
+ * associated to a PMD. The format of each line of the string is:
+ * "<device-pattern> <kmod-expression>".
+ *
+ * The possible formats for the device pattern are:
+ * "*" all devices supported by this driver
+ * "pci:*" all PCI devices supported by this driver
+ * "pci:v8086:d*:sv*:sd*" all PCI devices supported by this driver
+ * whose vendor id is 0x8086.
+ *
+ * The format of the kernel modules list is a parenthesed expression
+ * containing logical-and (&) and logical-or (|).
+ *
+ * The device pattern and the kmod expression are separated by a space.
+ *
+ * Example:
+ * - "* igb_uio | uio_pci_generic | vfio"
+ */
+#define RTE_PMD_REGISTER_KMOD_DEP(name, str) \
+static const char DRV_EXP_TAG(name, kmod_dep_export)[] \
+__attribute__((used)) = str
+
#ifdef __cplusplus
}
#endif
@@ -312,7 +312,10 @@ def parse_pmd_info_string(self, mystring):
global raw_output
global pcidb
- optional_pmd_info = [{'id': 'params', 'tag': 'PMD PARAMETERS'}]
+ optional_pmd_info = [
+ {'id': 'params', 'tag': 'PMD PARAMETERS'},
+ {'id': 'kmod', 'tag': 'PMD KMOD DEPENDENCIES'}
+ ]
i = mystring.index("=")
mystring = mystring[i + 2:]