* [RFC] drivers: advertise kmod dependencies in pmdinfo
@ 2016-08-26 13:20 Olivier Matz
2016-08-30 8:40 ` Matej Vido
` (2 more replies)
0 siblings, 3 replies; 46+ messages in thread
From: Olivier Matz @ 2016-08-26 13:20 UTC (permalink / raw)
To: dev, nhorman, thomas.monjalon
Add a new macro DRIVER_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>
---
In this RFC, I supposed that all PCI drivers require a the loading of a
uio/vfio module (except mlx*), this may be wrong.
Comments are welcome!
buildtools/pmdinfogen/pmdinfogen.c | 1 +
buildtools/pmdinfogen/pmdinfogen.h | 1 +
drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
drivers/net/bnxt/bnxt_ethdev.c | 2 ++
drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
drivers/net/e1000/em_ethdev.c | 2 ++
drivers/net/e1000/igb_ethdev.c | 4 ++++
drivers/net/ena/ena_ethdev.c | 2 ++
drivers/net/enic/enic_ethdev.c | 2 ++
drivers/net/fm10k/fm10k_ethdev.c | 2 ++
drivers/net/i40e/i40e_ethdev.c | 2 ++
drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
drivers/net/mlx4/mlx4.c | 2 ++
drivers/net/mlx5/mlx5.c | 3 +++
drivers/net/nfp/nfp_net.c | 2 ++
drivers/net/qede/qede_ethdev.c | 4 ++++
drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
drivers/net/thunderx/nicvf_ethdev.c | 2 ++
drivers/net/virtio/virtio_ethdev.c | 2 ++
drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
lib/librte_eal/common/include/rte_dev.h | 14 ++++++++++++++
tools/dpdk-pmdinfo.py | 5 ++++-
24 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/buildtools/pmdinfogen/pmdinfogen.c b/buildtools/pmdinfogen/pmdinfogen.c
index e1bf2e4..1e5b6f3 100644
--- a/buildtools/pmdinfogen/pmdinfogen.c
+++ b/buildtools/pmdinfogen/pmdinfogen.c
@@ -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)
diff --git a/buildtools/pmdinfogen/pmdinfogen.h b/buildtools/pmdinfogen/pmdinfogen.h
index 1da2966..2fab2aa 100644
--- a/buildtools/pmdinfogen/pmdinfogen.h
+++ b/buildtools/pmdinfogen/pmdinfogen.h
@@ -85,6 +85,7 @@ else \
enum opt_params {
PMD_PARAM_STRING = 0,
+ PMD_KMOD_DEP,
PMD_OPT_MAX
};
diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c b/drivers/crypto/qat/rte_qat_cryptodev.c
index 82ab047..fc62be9 100644
--- a/drivers/crypto/qat/rte_qat_cryptodev.c
+++ b/drivers/crypto/qat/rte_qat_cryptodev.c
@@ -135,4 +135,6 @@ static struct rte_driver pmd_qat_drv = {
PMD_REGISTER_DRIVER(pmd_qat_drv, CRYPTODEV_NAME_QAT_SYM_PMD);
DRIVER_REGISTER_PCI_TABLE(CRYPTODEV_NAME_QAT_SYM_PMD, pci_id_qat_map);
+DRIVER_REGISTER_KMOD_DEP(CRYPTODEV_NAME_QAT_SYM_PMD,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index f3ab355..ba8831a 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -667,5 +667,9 @@ static struct rte_driver rte_bnx2xvf_driver = {
PMD_REGISTER_DRIVER(rte_bnx2x_driver, bnx2x);
DRIVER_REGISTER_PCI_TABLE(bnx2x, pci_id_bnx2x_map);
+DRIVER_REGISTER_KMOD_DEP(bnx2x,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
PMD_REGISTER_DRIVER(rte_bnx2xvf_driver, bnx2xvf);
DRIVER_REGISTER_PCI_TABLE(bnx2xvf, pci_id_bnx2xvf_map);
+DRIVER_REGISTER_KMOD_DEP(bnx2xvf,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 3795fac..5c6c7b5 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1068,3 +1068,5 @@ static struct rte_driver bnxt_pmd_drv = {
PMD_REGISTER_DRIVER(bnxt_pmd_drv, bnxt);
DRIVER_REGISTER_PCI_TABLE(bnxt, bnxt_pci_id_map);
+DRIVER_REGISTER_KMOD_DEP(bnxt,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 9208a61..cea2741 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -1068,4 +1068,6 @@ static struct rte_driver rte_cxgbe_driver = {
PMD_REGISTER_DRIVER(rte_cxgbe_driver, cxgb4);
DRIVER_REGISTER_PCI_TABLE(cxgb4, cxgb4_pci_tbl);
+DRIVER_REGISTER_KMOD_DEP(cxgb4,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index ad104ed..bd0d0ea 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -1806,3 +1806,5 @@ struct rte_driver em_pmd_drv = {
PMD_REGISTER_DRIVER(em_pmd_drv, em);
DRIVER_REGISTER_PCI_TABLE(em, pci_id_em_map);
+DRIVER_REGISTER_KMOD_DEP(em,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 4e9e6a3..a3dfbfe 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -5257,5 +5257,9 @@ eth_igb_configure_msix_intr(struct rte_eth_dev *dev)
PMD_REGISTER_DRIVER(pmd_igb_drv, igb);
DRIVER_REGISTER_PCI_TABLE(igb, pci_id_igb_map);
+DRIVER_REGISTER_KMOD_DEP(igb,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
PMD_REGISTER_DRIVER(pmd_igbvf_drv, igbvf);
DRIVER_REGISTER_PCI_TABLE(igbvf, pci_id_igbvf_map);
+DRIVER_REGISTER_KMOD_DEP(igbvf,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index ac0803d..a45d60c 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -1709,3 +1709,5 @@ struct rte_driver ena_pmd_drv = {
PMD_REGISTER_DRIVER(ena_pmd_drv, ena);
DRIVER_REGISTER_PCI_TABLE(ena, pci_id_ena_map);
+DRIVER_REGISTER_KMOD_DEP(ena,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 47b07c9..a1b8abc 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -642,3 +642,5 @@ static struct rte_driver rte_enic_driver = {
PMD_REGISTER_DRIVER(rte_enic_driver, enic);
DRIVER_REGISTER_PCI_TABLE(enic, pci_id_enic_map);
+DRIVER_REGISTER_KMOD_DEP(enic,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 01f4a72..391ccd7 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -3086,3 +3086,5 @@ static struct rte_driver rte_fm10k_driver = {
PMD_REGISTER_DRIVER(rte_fm10k_driver, fm10k);
DRIVER_REGISTER_PCI_TABLE(fm10k, pci_id_fm10k_map);
+DRIVER_REGISTER_KMOD_DEP(fm10k,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index d0aeb70..a1466aa 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -723,6 +723,8 @@ static struct rte_driver rte_i40e_driver = {
PMD_REGISTER_DRIVER(rte_i40e_driver, i40e);
DRIVER_REGISTER_PCI_TABLE(i40e, pci_id_i40e_map);
+DRIVER_REGISTER_KMOD_DEP(i40e,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
/*
* Initialize registers for flexible payload, which should be set by NVM.
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
index a616ae0..61be44a 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1586,6 +1586,8 @@ static struct rte_driver rte_i40evf_driver = {
PMD_REGISTER_DRIVER(rte_i40evf_driver, i40evf);
DRIVER_REGISTER_PCI_TABLE(i40evf, pci_id_i40evf_map);
+DRIVER_REGISTER_KMOD_DEP(i40evf,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
static int
i40evf_dev_configure(struct rte_eth_dev *dev)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index fb618ef..e353d7a 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -7421,5 +7421,9 @@ static struct rte_driver rte_ixgbevf_driver = {
PMD_REGISTER_DRIVER(rte_ixgbe_driver, ixgbe);
DRIVER_REGISTER_PCI_TABLE(ixgbe, pci_id_ixgbe_map);
+DRIVER_REGISTER_KMOD_DEP(ixgbe,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
PMD_REGISTER_DRIVER(rte_ixgbevf_driver, ixgbevf);
DRIVER_REGISTER_PCI_TABLE(ixgbevf, pci_id_ixgbevf_map);
+DRIVER_REGISTER_KMOD_DEP(ixgbevf,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 304c846..d8f6905 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -5948,3 +5948,5 @@ static struct rte_driver rte_mlx4_driver = {
PMD_REGISTER_DRIVER(rte_mlx4_driver, mlx4);
DRIVER_REGISTER_PCI_TABLE(mlx4, mlx4_pci_id_map);
+DRIVER_REGISTER_KMOD_DEP(mlx4,
+ "ib_uverbs,mlx4_core,mlx4_en,mlx4_ib");
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index d96a9af..29d7332 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -763,3 +763,6 @@ static struct rte_driver rte_mlx5_driver = {
PMD_REGISTER_DRIVER(rte_mlx5_driver, mlx5);
DRIVER_REGISTER_PCI_TABLE(mlx5, mlx5_pci_id_map);
+DRIVER_REGISTER_KMOD_DEP(mlx5,
+ "ptp,inet_lro,ib_sa,ib_mad,ib_netlink,ib_addr,"
+ "ib_core,ib_uverbs,mlx5_core,mlx5_ib");
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 82e3e4e..f4c8a39 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -2488,6 +2488,8 @@ static struct rte_driver rte_nfp_net_driver = {
PMD_REGISTER_DRIVER(rte_nfp_net_driver, nfp);
DRIVER_REGISTER_PCI_TABLE(nfp, pci_id_nfp_net_map);
+DRIVER_REGISTER_KMOD_DEP(nfp,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
/*
* Local variables:
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 82e44b8..a3c6b44 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -1530,5 +1530,9 @@ static struct rte_driver rte_qede_driver = {
PMD_REGISTER_DRIVER(rte_qede_driver, qede);
DRIVER_REGISTER_PCI_TABLE(qede, pci_id_qede_map);
+DRIVER_REGISTER_KMOD_DEP(qede,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
PMD_REGISTER_DRIVER(rte_qedevf_driver, qedevf);
DRIVER_REGISTER_PCI_TABLE(qedevf, pci_id_qedevf_map);
+DRIVER_REGISTER_KMOD_DEP(qedevf,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/szedata2/rte_eth_szedata2.c b/drivers/net/szedata2/rte_eth_szedata2.c
index 483d789..409e71f 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -1602,3 +1602,5 @@ static struct rte_driver rte_szedata2_driver = {
PMD_REGISTER_DRIVER(rte_szedata2_driver, RTE_SZEDATA2_DRIVER_NAME);
DRIVER_REGISTER_PCI_TABLE(RTE_SZEDATA2_DRIVER_NAME, rte_szedata2_pci_id_table);
+DRIVER_REGISTER_KMOD_DEP(RTE_SZEDATA2_DRIVER_NAME,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c
index 4f875c0..8c33df2 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -1785,3 +1785,5 @@ static struct rte_driver rte_nicvf_driver = {
PMD_REGISTER_DRIVER(rte_nicvf_driver, thunderx_nicvf);
DRIVER_REGISTER_PCI_TABLE(thunderx_nicvf, pci_id_nicvf_map);
+DRIVER_REGISTER_KMOD_DEP(thunderx_nicvf,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 07d6449..f65b9a4 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1570,3 +1570,5 @@ static struct rte_driver rte_virtio_driver = {
PMD_REGISTER_DRIVER(rte_virtio_driver, virtio_net);
DRIVER_REGISTER_PCI_TABLE(virtio_net, pci_id_virtio_map);
+DRIVER_REGISTER_KMOD_DEP(virtio_net,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 5874215..d2d07ad 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -955,3 +955,5 @@ static struct rte_driver rte_vmxnet3_driver = {
PMD_REGISTER_DRIVER(rte_vmxnet3_driver, vmxnet3);
DRIVER_REGISTER_PCI_TABLE(vmxnet3, pci_id_vmxnet3_map);
+DRIVER_REGISTER_KMOD_DEP(vmxnet3,
+ "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
diff --git a/lib/librte_eal/common/include/rte_dev.h b/lib/librte_eal/common/include/rte_dev.h
index 95789f9..b721dc3 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -203,6 +203,20 @@ 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 list the name of kernel modules, separated by commas. The
+ * order is important. If several modules lists are possible, they are
+ * separated by colons.
+ *
+ * Example: "uio,igb_uio:uio,uio_pci_generic" means either "uio,igb_uio"
+ * or "uio,uio_pci_generic".
+ */
+#define DRIVER_REGISTER_KMOD_DEP(name, str) \
+static const char DRV_EXP_TAG(name, kmod_dep_export)[] \
+__attribute__((used)) = str
+
#ifdef __cplusplus
}
#endif
diff --git a/tools/dpdk-pmdinfo.py b/tools/dpdk-pmdinfo.py
index 3db9819..17bfed4 100755
--- a/tools/dpdk-pmdinfo.py
+++ b/tools/dpdk-pmdinfo.py
@@ -312,7 +312,10 @@ class ReadElf(object):
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:]
--
2.8.1
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [RFC] drivers: advertise kmod dependencies in pmdinfo
2016-08-26 13:20 [RFC] drivers: advertise kmod dependencies in pmdinfo Olivier Matz
@ 2016-08-30 8:40 ` Matej Vido
2016-08-30 8:56 ` Olivier Matz
2016-08-30 13:23 ` [dpdk-dev, RFC] " Neil Horman
2016-09-15 14:22 ` [PATCH] " Olivier Matz
2 siblings, 1 reply; 46+ messages in thread
From: Matej Vido @ 2016-08-30 8:40 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, nhorman, thomas.monjalon
On 26.08.2016 15:20, Olivier Matz wrote:
> Add a new macro DRIVER_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>
> ---
>
> In this RFC, I supposed that all PCI drivers require a the loading of a
> uio/vfio module (except mlx*), this may be wrong.
> Comments are welcome!
>
>
> buildtools/pmdinfogen/pmdinfogen.c | 1 +
> buildtools/pmdinfogen/pmdinfogen.h | 1 +
> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
> drivers/net/e1000/em_ethdev.c | 2 ++
> drivers/net/e1000/igb_ethdev.c | 4 ++++
> drivers/net/ena/ena_ethdev.c | 2 ++
> drivers/net/enic/enic_ethdev.c | 2 ++
> drivers/net/fm10k/fm10k_ethdev.c | 2 ++
> drivers/net/i40e/i40e_ethdev.c | 2 ++
> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
> drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
> drivers/net/mlx4/mlx4.c | 2 ++
> drivers/net/mlx5/mlx5.c | 3 +++
> drivers/net/nfp/nfp_net.c | 2 ++
> drivers/net/qede/qede_ethdev.c | 4 ++++
> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
> drivers/net/virtio/virtio_ethdev.c | 2 ++
> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
> lib/librte_eal/common/include/rte_dev.h | 14 ++++++++++++++
> tools/dpdk-pmdinfo.py | 5 ++++-
> 24 files changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/buildtools/pmdinfogen/pmdinfogen.c b/buildtools/pmdinfogen/pmdinfogen.c
> index e1bf2e4..1e5b6f3 100644
> --- a/buildtools/pmdinfogen/pmdinfogen.c
> +++ b/buildtools/pmdinfogen/pmdinfogen.c
> @@ -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)
> diff --git a/buildtools/pmdinfogen/pmdinfogen.h b/buildtools/pmdinfogen/pmdinfogen.h
> index 1da2966..2fab2aa 100644
> --- a/buildtools/pmdinfogen/pmdinfogen.h
> +++ b/buildtools/pmdinfogen/pmdinfogen.h
> @@ -85,6 +85,7 @@ else \
>
> enum opt_params {
> PMD_PARAM_STRING = 0,
> + PMD_KMOD_DEP,
> PMD_OPT_MAX
> };
[..]
>
>
> diff --git a/drivers/net/szedata2/rte_eth_szedata2.c b/drivers/net/szedata2/rte_eth_szedata2.c
> index 483d789..409e71f 100644
> --- a/drivers/net/szedata2/rte_eth_szedata2.c
> +++ b/drivers/net/szedata2/rte_eth_szedata2.c
> @@ -1602,3 +1602,5 @@ static struct rte_driver rte_szedata2_driver = {
>
> PMD_REGISTER_DRIVER(rte_szedata2_driver, RTE_SZEDATA2_DRIVER_NAME);
> DRIVER_REGISTER_PCI_TABLE(RTE_SZEDATA2_DRIVER_NAME, rte_szedata2_pci_id_table);
> +DRIVER_REGISTER_KMOD_DEP(RTE_SZEDATA2_DRIVER_NAME,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
Hi Olivier,
szedata2 doesn't require uio/vfio modules. Instead the following lines
could be used:
+DRIVER_REGISTER_KMOD_DEP(RTE_SZEDATA2_DRIVER_NAME,
+ "combo6core,combov3,szedata2,szedata2_cv3");
Thanks,
Matej
[..]
> diff --git a/lib/librte_eal/common/include/rte_dev.h b/lib/librte_eal/common/include/rte_dev.h
> index 95789f9..b721dc3 100644
> --- a/lib/librte_eal/common/include/rte_dev.h
> +++ b/lib/librte_eal/common/include/rte_dev.h
> @@ -203,6 +203,20 @@ 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 list the name of kernel modules, separated by commas. The
> + * order is important. If several modules lists are possible, they are
> + * separated by colons.
> + *
> + * Example: "uio,igb_uio:uio,uio_pci_generic" means either "uio,igb_uio"
> + * or "uio,uio_pci_generic".
> + */
> +#define DRIVER_REGISTER_KMOD_DEP(name, str) \
> +static const char DRV_EXP_TAG(name, kmod_dep_export)[] \
> +__attribute__((used)) = str
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/tools/dpdk-pmdinfo.py b/tools/dpdk-pmdinfo.py
> index 3db9819..17bfed4 100755
> --- a/tools/dpdk-pmdinfo.py
> +++ b/tools/dpdk-pmdinfo.py
> @@ -312,7 +312,10 @@ class ReadElf(object):
> 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:]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC] drivers: advertise kmod dependencies in pmdinfo
2016-08-30 8:40 ` Matej Vido
@ 2016-08-30 8:56 ` Olivier Matz
0 siblings, 0 replies; 46+ messages in thread
From: Olivier Matz @ 2016-08-30 8:56 UTC (permalink / raw)
To: Matej Vido; +Cc: dev, nhorman, thomas.monjalon
Hi Matej,
On 08/30/2016 10:40 AM, Matej Vido wrote:
> On 26.08.2016 15:20, Olivier Matz wrote:
>
>> Add a new macro DRIVER_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>
>> ---
> [..]
>>
>> diff --git a/drivers/net/szedata2/rte_eth_szedata2.c
>> b/drivers/net/szedata2/rte_eth_szedata2.c
>> index 483d789..409e71f 100644
>> --- a/drivers/net/szedata2/rte_eth_szedata2.c
>> +++ b/drivers/net/szedata2/rte_eth_szedata2.c
>> @@ -1602,3 +1602,5 @@ static struct rte_driver rte_szedata2_driver = {
>> PMD_REGISTER_DRIVER(rte_szedata2_driver, RTE_SZEDATA2_DRIVER_NAME);
>> DRIVER_REGISTER_PCI_TABLE(RTE_SZEDATA2_DRIVER_NAME,
>> rte_szedata2_pci_id_table);
>> +DRIVER_REGISTER_KMOD_DEP(RTE_SZEDATA2_DRIVER_NAME,
>> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> Hi Olivier,
>
> szedata2 doesn't require uio/vfio modules. Instead the following lines
> could be used:
>
> +DRIVER_REGISTER_KMOD_DEP(RTE_SZEDATA2_DRIVER_NAME,
> + "combo6core,combov3,szedata2,szedata2_cv3");
>
ok, I will update it for next revision, thanks !
Olivier
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-08-26 13:20 [RFC] drivers: advertise kmod dependencies in pmdinfo Olivier Matz
2016-08-30 8:40 ` Matej Vido
@ 2016-08-30 13:23 ` Neil Horman
2016-08-31 9:21 ` Olivier Matz
2016-09-15 14:22 ` [PATCH] " Olivier Matz
2 siblings, 1 reply; 46+ messages in thread
From: Neil Horman @ 2016-08-30 13:23 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, thomas.monjalon
On Fri, Aug 26, 2016 at 03:20:46PM +0200, Olivier Matz wrote:
> Add a new macro DRIVER_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>
>
> ---
> In this RFC, I supposed that all PCI drivers require a the loading of a
> uio/vfio module (except mlx*), this may be wrong.
> Comments are welcome!
>
>
> buildtools/pmdinfogen/pmdinfogen.c | 1 +
> buildtools/pmdinfogen/pmdinfogen.h | 1 +
> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
> drivers/net/e1000/em_ethdev.c | 2 ++
> drivers/net/e1000/igb_ethdev.c | 4 ++++
> drivers/net/ena/ena_ethdev.c | 2 ++
> drivers/net/enic/enic_ethdev.c | 2 ++
> drivers/net/fm10k/fm10k_ethdev.c | 2 ++
> drivers/net/i40e/i40e_ethdev.c | 2 ++
> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
> drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
> drivers/net/mlx4/mlx4.c | 2 ++
> drivers/net/mlx5/mlx5.c | 3 +++
> drivers/net/nfp/nfp_net.c | 2 ++
> drivers/net/qede/qede_ethdev.c | 4 ++++
> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
> drivers/net/virtio/virtio_ethdev.c | 2 ++
> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
> lib/librte_eal/common/include/rte_dev.h | 14 ++++++++++++++
> tools/dpdk-pmdinfo.py | 5 ++++-
> 24 files changed, 69 insertions(+), 1 deletion(-)
>
Generally speaking, I like the idea, it makes sense to me in terms of using
pmdinfo to export this information
That said, This may need to be a set of macros. By that I mean (and correct me
if I'm wrong here), but the relationship between pmd's and kernel modules is in
some cases, more complex than a 'requires' or 'depends' relationship. That is
to say, some pmd may need user space hardware access, but can use either uio OR
vfio, but doesn't need both, and can continue to function if only one is
available. Other PMD's may be able to use vfio or uio, but can still function
without either. And some, as your patch implements, simply require one or the
other to function. As such it seems like you may want a few macros, in the form
of:
DRIVER_REGISTER_KMOD_REQUEST - List of modules to attempt loading, ignore any
failures
DRIVER_REGISTER_KMOD_REQUIRE - List of modules required to be loaded after
request macro completes, fail if any are not loaded
Thats just spitballing, mind you, theres probably a better way to do it, but the
idea is to list a set of modules you would like to have, and then create a
parsable syntax to describe the modules that need to be loaded after the request
is complete so that you can accurately codify the situations I described above.
Neil
> diff --git a/buildtools/pmdinfogen/pmdinfogen.c b/buildtools/pmdinfogen/pmdinfogen.c
> index e1bf2e4..1e5b6f3 100644
> --- a/buildtools/pmdinfogen/pmdinfogen.c
> +++ b/buildtools/pmdinfogen/pmdinfogen.c
> @@ -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)
> diff --git a/buildtools/pmdinfogen/pmdinfogen.h b/buildtools/pmdinfogen/pmdinfogen.h
> index 1da2966..2fab2aa 100644
> --- a/buildtools/pmdinfogen/pmdinfogen.h
> +++ b/buildtools/pmdinfogen/pmdinfogen.h
> @@ -85,6 +85,7 @@ else \
>
> enum opt_params {
> PMD_PARAM_STRING = 0,
> + PMD_KMOD_DEP,
> PMD_OPT_MAX
> };
>
> diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c b/drivers/crypto/qat/rte_qat_cryptodev.c
> index 82ab047..fc62be9 100644
> --- a/drivers/crypto/qat/rte_qat_cryptodev.c
> +++ b/drivers/crypto/qat/rte_qat_cryptodev.c
> @@ -135,4 +135,6 @@ static struct rte_driver pmd_qat_drv = {
>
> PMD_REGISTER_DRIVER(pmd_qat_drv, CRYPTODEV_NAME_QAT_SYM_PMD);
> DRIVER_REGISTER_PCI_TABLE(CRYPTODEV_NAME_QAT_SYM_PMD, pci_id_qat_map);
> +DRIVER_REGISTER_KMOD_DEP(CRYPTODEV_NAME_QAT_SYM_PMD,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
>
> diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
> index f3ab355..ba8831a 100644
> --- a/drivers/net/bnx2x/bnx2x_ethdev.c
> +++ b/drivers/net/bnx2x/bnx2x_ethdev.c
> @@ -667,5 +667,9 @@ static struct rte_driver rte_bnx2xvf_driver = {
>
> PMD_REGISTER_DRIVER(rte_bnx2x_driver, bnx2x);
> DRIVER_REGISTER_PCI_TABLE(bnx2x, pci_id_bnx2x_map);
> +DRIVER_REGISTER_KMOD_DEP(bnx2x,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> PMD_REGISTER_DRIVER(rte_bnx2xvf_driver, bnx2xvf);
> DRIVER_REGISTER_PCI_TABLE(bnx2xvf, pci_id_bnx2xvf_map);
> +DRIVER_REGISTER_KMOD_DEP(bnx2xvf,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
> index 3795fac..5c6c7b5 100644
> --- a/drivers/net/bnxt/bnxt_ethdev.c
> +++ b/drivers/net/bnxt/bnxt_ethdev.c
> @@ -1068,3 +1068,5 @@ static struct rte_driver bnxt_pmd_drv = {
>
> PMD_REGISTER_DRIVER(bnxt_pmd_drv, bnxt);
> DRIVER_REGISTER_PCI_TABLE(bnxt, bnxt_pci_id_map);
> +DRIVER_REGISTER_KMOD_DEP(bnxt,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
> index 9208a61..cea2741 100644
> --- a/drivers/net/cxgbe/cxgbe_ethdev.c
> +++ b/drivers/net/cxgbe/cxgbe_ethdev.c
> @@ -1068,4 +1068,6 @@ static struct rte_driver rte_cxgbe_driver = {
>
> PMD_REGISTER_DRIVER(rte_cxgbe_driver, cxgb4);
> DRIVER_REGISTER_PCI_TABLE(cxgb4, cxgb4_pci_tbl);
> +DRIVER_REGISTER_KMOD_DEP(cxgb4,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
>
> diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
> index ad104ed..bd0d0ea 100644
> --- a/drivers/net/e1000/em_ethdev.c
> +++ b/drivers/net/e1000/em_ethdev.c
> @@ -1806,3 +1806,5 @@ struct rte_driver em_pmd_drv = {
>
> PMD_REGISTER_DRIVER(em_pmd_drv, em);
> DRIVER_REGISTER_PCI_TABLE(em, pci_id_em_map);
> +DRIVER_REGISTER_KMOD_DEP(em,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
> index 4e9e6a3..a3dfbfe 100644
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -5257,5 +5257,9 @@ eth_igb_configure_msix_intr(struct rte_eth_dev *dev)
>
> PMD_REGISTER_DRIVER(pmd_igb_drv, igb);
> DRIVER_REGISTER_PCI_TABLE(igb, pci_id_igb_map);
> +DRIVER_REGISTER_KMOD_DEP(igb,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> PMD_REGISTER_DRIVER(pmd_igbvf_drv, igbvf);
> DRIVER_REGISTER_PCI_TABLE(igbvf, pci_id_igbvf_map);
> +DRIVER_REGISTER_KMOD_DEP(igbvf,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
> index ac0803d..a45d60c 100644
> --- a/drivers/net/ena/ena_ethdev.c
> +++ b/drivers/net/ena/ena_ethdev.c
> @@ -1709,3 +1709,5 @@ struct rte_driver ena_pmd_drv = {
>
> PMD_REGISTER_DRIVER(ena_pmd_drv, ena);
> DRIVER_REGISTER_PCI_TABLE(ena, pci_id_ena_map);
> +DRIVER_REGISTER_KMOD_DEP(ena,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
> index 47b07c9..a1b8abc 100644
> --- a/drivers/net/enic/enic_ethdev.c
> +++ b/drivers/net/enic/enic_ethdev.c
> @@ -642,3 +642,5 @@ static struct rte_driver rte_enic_driver = {
>
> PMD_REGISTER_DRIVER(rte_enic_driver, enic);
> DRIVER_REGISTER_PCI_TABLE(enic, pci_id_enic_map);
> +DRIVER_REGISTER_KMOD_DEP(enic,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
> index 01f4a72..391ccd7 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -3086,3 +3086,5 @@ static struct rte_driver rte_fm10k_driver = {
>
> PMD_REGISTER_DRIVER(rte_fm10k_driver, fm10k);
> DRIVER_REGISTER_PCI_TABLE(fm10k, pci_id_fm10k_map);
> +DRIVER_REGISTER_KMOD_DEP(fm10k,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index d0aeb70..a1466aa 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -723,6 +723,8 @@ static struct rte_driver rte_i40e_driver = {
>
> PMD_REGISTER_DRIVER(rte_i40e_driver, i40e);
> DRIVER_REGISTER_PCI_TABLE(i40e, pci_id_i40e_map);
> +DRIVER_REGISTER_KMOD_DEP(i40e,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
>
> /*
> * Initialize registers for flexible payload, which should be set by NVM.
> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
> index a616ae0..61be44a 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -1586,6 +1586,8 @@ static struct rte_driver rte_i40evf_driver = {
>
> PMD_REGISTER_DRIVER(rte_i40evf_driver, i40evf);
> DRIVER_REGISTER_PCI_TABLE(i40evf, pci_id_i40evf_map);
> +DRIVER_REGISTER_KMOD_DEP(i40evf,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
>
> static int
> i40evf_dev_configure(struct rte_eth_dev *dev)
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
> index fb618ef..e353d7a 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -7421,5 +7421,9 @@ static struct rte_driver rte_ixgbevf_driver = {
>
> PMD_REGISTER_DRIVER(rte_ixgbe_driver, ixgbe);
> DRIVER_REGISTER_PCI_TABLE(ixgbe, pci_id_ixgbe_map);
> +DRIVER_REGISTER_KMOD_DEP(ixgbe,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> PMD_REGISTER_DRIVER(rte_ixgbevf_driver, ixgbevf);
> DRIVER_REGISTER_PCI_TABLE(ixgbevf, pci_id_ixgbevf_map);
> +DRIVER_REGISTER_KMOD_DEP(ixgbevf,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
> index 304c846..d8f6905 100644
> --- a/drivers/net/mlx4/mlx4.c
> +++ b/drivers/net/mlx4/mlx4.c
> @@ -5948,3 +5948,5 @@ static struct rte_driver rte_mlx4_driver = {
>
> PMD_REGISTER_DRIVER(rte_mlx4_driver, mlx4);
> DRIVER_REGISTER_PCI_TABLE(mlx4, mlx4_pci_id_map);
> +DRIVER_REGISTER_KMOD_DEP(mlx4,
> + "ib_uverbs,mlx4_core,mlx4_en,mlx4_ib");
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
> index d96a9af..29d7332 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -763,3 +763,6 @@ static struct rte_driver rte_mlx5_driver = {
>
> PMD_REGISTER_DRIVER(rte_mlx5_driver, mlx5);
> DRIVER_REGISTER_PCI_TABLE(mlx5, mlx5_pci_id_map);
> +DRIVER_REGISTER_KMOD_DEP(mlx5,
> + "ptp,inet_lro,ib_sa,ib_mad,ib_netlink,ib_addr,"
> + "ib_core,ib_uverbs,mlx5_core,mlx5_ib");
> diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
> index 82e3e4e..f4c8a39 100644
> --- a/drivers/net/nfp/nfp_net.c
> +++ b/drivers/net/nfp/nfp_net.c
> @@ -2488,6 +2488,8 @@ static struct rte_driver rte_nfp_net_driver = {
>
> PMD_REGISTER_DRIVER(rte_nfp_net_driver, nfp);
> DRIVER_REGISTER_PCI_TABLE(nfp, pci_id_nfp_net_map);
> +DRIVER_REGISTER_KMOD_DEP(nfp,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
>
> /*
> * Local variables:
> diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
> index 82e44b8..a3c6b44 100644
> --- a/drivers/net/qede/qede_ethdev.c
> +++ b/drivers/net/qede/qede_ethdev.c
> @@ -1530,5 +1530,9 @@ static struct rte_driver rte_qede_driver = {
>
> PMD_REGISTER_DRIVER(rte_qede_driver, qede);
> DRIVER_REGISTER_PCI_TABLE(qede, pci_id_qede_map);
> +DRIVER_REGISTER_KMOD_DEP(qede,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> PMD_REGISTER_DRIVER(rte_qedevf_driver, qedevf);
> DRIVER_REGISTER_PCI_TABLE(qedevf, pci_id_qedevf_map);
> +DRIVER_REGISTER_KMOD_DEP(qedevf,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> diff --git a/drivers/net/szedata2/rte_eth_szedata2.c b/drivers/net/szedata2/rte_eth_szedata2.c
> index 483d789..409e71f 100644
> --- a/drivers/net/szedata2/rte_eth_szedata2.c
> +++ b/drivers/net/szedata2/rte_eth_szedata2.c
> @@ -1602,3 +1602,5 @@ static struct rte_driver rte_szedata2_driver = {
>
> PMD_REGISTER_DRIVER(rte_szedata2_driver, RTE_SZEDATA2_DRIVER_NAME);
> DRIVER_REGISTER_PCI_TABLE(RTE_SZEDATA2_DRIVER_NAME, rte_szedata2_pci_id_table);
> +DRIVER_REGISTER_KMOD_DEP(RTE_SZEDATA2_DRIVER_NAME,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c
> index 4f875c0..8c33df2 100644
> --- a/drivers/net/thunderx/nicvf_ethdev.c
> +++ b/drivers/net/thunderx/nicvf_ethdev.c
> @@ -1785,3 +1785,5 @@ static struct rte_driver rte_nicvf_driver = {
>
> PMD_REGISTER_DRIVER(rte_nicvf_driver, thunderx_nicvf);
> DRIVER_REGISTER_PCI_TABLE(thunderx_nicvf, pci_id_nicvf_map);
> +DRIVER_REGISTER_KMOD_DEP(thunderx_nicvf,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
> index 07d6449..f65b9a4 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1570,3 +1570,5 @@ static struct rte_driver rte_virtio_driver = {
>
> PMD_REGISTER_DRIVER(rte_virtio_driver, virtio_net);
> DRIVER_REGISTER_PCI_TABLE(virtio_net, pci_id_virtio_map);
> +DRIVER_REGISTER_KMOD_DEP(virtio_net,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
> index 5874215..d2d07ad 100644
> --- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
> +++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
> @@ -955,3 +955,5 @@ static struct rte_driver rte_vmxnet3_driver = {
>
> PMD_REGISTER_DRIVER(rte_vmxnet3_driver, vmxnet3);
> DRIVER_REGISTER_PCI_TABLE(vmxnet3, pci_id_vmxnet3_map);
> +DRIVER_REGISTER_KMOD_DEP(vmxnet3,
> + "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci");
> diff --git a/lib/librte_eal/common/include/rte_dev.h b/lib/librte_eal/common/include/rte_dev.h
> index 95789f9..b721dc3 100644
> --- a/lib/librte_eal/common/include/rte_dev.h
> +++ b/lib/librte_eal/common/include/rte_dev.h
> @@ -203,6 +203,20 @@ 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 list the name of kernel modules, separated by commas. The
> + * order is important. If several modules lists are possible, they are
> + * separated by colons.
> + *
> + * Example: "uio,igb_uio:uio,uio_pci_generic" means either "uio,igb_uio"
> + * or "uio,uio_pci_generic".
> + */
> +#define DRIVER_REGISTER_KMOD_DEP(name, str) \
> +static const char DRV_EXP_TAG(name, kmod_dep_export)[] \
> +__attribute__((used)) = str
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/tools/dpdk-pmdinfo.py b/tools/dpdk-pmdinfo.py
> index 3db9819..17bfed4 100755
> --- a/tools/dpdk-pmdinfo.py
> +++ b/tools/dpdk-pmdinfo.py
> @@ -312,7 +312,10 @@ class ReadElf(object):
> 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:]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-08-30 13:23 ` [dpdk-dev, RFC] " Neil Horman
@ 2016-08-31 9:21 ` Olivier Matz
2016-08-31 13:27 ` Neil Horman
0 siblings, 1 reply; 46+ messages in thread
From: Olivier Matz @ 2016-08-31 9:21 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, thomas.monjalon
Hi Neil,
On 08/30/2016 03:23 PM, Neil Horman wrote:
> On Fri, Aug 26, 2016 at 03:20:46PM +0200, Olivier Matz wrote:
>> Add a new macro DRIVER_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>
>>
>> ---
>> In this RFC, I supposed that all PCI drivers require a the loading of a
>> uio/vfio module (except mlx*), this may be wrong.
>> Comments are welcome!
>>
>>
>> buildtools/pmdinfogen/pmdinfogen.c | 1 +
>> buildtools/pmdinfogen/pmdinfogen.h | 1 +
>> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
>> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
>> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
>> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
>> drivers/net/e1000/em_ethdev.c | 2 ++
>> drivers/net/e1000/igb_ethdev.c | 4 ++++
>> drivers/net/ena/ena_ethdev.c | 2 ++
>> drivers/net/enic/enic_ethdev.c | 2 ++
>> drivers/net/fm10k/fm10k_ethdev.c | 2 ++
>> drivers/net/i40e/i40e_ethdev.c | 2 ++
>> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
>> drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
>> drivers/net/mlx4/mlx4.c | 2 ++
>> drivers/net/mlx5/mlx5.c | 3 +++
>> drivers/net/nfp/nfp_net.c | 2 ++
>> drivers/net/qede/qede_ethdev.c | 4 ++++
>> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
>> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
>> drivers/net/virtio/virtio_ethdev.c | 2 ++
>> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
>> lib/librte_eal/common/include/rte_dev.h | 14 ++++++++++++++
>> tools/dpdk-pmdinfo.py | 5 ++++-
>> 24 files changed, 69 insertions(+), 1 deletion(-)
>>
>
> Generally speaking, I like the idea, it makes sense to me in terms of using
> pmdinfo to export this information
>
> That said, This may need to be a set of macros. By that I mean (and correct me
> if I'm wrong here), but the relationship between pmd's and kernel modules is in
> some cases, more complex than a 'requires' or 'depends' relationship. That is
> to say, some pmd may need user space hardware access, but can use either uio OR
> vfio, but doesn't need both, and can continue to function if only one is
> available. Other PMD's may be able to use vfio or uio, but can still function
> without either. And some, as your patch implements, simply require one or the
> other to function. As such it seems like you may want a few macros, in the form
> of:
>
> DRIVER_REGISTER_KMOD_REQUEST - List of modules to attempt loading, ignore any
> failures
> DRIVER_REGISTER_KMOD_REQUIRE - List of modules required to be loaded after
> request macro completes, fail if any are not loaded
>
> Thats just spitballing, mind you, theres probably a better way to do it, but the
> idea is to list a set of modules you would like to have, and then create a
> parsable syntax to describe the modules that need to be loaded after the request
> is complete so that you can accurately codify the situations I described above.
Thank you for your feedback.
However, I'm not sure I'm perfectly getting what you suggest.
Do you think some PMDs could request a kernel module without really
requiring it? Do you have an example in mind?
The syntax I've submitted lets you define several lists of modules, so
that the user or the script that starts the application can decide which
kmod list is better according to the environment.
For example, most drivers will advertise
"uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci", and the user or script
will have to choose between loading:
- uio igb_uio
- uio uio_pci_generic
- vfio vfio-pci
Olivier
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-08-31 9:21 ` Olivier Matz
@ 2016-08-31 13:27 ` Neil Horman
2016-08-31 13:39 ` Olivier Matz
0 siblings, 1 reply; 46+ messages in thread
From: Neil Horman @ 2016-08-31 13:27 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, thomas.monjalon
On Wed, Aug 31, 2016 at 11:21:18AM +0200, Olivier Matz wrote:
> Hi Neil,
>
> On 08/30/2016 03:23 PM, Neil Horman wrote:
> > On Fri, Aug 26, 2016 at 03:20:46PM +0200, Olivier Matz wrote:
> >> Add a new macro DRIVER_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>
> >>
> >> ---
> >> In this RFC, I supposed that all PCI drivers require a the loading of a
> >> uio/vfio module (except mlx*), this may be wrong.
> >> Comments are welcome!
> >>
> >>
> >> buildtools/pmdinfogen/pmdinfogen.c | 1 +
> >> buildtools/pmdinfogen/pmdinfogen.h | 1 +
> >> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
> >> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
> >> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
> >> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
> >> drivers/net/e1000/em_ethdev.c | 2 ++
> >> drivers/net/e1000/igb_ethdev.c | 4 ++++
> >> drivers/net/ena/ena_ethdev.c | 2 ++
> >> drivers/net/enic/enic_ethdev.c | 2 ++
> >> drivers/net/fm10k/fm10k_ethdev.c | 2 ++
> >> drivers/net/i40e/i40e_ethdev.c | 2 ++
> >> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
> >> drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
> >> drivers/net/mlx4/mlx4.c | 2 ++
> >> drivers/net/mlx5/mlx5.c | 3 +++
> >> drivers/net/nfp/nfp_net.c | 2 ++
> >> drivers/net/qede/qede_ethdev.c | 4 ++++
> >> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
> >> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
> >> drivers/net/virtio/virtio_ethdev.c | 2 ++
> >> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
> >> lib/librte_eal/common/include/rte_dev.h | 14 ++++++++++++++
> >> tools/dpdk-pmdinfo.py | 5 ++++-
> >> 24 files changed, 69 insertions(+), 1 deletion(-)
> >>
> >
> > Generally speaking, I like the idea, it makes sense to me in terms of using
> > pmdinfo to export this information
> >
> > That said, This may need to be a set of macros. By that I mean (and correct me
> > if I'm wrong here), but the relationship between pmd's and kernel modules is in
> > some cases, more complex than a 'requires' or 'depends' relationship. That is
> > to say, some pmd may need user space hardware access, but can use either uio OR
> > vfio, but doesn't need both, and can continue to function if only one is
> > available. Other PMD's may be able to use vfio or uio, but can still function
> > without either. And some, as your patch implements, simply require one or the
> > other to function. As such it seems like you may want a few macros, in the form
> > of:
> >
> > DRIVER_REGISTER_KMOD_REQUEST - List of modules to attempt loading, ignore any
> > failures
> > DRIVER_REGISTER_KMOD_REQUIRE - List of modules required to be loaded after
> > request macro completes, fail if any are not loaded
> >
> > Thats just spitballing, mind you, theres probably a better way to do it, but the
> > idea is to list a set of modules you would like to have, and then create a
> > parsable syntax to describe the modules that need to be loaded after the request
> > is complete so that you can accurately codify the situations I described above.
>
> Thank you for your feedback.
> However, I'm not sure I'm perfectly getting what you suggest.
>
> Do you think some PMDs could request a kernel module without really
> requiring it? Do you have an example in mind?
>
Yes, thats precisely it. The most clear example I could think of (though I'm
not sure if any pmd currently supports this), is a pmd that supports both UIO
and VFIO communication with the kernel. Such a PMD requires that one of those
two modules be loaded, but only one (i.e. both are not required), so if only the
uio kernel module loads is a success case, likewise if only the vfio module
loads can be treated as success. Both loading are clearly successful. Only if
neither load do we have a failure case. I'm suggesting that the grammer that
your exports define should take those cases into account. Its not always as
simple as "I must have the following modules"
> The syntax I've submitted lets you define several lists of modules, so
> that the user or the script that starts the application can decide which
> kmod list is better according to the environment.
>
If you have a human intervening in the module load process, sure, then its fine.
But it seems that this particular feature that you're implemnting might have
automated uses. That is to say the dpdk core library might be interested in
parsing this particular information to direct module autoloading, and if thats
desireable then you need to define these lists such that you can codify failure
and success conditions.
> For example, most drivers will advertise
> "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci", and the user or script
> will have to choose between loading:
> - uio igb_uio
> - uio uio_pci_generic
> - vfio vfio-pci
>
Oh, I see, so your list is a colon delimited list of module load sets, where at
least one set must succeed by loading all modules in its set, but the failure of
any one set isn't fatal to the process? e.g. a string like this:
uio,igb_uio:vfio,vfio-pci
could be interpreted to mean "I must load (uio AND igb_uio) OR (vfio AND
vfio-pci). If the evaluation of that statement results in false, then the
operation fails, otherwise it succedes.
If thats the case, then, apologies, we're on the same page, and this will work
just fine.
Best
Neil
>
> Olivier
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-08-31 13:27 ` Neil Horman
@ 2016-08-31 13:39 ` Olivier Matz
2016-09-01 12:55 ` Trahe, Fiona
0 siblings, 1 reply; 46+ messages in thread
From: Olivier Matz @ 2016-08-31 13:39 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, thomas.monjalon
Hi Neil,
On 08/31/2016 03:27 PM, Neil Horman wrote:
> On Wed, Aug 31, 2016 at 11:21:18AM +0200, Olivier Matz wrote:
>> Hi Neil,
>>
>> On 08/30/2016 03:23 PM, Neil Horman wrote:
>>> On Fri, Aug 26, 2016 at 03:20:46PM +0200, Olivier Matz wrote:
>>>> Add a new macro DRIVER_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>
>>>>
>>>> ---
>>>> In this RFC, I supposed that all PCI drivers require a the loading of a
>>>> uio/vfio module (except mlx*), this may be wrong.
>>>> Comments are welcome!
>>>>
>>>>
>>>> buildtools/pmdinfogen/pmdinfogen.c | 1 +
>>>> buildtools/pmdinfogen/pmdinfogen.h | 1 +
>>>> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
>>>> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
>>>> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
>>>> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
>>>> drivers/net/e1000/em_ethdev.c | 2 ++
>>>> drivers/net/e1000/igb_ethdev.c | 4 ++++
>>>> drivers/net/ena/ena_ethdev.c | 2 ++
>>>> drivers/net/enic/enic_ethdev.c | 2 ++
>>>> drivers/net/fm10k/fm10k_ethdev.c | 2 ++
>>>> drivers/net/i40e/i40e_ethdev.c | 2 ++
>>>> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
>>>> drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
>>>> drivers/net/mlx4/mlx4.c | 2 ++
>>>> drivers/net/mlx5/mlx5.c | 3 +++
>>>> drivers/net/nfp/nfp_net.c | 2 ++
>>>> drivers/net/qede/qede_ethdev.c | 4 ++++
>>>> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
>>>> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
>>>> drivers/net/virtio/virtio_ethdev.c | 2 ++
>>>> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
>>>> lib/librte_eal/common/include/rte_dev.h | 14 ++++++++++++++
>>>> tools/dpdk-pmdinfo.py | 5 ++++-
>>>> 24 files changed, 69 insertions(+), 1 deletion(-)
>>>>
>>>
>>> Generally speaking, I like the idea, it makes sense to me in terms of using
>>> pmdinfo to export this information
>>>
>>> That said, This may need to be a set of macros. By that I mean (and correct me
>>> if I'm wrong here), but the relationship between pmd's and kernel modules is in
>>> some cases, more complex than a 'requires' or 'depends' relationship. That is
>>> to say, some pmd may need user space hardware access, but can use either uio OR
>>> vfio, but doesn't need both, and can continue to function if only one is
>>> available. Other PMD's may be able to use vfio or uio, but can still function
>>> without either. And some, as your patch implements, simply require one or the
>>> other to function. As such it seems like you may want a few macros, in the form
>>> of:
>>>
>>> DRIVER_REGISTER_KMOD_REQUEST - List of modules to attempt loading, ignore any
>>> failures
>>> DRIVER_REGISTER_KMOD_REQUIRE - List of modules required to be loaded after
>>> request macro completes, fail if any are not loaded
>>>
>>> Thats just spitballing, mind you, theres probably a better way to do it, but the
>>> idea is to list a set of modules you would like to have, and then create a
>>> parsable syntax to describe the modules that need to be loaded after the request
>>> is complete so that you can accurately codify the situations I described above.
>>
>> Thank you for your feedback.
>> However, I'm not sure I'm perfectly getting what you suggest.
>>
>> Do you think some PMDs could request a kernel module without really
>> requiring it? Do you have an example in mind?
>>
> Yes, thats precisely it. The most clear example I could think of (though I'm
> not sure if any pmd currently supports this), is a pmd that supports both UIO
> and VFIO communication with the kernel. Such a PMD requires that one of those
> two modules be loaded, but only one (i.e. both are not required), so if only the
> uio kernel module loads is a success case, likewise if only the vfio module
> loads can be treated as success. Both loading are clearly successful. Only if
> neither load do we have a failure case. I'm suggesting that the grammer that
> your exports define should take those cases into account. Its not always as
> simple as "I must have the following modules"
>
>> The syntax I've submitted lets you define several lists of modules, so
>> that the user or the script that starts the application can decide which
>> kmod list is better according to the environment.
>>
> If you have a human intervening in the module load process, sure, then its fine.
> But it seems that this particular feature that you're implemnting might have
> automated uses. That is to say the dpdk core library might be interested in
> parsing this particular information to direct module autoloading, and if thats
> desireable then you need to define these lists such that you can codify failure
> and success conditions.
>
>> For example, most drivers will advertise
>> "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci", and the user or script
>> will have to choose between loading:
>> - uio igb_uio
>> - uio uio_pci_generic
>> - vfio vfio-pci
>>
> Oh, I see, so your list is a colon delimited list of module load sets, where at
> least one set must succeed by loading all modules in its set, but the failure of
> any one set isn't fatal to the process? e.g. a string like this:
>
> uio,igb_uio:vfio,vfio-pci
>
> could be interpreted to mean "I must load (uio AND igb_uio) OR (vfio AND
> vfio-pci). If the evaluation of that statement results in false, then the
> operation fails, otherwise it succedes.
>
> If thats the case, then, apologies, we're on the same page, and this will work
> just fine.
Yep, that's the idea.
Colon and commas are the best separators I've thought about, but any
idea to make the syntax clearer is welcome ;)
Maybe a syntax like is clearer:
"(mod1 & mod2)|(mod3 & mod4)" ?
But it would let the user think that more complex expressions are valid,
like "(mod1 & (mod2 | mod3)) | mod4", which is probably overkill.
Regards,
Olivier
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-08-31 13:39 ` Olivier Matz
@ 2016-09-01 12:55 ` Trahe, Fiona
2016-09-01 17:35 ` Neil Horman
0 siblings, 1 reply; 46+ messages in thread
From: Trahe, Fiona @ 2016-09-01 12:55 UTC (permalink / raw)
To: dev; +Cc: Olivier Matz, nhorman, Thomas Monjalon, Trahe, Fiona
Hi Neil and Olivier,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> Sent: Wednesday, August 31, 2016 2:40 PM
> To: Neil Horman <nhorman@tuxdriver.com>
> Cc: dev@dpdk.org; thomas.monjalon@6wind.com
> Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod dependencies
> in pmdinfo
>
> Hi Neil,
>
> On 08/31/2016 03:27 PM, Neil Horman wrote:
> > On Wed, Aug 31, 2016 at 11:21:18AM +0200, Olivier Matz wrote:
> >> Hi Neil,
> >>
> >> On 08/30/2016 03:23 PM, Neil Horman wrote:
> >>> On Fri, Aug 26, 2016 at 03:20:46PM +0200, Olivier Matz wrote:
> >>>> Add a new macro DRIVER_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>
> >>>>
> >>>> ---
> >>>> In this RFC, I supposed that all PCI drivers require a the loading of a
> >>>> uio/vfio module (except mlx*), this may be wrong.
> >>>> Comments are welcome!
> >>>>
> >>>>
> >>>> buildtools/pmdinfogen/pmdinfogen.c | 1 +
> >>>> buildtools/pmdinfogen/pmdinfogen.h | 1 +
> >>>> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
> >>>> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
> >>>> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
> >>>> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
> >>>> drivers/net/e1000/em_ethdev.c | 2 ++
> >>>> drivers/net/e1000/igb_ethdev.c | 4 ++++
> >>>> drivers/net/ena/ena_ethdev.c | 2 ++
> >>>> drivers/net/enic/enic_ethdev.c | 2 ++
> >>>> drivers/net/fm10k/fm10k_ethdev.c | 2 ++
> >>>> drivers/net/i40e/i40e_ethdev.c | 2 ++
> >>>> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
> >>>> drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
> >>>> drivers/net/mlx4/mlx4.c | 2 ++
> >>>> drivers/net/mlx5/mlx5.c | 3 +++
> >>>> drivers/net/nfp/nfp_net.c | 2 ++
> >>>> drivers/net/qede/qede_ethdev.c | 4 ++++
> >>>> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
> >>>> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
> >>>> drivers/net/virtio/virtio_ethdev.c | 2 ++
> >>>> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
> >>>> lib/librte_eal/common/include/rte_dev.h | 14 ++++++++++++++
> >>>> tools/dpdk-pmdinfo.py | 5 ++++-
> >>>> 24 files changed, 69 insertions(+), 1 deletion(-)
> >>>>
> >>>
> >>> Generally speaking, I like the idea, it makes sense to me in terms of using
> >>> pmdinfo to export this information
> >>>
> >>> That said, This may need to be a set of macros. By that I mean (and correct
> me
> >>> if I'm wrong here), but the relationship between pmd's and kernel modules
> is in
> >>> some cases, more complex than a 'requires' or 'depends' relationship. That
> is
> >>> to say, some pmd may need user space hardware access, but can use either
> uio OR
> >>> vfio, but doesn't need both, and can continue to function if only one is
> >>> available. Other PMD's may be able to use vfio or uio, but can still function
> >>> without either. And some, as your patch implements, simply require one or
> the
> >>> other to function. As such it seems like you may want a few macros, in the
> form
> >>> of:
> >>>
> >>> DRIVER_REGISTER_KMOD_REQUEST - List of modules to attempt loading,
> ignore any
> >>> failures
> >>> DRIVER_REGISTER_KMOD_REQUIRE - List of modules required to be
> loaded after
> >>> request macro completes, fail if any are not loaded
> >>>
> >>> Thats just spitballing, mind you, theres probably a better way to do it, but
> the
> >>> idea is to list a set of modules you would like to have, and then create a
> >>> parsable syntax to describe the modules that need to be loaded after the
> request
> >>> is complete so that you can accurately codify the situations I described
> above.
> >>
> >> Thank you for your feedback.
> >> However, I'm not sure I'm perfectly getting what you suggest.
> >>
> >> Do you think some PMDs could request a kernel module without really
> >> requiring it? Do you have an example in mind?
> >>
> > Yes, thats precisely it. The most clear example I could think of (though I'm
> > not sure if any pmd currently supports this), is a pmd that supports both UIO
> > and VFIO communication with the kernel. Such a PMD requires that one of
> those
> > two modules be loaded, but only one (i.e. both are not required), so if only
> the
> > uio kernel module loads is a success case, likewise if only the vfio module
> > loads can be treated as success. Both loading are clearly successful. Only if
> > neither load do we have a failure case. I'm suggesting that the grammer that
> > your exports define should take those cases into account. Its not always as
> > simple as "I must have the following modules"
> >
> >> The syntax I've submitted lets you define several lists of modules, so
> >> that the user or the script that starts the application can decide which
> >> kmod list is better according to the environment.
> >>
> > If you have a human intervening in the module load process, sure, then its
> fine.
> > But it seems that this particular feature that you're implemnting might have
> > automated uses. That is to say the dpdk core library might be interested in
> > parsing this particular information to direct module autoloading, and if thats
> > desireable then you need to define these lists such that you can codify failure
> > and success conditions.
> >
> >> For example, most drivers will advertise
> >> "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci", and the user or script
> >> will have to choose between loading:
> >> - uio igb_uio
> >> - uio uio_pci_generic
> >> - vfio vfio-pci
> >>
> > Oh, I see, so your list is a colon delimited list of module load sets, where at
> > least one set must succeed by loading all modules in its set, but the failure of
> > any one set isn't fatal to the process? e.g. a string like this:
> >
> > uio,igb_uio:vfio,vfio-pci
> >
> > could be interpreted to mean "I must load (uio AND igb_uio) OR (vfio AND
> > vfio-pci). If the evaluation of that statement results in false, then the
> > operation fails, otherwise it succedes.
> >
> > If thats the case, then, apologies, we're on the same page, and this will work
> > just fine.
>
> Yep, that's the idea.
>
> Colon and commas are the best separators I've thought about, but any
> idea to make the syntax clearer is welcome ;)
>
> Maybe a syntax like is clearer:
> "(mod1 & mod2)|(mod3 & mod4)" ?
> But it would let the user think that more complex expressions are valid,
> like "(mod1 & (mod2 | mod3)) | mod4", which is probably overkill.
>
> Regards,
> Olivier
This RFC seems like a good idea - and something the Intel QuickAssist PMD could benefit from.
However the (mod1 & mod2) can handle the QAT case better in my opinion.
i.e.
as well as needing one of
* uio igb_uio
* uio uio_pci_generic
* vfio vfio-pci
QAT PMD also needs one of (depending on which physical device is plugged)
* qat_dh895xcc
* qat_c62x
* qat_c3xxx
So the original syntax would result in a very long list of possible variations.
What really reflects the dependencies would be
((uio & igb_uio) | (uio & uio_pci_generic) | (vfio & vfio_pci)) & (qat_dh895xcc | qat_c62x | qat_c3xxx)
Also the dependencies on a VM are different to a bare-metal installation, i.e. the qat_xxxx driver just
needs to be loaded in the Host. So maybe this could be satisfied by a separate list?
DRIVER_REGISTER_KMOD_DEP()
DRIVER_REGISTER_KMOD_VM_DEP()
But maybe this is all too complex, and instead the feature should be considered as optional and
not requiring all dependencies to be declared?
Regards,
Fiona
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-09-01 12:55 ` Trahe, Fiona
@ 2016-09-01 17:35 ` Neil Horman
2016-09-01 17:41 ` Stephen Hemminger
0 siblings, 1 reply; 46+ messages in thread
From: Neil Horman @ 2016-09-01 17:35 UTC (permalink / raw)
To: Trahe, Fiona; +Cc: dev, Olivier Matz, Thomas Monjalon
On Thu, Sep 01, 2016 at 12:55:27PM +0000, Trahe, Fiona wrote:
> Hi Neil and Olivier,
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> > Sent: Wednesday, August 31, 2016 2:40 PM
> > To: Neil Horman <nhorman@tuxdriver.com>
> > Cc: dev@dpdk.org; thomas.monjalon@6wind.com
> > Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod dependencies
> > in pmdinfo
> >
> > Hi Neil,
> >
> > On 08/31/2016 03:27 PM, Neil Horman wrote:
> > > On Wed, Aug 31, 2016 at 11:21:18AM +0200, Olivier Matz wrote:
> > >> Hi Neil,
> > >>
> > >> On 08/30/2016 03:23 PM, Neil Horman wrote:
> > >>> On Fri, Aug 26, 2016 at 03:20:46PM +0200, Olivier Matz wrote:
> > >>>> Add a new macro DRIVER_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>
> > >>>>
> > >>>> ---
> > >>>> In this RFC, I supposed that all PCI drivers require a the loading of a
> > >>>> uio/vfio module (except mlx*), this may be wrong.
> > >>>> Comments are welcome!
> > >>>>
> > >>>>
> > >>>> buildtools/pmdinfogen/pmdinfogen.c | 1 +
> > >>>> buildtools/pmdinfogen/pmdinfogen.h | 1 +
> > >>>> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
> > >>>> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
> > >>>> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
> > >>>> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
> > >>>> drivers/net/e1000/em_ethdev.c | 2 ++
> > >>>> drivers/net/e1000/igb_ethdev.c | 4 ++++
> > >>>> drivers/net/ena/ena_ethdev.c | 2 ++
> > >>>> drivers/net/enic/enic_ethdev.c | 2 ++
> > >>>> drivers/net/fm10k/fm10k_ethdev.c | 2 ++
> > >>>> drivers/net/i40e/i40e_ethdev.c | 2 ++
> > >>>> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
> > >>>> drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
> > >>>> drivers/net/mlx4/mlx4.c | 2 ++
> > >>>> drivers/net/mlx5/mlx5.c | 3 +++
> > >>>> drivers/net/nfp/nfp_net.c | 2 ++
> > >>>> drivers/net/qede/qede_ethdev.c | 4 ++++
> > >>>> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
> > >>>> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
> > >>>> drivers/net/virtio/virtio_ethdev.c | 2 ++
> > >>>> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
> > >>>> lib/librte_eal/common/include/rte_dev.h | 14 ++++++++++++++
> > >>>> tools/dpdk-pmdinfo.py | 5 ++++-
> > >>>> 24 files changed, 69 insertions(+), 1 deletion(-)
> > >>>>
> > >>>
> > >>> Generally speaking, I like the idea, it makes sense to me in terms of using
> > >>> pmdinfo to export this information
> > >>>
> > >>> That said, This may need to be a set of macros. By that I mean (and correct
> > me
> > >>> if I'm wrong here), but the relationship between pmd's and kernel modules
> > is in
> > >>> some cases, more complex than a 'requires' or 'depends' relationship. That
> > is
> > >>> to say, some pmd may need user space hardware access, but can use either
> > uio OR
> > >>> vfio, but doesn't need both, and can continue to function if only one is
> > >>> available. Other PMD's may be able to use vfio or uio, but can still function
> > >>> without either. And some, as your patch implements, simply require one or
> > the
> > >>> other to function. As such it seems like you may want a few macros, in the
> > form
> > >>> of:
> > >>>
> > >>> DRIVER_REGISTER_KMOD_REQUEST - List of modules to attempt loading,
> > ignore any
> > >>> failures
> > >>> DRIVER_REGISTER_KMOD_REQUIRE - List of modules required to be
> > loaded after
> > >>> request macro completes, fail if any are not loaded
> > >>>
> > >>> Thats just spitballing, mind you, theres probably a better way to do it, but
> > the
> > >>> idea is to list a set of modules you would like to have, and then create a
> > >>> parsable syntax to describe the modules that need to be loaded after the
> > request
> > >>> is complete so that you can accurately codify the situations I described
> > above.
> > >>
> > >> Thank you for your feedback.
> > >> However, I'm not sure I'm perfectly getting what you suggest.
> > >>
> > >> Do you think some PMDs could request a kernel module without really
> > >> requiring it? Do you have an example in mind?
> > >>
> > > Yes, thats precisely it. The most clear example I could think of (though I'm
> > > not sure if any pmd currently supports this), is a pmd that supports both UIO
> > > and VFIO communication with the kernel. Such a PMD requires that one of
> > those
> > > two modules be loaded, but only one (i.e. both are not required), so if only
> > the
> > > uio kernel module loads is a success case, likewise if only the vfio module
> > > loads can be treated as success. Both loading are clearly successful. Only if
> > > neither load do we have a failure case. I'm suggesting that the grammer that
> > > your exports define should take those cases into account. Its not always as
> > > simple as "I must have the following modules"
> > >
> > >> The syntax I've submitted lets you define several lists of modules, so
> > >> that the user or the script that starts the application can decide which
> > >> kmod list is better according to the environment.
> > >>
> > > If you have a human intervening in the module load process, sure, then its
> > fine.
> > > But it seems that this particular feature that you're implemnting might have
> > > automated uses. That is to say the dpdk core library might be interested in
> > > parsing this particular information to direct module autoloading, and if thats
> > > desireable then you need to define these lists such that you can codify failure
> > > and success conditions.
> > >
> > >> For example, most drivers will advertise
> > >> "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci", and the user or script
> > >> will have to choose between loading:
> > >> - uio igb_uio
> > >> - uio uio_pci_generic
> > >> - vfio vfio-pci
> > >>
> > > Oh, I see, so your list is a colon delimited list of module load sets, where at
> > > least one set must succeed by loading all modules in its set, but the failure of
> > > any one set isn't fatal to the process? e.g. a string like this:
> > >
> > > uio,igb_uio:vfio,vfio-pci
> > >
> > > could be interpreted to mean "I must load (uio AND igb_uio) OR (vfio AND
> > > vfio-pci). If the evaluation of that statement results in false, then the
> > > operation fails, otherwise it succedes.
> > >
> > > If thats the case, then, apologies, we're on the same page, and this will work
> > > just fine.
> >
> > Yep, that's the idea.
> >
> > Colon and commas are the best separators I've thought about, but any
> > idea to make the syntax clearer is welcome ;)
> >
> > Maybe a syntax like is clearer:
> > "(mod1 & mod2)|(mod3 & mod4)" ?
> > But it would let the user think that more complex expressions are valid,
> > like "(mod1 & (mod2 | mod3)) | mod4", which is probably overkill.
> >
> > Regards,
> > Olivier
>
> This RFC seems like a good idea - and something the Intel QuickAssist PMD could benefit from.
> However the (mod1 & mod2) can handle the QAT case better in my opinion.
> i.e.
> as well as needing one of
> * uio igb_uio
> * uio uio_pci_generic
> * vfio vfio-pci
> QAT PMD also needs one of (depending on which physical device is plugged)
> * qat_dh895xcc
> * qat_c62x
> * qat_c3xxx
>
> So the original syntax would result in a very long list of possible variations.
> What really reflects the dependencies would be
> ((uio & igb_uio) | (uio & uio_pci_generic) | (vfio & vfio_pci)) & (qat_dh895xcc | qat_c62x | qat_c3xxx)
>
Ah, I didn't consider that hardware specifics might create a use case where a
pmd must have one or more kernel modules available for hw support. Perhaps it
is worthwhile to automate hardware support - that is to say, any module loading
script should automatically look at the pci table exported from a pmd, and, if
found, load any modules that claim support for that device:vendor tuple? Though
that might break in the case of uio, if there are separate driver modules that
support native hardware and uio access.
> Also the dependencies on a VM are different to a bare-metal installation, i.e. the qat_xxxx driver just
> needs to be loaded in the Host. So maybe this could be satisfied by a separate list?
> DRIVER_REGISTER_KMOD_DEP()
> DRIVER_REGISTER_KMOD_VM_DEP()
>
This makes me a bit nervous, Ideally, nothing should have to know if its running
on bare metal or in a vm, we should try to avoid vm specific macros if possible.
Not sure what the alternative is yet, though.
> But maybe this is all too complex, and instead the feature should be considered as optional and
> not requiring all dependencies to be declared?
>
> Regards,
> Fiona
>
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-09-01 17:35 ` Neil Horman
@ 2016-09-01 17:41 ` Stephen Hemminger
2016-09-01 19:15 ` Neil Horman
2016-09-02 10:55 ` Thomas Monjalon
0 siblings, 2 replies; 46+ messages in thread
From: Stephen Hemminger @ 2016-09-01 17:41 UTC (permalink / raw)
To: Neil Horman; +Cc: Trahe, Fiona, dev, Olivier Matz, Thomas Monjalon
On Thu, 1 Sep 2016 13:35:19 -0400
Neil Horman <nhorman@tuxdriver.com> wrote:
> On Thu, Sep 01, 2016 at 12:55:27PM +0000, Trahe, Fiona wrote:
> > Hi Neil and Olivier,
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> > > Sent: Wednesday, August 31, 2016 2:40 PM
> > > To: Neil Horman <nhorman@tuxdriver.com>
> > > Cc: dev@dpdk.org; thomas.monjalon@6wind.com
> > > Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod dependencies
> > > in pmdinfo
> > >
> > > Hi Neil,
> > >
> > > On 08/31/2016 03:27 PM, Neil Horman wrote:
> > > > On Wed, Aug 31, 2016 at 11:21:18AM +0200, Olivier Matz wrote:
> > > >> Hi Neil,
> > > >>
> > > >> On 08/30/2016 03:23 PM, Neil Horman wrote:
> > > >>> On Fri, Aug 26, 2016 at 03:20:46PM +0200, Olivier Matz wrote:
> > > >>>> Add a new macro DRIVER_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>
> > > >>>>
> > > >>>> ---
> > > >>>> In this RFC, I supposed that all PCI drivers require a the loading of a
> > > >>>> uio/vfio module (except mlx*), this may be wrong.
> > > >>>> Comments are welcome!
> > > >>>>
> > > >>>>
> > > >>>> buildtools/pmdinfogen/pmdinfogen.c | 1 +
> > > >>>> buildtools/pmdinfogen/pmdinfogen.h | 1 +
> > > >>>> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
> > > >>>> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
> > > >>>> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
> > > >>>> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
> > > >>>> drivers/net/e1000/em_ethdev.c | 2 ++
> > > >>>> drivers/net/e1000/igb_ethdev.c | 4 ++++
> > > >>>> drivers/net/ena/ena_ethdev.c | 2 ++
> > > >>>> drivers/net/enic/enic_ethdev.c | 2 ++
> > > >>>> drivers/net/fm10k/fm10k_ethdev.c | 2 ++
> > > >>>> drivers/net/i40e/i40e_ethdev.c | 2 ++
> > > >>>> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
> > > >>>> drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
> > > >>>> drivers/net/mlx4/mlx4.c | 2 ++
> > > >>>> drivers/net/mlx5/mlx5.c | 3 +++
> > > >>>> drivers/net/nfp/nfp_net.c | 2 ++
> > > >>>> drivers/net/qede/qede_ethdev.c | 4 ++++
> > > >>>> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
> > > >>>> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
> > > >>>> drivers/net/virtio/virtio_ethdev.c | 2 ++
> > > >>>> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
> > > >>>> lib/librte_eal/common/include/rte_dev.h | 14 ++++++++++++++
> > > >>>> tools/dpdk-pmdinfo.py | 5 ++++-
> > > >>>> 24 files changed, 69 insertions(+), 1 deletion(-)
> > > >>>>
> > > >>>
> > > >>> Generally speaking, I like the idea, it makes sense to me in terms of using
> > > >>> pmdinfo to export this information
> > > >>>
> > > >>> That said, This may need to be a set of macros. By that I mean (and correct
> > > me
> > > >>> if I'm wrong here), but the relationship between pmd's and kernel modules
> > > is in
> > > >>> some cases, more complex than a 'requires' or 'depends' relationship. That
> > > is
> > > >>> to say, some pmd may need user space hardware access, but can use either
> > > uio OR
> > > >>> vfio, but doesn't need both, and can continue to function if only one is
> > > >>> available. Other PMD's may be able to use vfio or uio, but can still function
> > > >>> without either. And some, as your patch implements, simply require one or
> > > the
> > > >>> other to function. As such it seems like you may want a few macros, in the
> > > form
> > > >>> of:
> > > >>>
> > > >>> DRIVER_REGISTER_KMOD_REQUEST - List of modules to attempt loading,
> > > ignore any
> > > >>> failures
> > > >>> DRIVER_REGISTER_KMOD_REQUIRE - List of modules required to be
> > > loaded after
> > > >>> request macro completes, fail if any are not loaded
> > > >>>
> > > >>> Thats just spitballing, mind you, theres probably a better way to do it, but
> > > the
> > > >>> idea is to list a set of modules you would like to have, and then create a
> > > >>> parsable syntax to describe the modules that need to be loaded after the
> > > request
> > > >>> is complete so that you can accurately codify the situations I described
> > > above.
> > > >>
> > > >> Thank you for your feedback.
> > > >> However, I'm not sure I'm perfectly getting what you suggest.
> > > >>
> > > >> Do you think some PMDs could request a kernel module without really
> > > >> requiring it? Do you have an example in mind?
> > > >>
> > > > Yes, thats precisely it. The most clear example I could think of (though I'm
> > > > not sure if any pmd currently supports this), is a pmd that supports both UIO
> > > > and VFIO communication with the kernel. Such a PMD requires that one of
> > > those
> > > > two modules be loaded, but only one (i.e. both are not required), so if only
> > > the
> > > > uio kernel module loads is a success case, likewise if only the vfio module
> > > > loads can be treated as success. Both loading are clearly successful. Only if
> > > > neither load do we have a failure case. I'm suggesting that the grammer that
> > > > your exports define should take those cases into account. Its not always as
> > > > simple as "I must have the following modules"
> > > >
> > > >> The syntax I've submitted lets you define several lists of modules, so
> > > >> that the user or the script that starts the application can decide which
> > > >> kmod list is better according to the environment.
> > > >>
> > > > If you have a human intervening in the module load process, sure, then its
> > > fine.
> > > > But it seems that this particular feature that you're implemnting might have
> > > > automated uses. That is to say the dpdk core library might be interested in
> > > > parsing this particular information to direct module autoloading, and if thats
> > > > desireable then you need to define these lists such that you can codify failure
> > > > and success conditions.
> > > >
> > > >> For example, most drivers will advertise
> > > >> "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci", and the user or script
> > > >> will have to choose between loading:
> > > >> - uio igb_uio
> > > >> - uio uio_pci_generic
> > > >> - vfio vfio-pci
> > > >>
> > > > Oh, I see, so your list is a colon delimited list of module load sets, where at
> > > > least one set must succeed by loading all modules in its set, but the failure of
> > > > any one set isn't fatal to the process? e.g. a string like this:
> > > >
> > > > uio,igb_uio:vfio,vfio-pci
> > > >
> > > > could be interpreted to mean "I must load (uio AND igb_uio) OR (vfio AND
> > > > vfio-pci). If the evaluation of that statement results in false, then the
> > > > operation fails, otherwise it succedes.
> > > >
> > > > If thats the case, then, apologies, we're on the same page, and this will work
> > > > just fine.
> > >
> > > Yep, that's the idea.
> > >
> > > Colon and commas are the best separators I've thought about, but any
> > > idea to make the syntax clearer is welcome ;)
> > >
> > > Maybe a syntax like is clearer:
> > > "(mod1 & mod2)|(mod3 & mod4)" ?
> > > But it would let the user think that more complex expressions are valid,
> > > like "(mod1 & (mod2 | mod3)) | mod4", which is probably overkill.
> > >
> > > Regards,
> > > Olivier
> >
> > This RFC seems like a good idea - and something the Intel QuickAssist PMD could benefit from.
> > However the (mod1 & mod2) can handle the QAT case better in my opinion.
> > i.e.
> > as well as needing one of
> > * uio igb_uio
> > * uio uio_pci_generic
> > * vfio vfio-pci
> > QAT PMD also needs one of (depending on which physical device is plugged)
> > * qat_dh895xcc
> > * qat_c62x
> > * qat_c3xxx
> >
> > So the original syntax would result in a very long list of possible variations.
> > What really reflects the dependencies would be
> > ((uio & igb_uio) | (uio & uio_pci_generic) | (vfio & vfio_pci)) & (qat_dh895xcc | qat_c62x | qat_c3xxx)
> >
> Ah, I didn't consider that hardware specifics might create a use case where a
> pmd must have one or more kernel modules available for hw support. Perhaps it
> is worthwhile to automate hardware support - that is to say, any module loading
> script should automatically look at the pci table exported from a pmd, and, if
> found, load any modules that claim support for that device:vendor tuple? Though
> that might break in the case of uio, if there are separate driver modules that
> support native hardware and uio access.
I ended up writing a script that went the other way.
First look at the hardware and load VFIO if IOMMU is available.
Then look for special driver needed for Xen and HyperV
Lastly fallback to loading igb_uio if no VFIO and PCI device present.
In other words it is a system not driver issue.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-09-01 17:41 ` Stephen Hemminger
@ 2016-09-01 19:15 ` Neil Horman
2016-09-02 9:19 ` Trahe, Fiona
2016-09-02 10:55 ` Thomas Monjalon
1 sibling, 1 reply; 46+ messages in thread
From: Neil Horman @ 2016-09-01 19:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Trahe, Fiona, dev, Olivier Matz, Thomas Monjalon
On Thu, Sep 01, 2016 at 10:41:22AM -0700, Stephen Hemminger wrote:
> On Thu, 1 Sep 2016 13:35:19 -0400
> Neil Horman <nhorman@tuxdriver.com> wrote:
>
> > On Thu, Sep 01, 2016 at 12:55:27PM +0000, Trahe, Fiona wrote:
> > > Hi Neil and Olivier,
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> > > > Sent: Wednesday, August 31, 2016 2:40 PM
> > > > To: Neil Horman <nhorman@tuxdriver.com>
> > > > Cc: dev@dpdk.org; thomas.monjalon@6wind.com
> > > > Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod dependencies
> > > > in pmdinfo
> > > >
> > > > Hi Neil,
> > > >
> > > > On 08/31/2016 03:27 PM, Neil Horman wrote:
> > > > > On Wed, Aug 31, 2016 at 11:21:18AM +0200, Olivier Matz wrote:
> > > > >> Hi Neil,
> > > > >>
> > > > >> On 08/30/2016 03:23 PM, Neil Horman wrote:
> > > > >>> On Fri, Aug 26, 2016 at 03:20:46PM +0200, Olivier Matz wrote:
> > > > >>>> Add a new macro DRIVER_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>
> > > > >>>>
> > > > >>>> ---
> > > > >>>> In this RFC, I supposed that all PCI drivers require a the loading of a
> > > > >>>> uio/vfio module (except mlx*), this may be wrong.
> > > > >>>> Comments are welcome!
> > > > >>>>
> > > > >>>>
> > > > >>>> buildtools/pmdinfogen/pmdinfogen.c | 1 +
> > > > >>>> buildtools/pmdinfogen/pmdinfogen.h | 1 +
> > > > >>>> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
> > > > >>>> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
> > > > >>>> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
> > > > >>>> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
> > > > >>>> drivers/net/e1000/em_ethdev.c | 2 ++
> > > > >>>> drivers/net/e1000/igb_ethdev.c | 4 ++++
> > > > >>>> drivers/net/ena/ena_ethdev.c | 2 ++
> > > > >>>> drivers/net/enic/enic_ethdev.c | 2 ++
> > > > >>>> drivers/net/fm10k/fm10k_ethdev.c | 2 ++
> > > > >>>> drivers/net/i40e/i40e_ethdev.c | 2 ++
> > > > >>>> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
> > > > >>>> drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
> > > > >>>> drivers/net/mlx4/mlx4.c | 2 ++
> > > > >>>> drivers/net/mlx5/mlx5.c | 3 +++
> > > > >>>> drivers/net/nfp/nfp_net.c | 2 ++
> > > > >>>> drivers/net/qede/qede_ethdev.c | 4 ++++
> > > > >>>> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
> > > > >>>> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
> > > > >>>> drivers/net/virtio/virtio_ethdev.c | 2 ++
> > > > >>>> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
> > > > >>>> lib/librte_eal/common/include/rte_dev.h | 14 ++++++++++++++
> > > > >>>> tools/dpdk-pmdinfo.py | 5 ++++-
> > > > >>>> 24 files changed, 69 insertions(+), 1 deletion(-)
> > > > >>>>
> > > > >>>
> > > > >>> Generally speaking, I like the idea, it makes sense to me in terms of using
> > > > >>> pmdinfo to export this information
> > > > >>>
> > > > >>> That said, This may need to be a set of macros. By that I mean (and correct
> > > > me
> > > > >>> if I'm wrong here), but the relationship between pmd's and kernel modules
> > > > is in
> > > > >>> some cases, more complex than a 'requires' or 'depends' relationship. That
> > > > is
> > > > >>> to say, some pmd may need user space hardware access, but can use either
> > > > uio OR
> > > > >>> vfio, but doesn't need both, and can continue to function if only one is
> > > > >>> available. Other PMD's may be able to use vfio or uio, but can still function
> > > > >>> without either. And some, as your patch implements, simply require one or
> > > > the
> > > > >>> other to function. As such it seems like you may want a few macros, in the
> > > > form
> > > > >>> of:
> > > > >>>
> > > > >>> DRIVER_REGISTER_KMOD_REQUEST - List of modules to attempt loading,
> > > > ignore any
> > > > >>> failures
> > > > >>> DRIVER_REGISTER_KMOD_REQUIRE - List of modules required to be
> > > > loaded after
> > > > >>> request macro completes, fail if any are not loaded
> > > > >>>
> > > > >>> Thats just spitballing, mind you, theres probably a better way to do it, but
> > > > the
> > > > >>> idea is to list a set of modules you would like to have, and then create a
> > > > >>> parsable syntax to describe the modules that need to be loaded after the
> > > > request
> > > > >>> is complete so that you can accurately codify the situations I described
> > > > above.
> > > > >>
> > > > >> Thank you for your feedback.
> > > > >> However, I'm not sure I'm perfectly getting what you suggest.
> > > > >>
> > > > >> Do you think some PMDs could request a kernel module without really
> > > > >> requiring it? Do you have an example in mind?
> > > > >>
> > > > > Yes, thats precisely it. The most clear example I could think of (though I'm
> > > > > not sure if any pmd currently supports this), is a pmd that supports both UIO
> > > > > and VFIO communication with the kernel. Such a PMD requires that one of
> > > > those
> > > > > two modules be loaded, but only one (i.e. both are not required), so if only
> > > > the
> > > > > uio kernel module loads is a success case, likewise if only the vfio module
> > > > > loads can be treated as success. Both loading are clearly successful. Only if
> > > > > neither load do we have a failure case. I'm suggesting that the grammer that
> > > > > your exports define should take those cases into account. Its not always as
> > > > > simple as "I must have the following modules"
> > > > >
> > > > >> The syntax I've submitted lets you define several lists of modules, so
> > > > >> that the user or the script that starts the application can decide which
> > > > >> kmod list is better according to the environment.
> > > > >>
> > > > > If you have a human intervening in the module load process, sure, then its
> > > > fine.
> > > > > But it seems that this particular feature that you're implemnting might have
> > > > > automated uses. That is to say the dpdk core library might be interested in
> > > > > parsing this particular information to direct module autoloading, and if thats
> > > > > desireable then you need to define these lists such that you can codify failure
> > > > > and success conditions.
> > > > >
> > > > >> For example, most drivers will advertise
> > > > >> "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci", and the user or script
> > > > >> will have to choose between loading:
> > > > >> - uio igb_uio
> > > > >> - uio uio_pci_generic
> > > > >> - vfio vfio-pci
> > > > >>
> > > > > Oh, I see, so your list is a colon delimited list of module load sets, where at
> > > > > least one set must succeed by loading all modules in its set, but the failure of
> > > > > any one set isn't fatal to the process? e.g. a string like this:
> > > > >
> > > > > uio,igb_uio:vfio,vfio-pci
> > > > >
> > > > > could be interpreted to mean "I must load (uio AND igb_uio) OR (vfio AND
> > > > > vfio-pci). If the evaluation of that statement results in false, then the
> > > > > operation fails, otherwise it succedes.
> > > > >
> > > > > If thats the case, then, apologies, we're on the same page, and this will work
> > > > > just fine.
> > > >
> > > > Yep, that's the idea.
> > > >
> > > > Colon and commas are the best separators I've thought about, but any
> > > > idea to make the syntax clearer is welcome ;)
> > > >
> > > > Maybe a syntax like is clearer:
> > > > "(mod1 & mod2)|(mod3 & mod4)" ?
> > > > But it would let the user think that more complex expressions are valid,
> > > > like "(mod1 & (mod2 | mod3)) | mod4", which is probably overkill.
> > > >
> > > > Regards,
> > > > Olivier
> > >
> > > This RFC seems like a good idea - and something the Intel QuickAssist PMD could benefit from.
> > > However the (mod1 & mod2) can handle the QAT case better in my opinion.
> > > i.e.
> > > as well as needing one of
> > > * uio igb_uio
> > > * uio uio_pci_generic
> > > * vfio vfio-pci
> > > QAT PMD also needs one of (depending on which physical device is plugged)
> > > * qat_dh895xcc
> > > * qat_c62x
> > > * qat_c3xxx
> > >
> > > So the original syntax would result in a very long list of possible variations.
> > > What really reflects the dependencies would be
> > > ((uio & igb_uio) | (uio & uio_pci_generic) | (vfio & vfio_pci)) & (qat_dh895xcc | qat_c62x | qat_c3xxx)
> > >
> > Ah, I didn't consider that hardware specifics might create a use case where a
> > pmd must have one or more kernel modules available for hw support. Perhaps it
> > is worthwhile to automate hardware support - that is to say, any module loading
> > script should automatically look at the pci table exported from a pmd, and, if
> > found, load any modules that claim support for that device:vendor tuple? Though
> > that might break in the case of uio, if there are separate driver modules that
> > support native hardware and uio access.
>
> I ended up writing a script that went the other way.
> First look at the hardware and load VFIO if IOMMU is available.
> Then look for special driver needed for Xen and HyperV
> Lastly fallback to loading igb_uio if no VFIO and PCI device present.
>
> In other words it is a system not driver issue.
>
That sounds like a reasonable approach, yes.
Neil
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-09-01 19:15 ` Neil Horman
@ 2016-09-02 9:19 ` Trahe, Fiona
2016-09-02 13:33 ` Neil Horman
0 siblings, 1 reply; 46+ messages in thread
From: Trahe, Fiona @ 2016-09-02 9:19 UTC (permalink / raw)
To: Neil Horman, Stephen Hemminger
Cc: dev, Olivier Matz, Thomas Monjalon, Trahe, Fiona
> -----Original Message-----
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Thursday, September 1, 2016 8:16 PM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Trahe, Fiona <fiona.trahe@intel.com>; dev@dpdk.org; Olivier Matz
> <olivier.matz@6wind.com>; Thomas Monjalon
> <thomas.monjalon@6wind.com>
> Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod dependencies
> in pmdinfo
>
> On Thu, Sep 01, 2016 at 10:41:22AM -0700, Stephen Hemminger wrote:
> > On Thu, 1 Sep 2016 13:35:19 -0400
> > Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > > On Thu, Sep 01, 2016 at 12:55:27PM +0000, Trahe, Fiona wrote:
> > > > Hi Neil and Olivier,
> > > >
> > > > > -----Original Message-----
> > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier
> > > > > Matz
> > > > > Sent: Wednesday, August 31, 2016 2:40 PM
> > > > > To: Neil Horman <nhorman@tuxdriver.com>
> > > > > Cc: dev@dpdk.org; thomas.monjalon@6wind.com
> > > > > Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod
> > > > > dependencies in pmdinfo
> > > > >
> > > > > Hi Neil,
> > > > >
> > > > > On 08/31/2016 03:27 PM, Neil Horman wrote:
> > > > > > On Wed, Aug 31, 2016 at 11:21:18AM +0200, Olivier Matz wrote:
> > > > > >> Hi Neil,
> > > > > >>
> > > > > >> On 08/30/2016 03:23 PM, Neil Horman wrote:
> > > > > >>> On Fri, Aug 26, 2016 at 03:20:46PM +0200, Olivier Matz wrote:
> > > > > >>>> Add a new macro DRIVER_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>
> > > > > >>>>
> > > > > >>>> ---
> > > > > >>>> In this RFC, I supposed that all PCI drivers require a the
> > > > > >>>> loading of a uio/vfio module (except mlx*), this may be wrong.
> > > > > >>>> Comments are welcome!
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> buildtools/pmdinfogen/pmdinfogen.c | 1 +
> > > > > >>>> buildtools/pmdinfogen/pmdinfogen.h | 1 +
> > > > > >>>> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
> > > > > >>>> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
> > > > > >>>> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
> > > > > >>>> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
> > > > > >>>> drivers/net/e1000/em_ethdev.c | 2 ++
> > > > > >>>> drivers/net/e1000/igb_ethdev.c | 4 ++++
> > > > > >>>> drivers/net/ena/ena_ethdev.c | 2 ++
> > > > > >>>> drivers/net/enic/enic_ethdev.c | 2 ++
> > > > > >>>> drivers/net/fm10k/fm10k_ethdev.c | 2 ++
> > > > > >>>> drivers/net/i40e/i40e_ethdev.c | 2 ++
> > > > > >>>> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
> > > > > >>>> drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
> > > > > >>>> drivers/net/mlx4/mlx4.c | 2 ++
> > > > > >>>> drivers/net/mlx5/mlx5.c | 3 +++
> > > > > >>>> drivers/net/nfp/nfp_net.c | 2 ++
> > > > > >>>> drivers/net/qede/qede_ethdev.c | 4 ++++
> > > > > >>>> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
> > > > > >>>> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
> > > > > >>>> drivers/net/virtio/virtio_ethdev.c | 2 ++
> > > > > >>>> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
> > > > > >>>> lib/librte_eal/common/include/rte_dev.h | 14 ++++++++++++++
> > > > > >>>> tools/dpdk-pmdinfo.py | 5 ++++-
> > > > > >>>> 24 files changed, 69 insertions(+), 1 deletion(-)
> > > > > >>>>
> > > > > >>>
> > > > > >>> Generally speaking, I like the idea, it makes sense to me in
> > > > > >>> terms of using pmdinfo to export this information
> > > > > >>>
> > > > > >>> That said, This may need to be a set of macros. By that I
> > > > > >>> mean (and correct
> > > > > me
> > > > > >>> if I'm wrong here), but the relationship between pmd's and
> > > > > >>> kernel modules
> > > > > is in
> > > > > >>> some cases, more complex than a 'requires' or 'depends'
> > > > > >>> relationship. That
> > > > > is
> > > > > >>> to say, some pmd may need user space hardware access, but
> > > > > >>> can use either
> > > > > uio OR
> > > > > >>> vfio, but doesn't need both, and can continue to function if
> > > > > >>> only one is available. Other PMD's may be able to use vfio
> > > > > >>> or uio, but can still function without either. And some, as
> > > > > >>> your patch implements, simply require one or
> > > > > the
> > > > > >>> other to function. As such it seems like you may want a few
> > > > > >>> macros, in the
> > > > > form
> > > > > >>> of:
> > > > > >>>
> > > > > >>> DRIVER_REGISTER_KMOD_REQUEST - List of modules to attempt
> > > > > >>> loading,
> > > > > ignore any
> > > > > >>> failures
> > > > > >>> DRIVER_REGISTER_KMOD_REQUIRE - List of modules required to
> > > > > >>> be
> > > > > loaded after
> > > > > >>> request macro completes, fail if any are not loaded
> > > > > >>>
> > > > > >>> Thats just spitballing, mind you, theres probably a better
> > > > > >>> way to do it, but
> > > > > the
> > > > > >>> idea is to list a set of modules you would like to have, and
> > > > > >>> then create a parsable syntax to describe the modules that
> > > > > >>> need to be loaded after the
> > > > > request
> > > > > >>> is complete so that you can accurately codify the situations
> > > > > >>> I described
> > > > > above.
> > > > > >>
> > > > > >> Thank you for your feedback.
> > > > > >> However, I'm not sure I'm perfectly getting what you suggest.
> > > > > >>
> > > > > >> Do you think some PMDs could request a kernel module without
> > > > > >> really requiring it? Do you have an example in mind?
> > > > > >>
> > > > > > Yes, thats precisely it. The most clear example I could think
> > > > > > of (though I'm not sure if any pmd currently supports this),
> > > > > > is a pmd that supports both UIO and VFIO communication with
> > > > > > the kernel. Such a PMD requires that one of
> > > > > those
> > > > > > two modules be loaded, but only one (i.e. both are not
> > > > > > required), so if only
> > > > > the
> > > > > > uio kernel module loads is a success case, likewise if only
> > > > > > the vfio module loads can be treated as success. Both loading
> > > > > > are clearly successful. Only if neither load do we have a
> > > > > > failure case. I'm suggesting that the grammer that your
> > > > > > exports define should take those cases into account. Its not always as
> simple as "I must have the following modules"
> > > > > >
> > > > > >> The syntax I've submitted lets you define several lists of
> > > > > >> modules, so that the user or the script that starts the
> > > > > >> application can decide which kmod list is better according to the
> environment.
> > > > > >>
> > > > > > If you have a human intervening in the module load process,
> > > > > > sure, then its
> > > > > fine.
> > > > > > But it seems that this particular feature that you're
> > > > > > implemnting might have automated uses. That is to say the
> > > > > > dpdk core library might be interested in parsing this
> > > > > > particular information to direct module autoloading, and if
> > > > > > thats desireable then you need to define these lists such that you can
> codify failure and success conditions.
> > > > > >
> > > > > >> For example, most drivers will advertise
> > > > > >> "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci", and the user
> > > > > >> or script will have to choose between loading:
> > > > > >> - uio igb_uio
> > > > > >> - uio uio_pci_generic
> > > > > >> - vfio vfio-pci
> > > > > >>
> > > > > > Oh, I see, so your list is a colon delimited list of module
> > > > > > load sets, where at least one set must succeed by loading all
> > > > > > modules in its set, but the failure of any one set isn't fatal to the
> process? e.g. a string like this:
> > > > > >
> > > > > > uio,igb_uio:vfio,vfio-pci
> > > > > >
> > > > > > could be interpreted to mean "I must load (uio AND igb_uio) OR
> > > > > > (vfio AND vfio-pci). If the evaluation of that statement
> > > > > > results in false, then the operation fails, otherwise it succedes.
> > > > > >
> > > > > > If thats the case, then, apologies, we're on the same page,
> > > > > > and this will work just fine.
> > > > >
> > > > > Yep, that's the idea.
> > > > >
> > > > > Colon and commas are the best separators I've thought about, but
> > > > > any idea to make the syntax clearer is welcome ;)
> > > > >
> > > > > Maybe a syntax like is clearer:
> > > > > "(mod1 & mod2)|(mod3 & mod4)" ?
> > > > > But it would let the user think that more complex expressions
> > > > > are valid, like "(mod1 & (mod2 | mod3)) | mod4", which is probably
> overkill.
> > > > >
> > > > > Regards,
> > > > > Olivier
> > > >
> > > > This RFC seems like a good idea - and something the Intel QuickAssist PMD
> could benefit from.
> > > > However the (mod1 & mod2) can handle the QAT case better in my
> opinion.
> > > > i.e.
> > > > as well as needing one of
> > > > * uio igb_uio
> > > > * uio uio_pci_generic
> > > > * vfio vfio-pci
> > > > QAT PMD also needs one of (depending on which physical device is
> > > > plugged)
> > > > * qat_dh895xcc
> > > > * qat_c62x
> > > > * qat_c3xxx
> > > >
> > > > So the original syntax would result in a very long list of possible variations.
> > > > What really reflects the dependencies would be ((uio & igb_uio) |
> > > > (uio & uio_pci_generic) | (vfio & vfio_pci)) & (qat_dh895xcc |
> > > > qat_c62x | qat_c3xxx)
> > > >
> > > Ah, I didn't consider that hardware specifics might create a use
> > > case where a pmd must have one or more kernel modules available for
> > > hw support. Perhaps it is worthwhile to automate hardware support -
> > > that is to say, any module loading script should automatically look
> > > at the pci table exported from a pmd, and, if found, load any
> > > modules that claim support for that device:vendor tuple? Though
> > > that might break in the case of uio, if there are separate driver modules that
> support native hardware and uio access.
Actually if the script output was intended to be used to auto-load dependent kmods,
then even the above would not suffice for the QAT driver (and presumably for other
PMDs with specific HW dependencies). i.e. the qat_dhxxxx modules have further dependencies
themselves on an intel_qat module, and there are other steps documented in the
guide which must be taken after loading the kmods.
The use-case I'd addressed was for the script to identify and just throw an error where
dependent modules are missing.
I don't see a simple solution, but also don't see a strong need to find one.
Documentation and if necessary a driver-specific script seem sufficient to me.
My conclusion is the RFC is a nice feature for some drivers, but if introduced needs
to be optional as it doesn't handle the complexities of all drivers.
> >
> > I ended up writing a script that went the other way.
> > First look at the hardware and load VFIO if IOMMU is available.
> > Then look for special driver needed for Xen and HyperV Lastly fallback
> > to loading igb_uio if no VFIO and PCI device present.
> >
> > In other words it is a system not driver issue.
> >
> That sounds like a reasonable approach, yes.
> Neil
>
> >
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-09-01 17:41 ` Stephen Hemminger
2016-09-01 19:15 ` Neil Horman
@ 2016-09-02 10:55 ` Thomas Monjalon
1 sibling, 0 replies; 46+ messages in thread
From: Thomas Monjalon @ 2016-09-02 10:55 UTC (permalink / raw)
To: Stephen Hemminger, Neil Horman, Trahe, Fiona, Olivier Matz; +Cc: dev
2016-09-01 10:41, Stephen Hemminger:
> Neil Horman <nhorman@tuxdriver.com> wrote:
> > On Thu, Sep 01, 2016 at 12:55:27PM +0000, Trahe, Fiona wrote:
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> > > > On 08/31/2016 03:27 PM, Neil Horman wrote:
> > > > > Oh, I see, so your list is a colon delimited list of module load sets, where at
> > > > > least one set must succeed by loading all modules in its set, but the failure of
> > > > > any one set isn't fatal to the process? e.g. a string like this:
> > > > >
> > > > > uio,igb_uio:vfio,vfio-pci
> > > > >
> > > > > could be interpreted to mean "I must load (uio AND igb_uio) OR (vfio AND
> > > > > vfio-pci). If the evaluation of that statement results in false, then the
> > > > > operation fails, otherwise it succedes.
> > > > >
> > > > > If thats the case, then, apologies, we're on the same page, and this will work
> > > > > just fine.
> > > >
> > > > Yep, that's the idea.
> > > >
> > > > Colon and commas are the best separators I've thought about, but any
> > > > idea to make the syntax clearer is welcome ;)
> > > >
> > > > Maybe a syntax like is clearer:
> > > > "(mod1 & mod2)|(mod3 & mod4)" ?
> > > > But it would let the user think that more complex expressions are valid,
> > > > like "(mod1 & (mod2 | mod3)) | mod4", which is probably overkill.
> > >
> > > This RFC seems like a good idea - and something the Intel QuickAssist PMD could benefit from.
> > > However the (mod1 & mod2) can handle the QAT case better in my opinion.
> > > i.e.
> > > as well as needing one of
> > > * uio igb_uio
> > > * uio uio_pci_generic
> > > * vfio vfio-pci
> > > QAT PMD also needs one of (depending on which physical device is plugged)
> > > * qat_dh895xcc
> > > * qat_c62x
> > > * qat_c3xxx
> > >
> > > So the original syntax would result in a very long list of possible variations.
> > > What really reflects the dependencies would be
> > > ((uio & igb_uio) | (uio & uio_pci_generic) | (vfio & vfio_pci)) & (qat_dh895xcc | qat_c62x | qat_c3xxx)
> > >
> > Ah, I didn't consider that hardware specifics might create a use case where a
> > pmd must have one or more kernel modules available for hw support. Perhaps it
> > is worthwhile to automate hardware support - that is to say, any module loading
> > script should automatically look at the pci table exported from a pmd, and, if
> > found, load any modules that claim support for that device:vendor tuple? Though
> > that might break in the case of uio, if there are separate driver modules that
> > support native hardware and uio access.
>
> I ended up writing a script that went the other way.
> First look at the hardware and load VFIO if IOMMU is available.
> Then look for special driver needed for Xen and HyperV
> Lastly fallback to loading igb_uio if no VFIO and PCI device present.
>
> In other words it is a system not driver issue.
That's partly right, yes.
But you need some information which are specific to the drivers and
we should try to embed them for three usages:
- give more info the user (without digging in the doc)
- replace info in some external system scripts harder to maintain
- prepare for hotplug
Some PMDs do not use UIO or VFIO at all,
However, I agree that the requirement
(uio & igb_uio) | (uio & uio_pci_generic) | (vfio & vfio_pci)
- and even the VFIO noiommu case - could be translated into a simple
flag, let's say "generic_device_mapping"
(unfortunately "queue_mapping" doesn't exist).
The other interesting point from Fiona is to show that this information is
device-related (not general for the whole driver). So we should add a device
parameter in the macro with the ability to set a wildcard.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-09-02 9:19 ` Trahe, Fiona
@ 2016-09-02 13:33 ` Neil Horman
2016-09-02 13:52 ` Trahe, Fiona
0 siblings, 1 reply; 46+ messages in thread
From: Neil Horman @ 2016-09-02 13:33 UTC (permalink / raw)
To: Trahe, Fiona; +Cc: Stephen Hemminger, dev, Olivier Matz, Thomas Monjalon
On Fri, Sep 02, 2016 at 09:19:26AM +0000, Trahe, Fiona wrote:
>
>
> > -----Original Message-----
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > Sent: Thursday, September 1, 2016 8:16 PM
> > To: Stephen Hemminger <stephen@networkplumber.org>
> > Cc: Trahe, Fiona <fiona.trahe@intel.com>; dev@dpdk.org; Olivier Matz
> > <olivier.matz@6wind.com>; Thomas Monjalon
> > <thomas.monjalon@6wind.com>
> > Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod dependencies
> > in pmdinfo
> >
> > On Thu, Sep 01, 2016 at 10:41:22AM -0700, Stephen Hemminger wrote:
> > > On Thu, 1 Sep 2016 13:35:19 -0400
> > > Neil Horman <nhorman@tuxdriver.com> wrote:
> > >
> > > > On Thu, Sep 01, 2016 at 12:55:27PM +0000, Trahe, Fiona wrote:
> > > > > Hi Neil and Olivier,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier
> > > > > > Matz
> > > > > > Sent: Wednesday, August 31, 2016 2:40 PM
> > > > > > To: Neil Horman <nhorman@tuxdriver.com>
> > > > > > Cc: dev@dpdk.org; thomas.monjalon@6wind.com
> > > > > > Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod
> > > > > > dependencies in pmdinfo
> > > > > >
> > > > > > Hi Neil,
> > > > > >
> > > > > > On 08/31/2016 03:27 PM, Neil Horman wrote:
> > > > > > > On Wed, Aug 31, 2016 at 11:21:18AM +0200, Olivier Matz wrote:
> > > > > > >> Hi Neil,
> > > > > > >>
> > > > > > >> On 08/30/2016 03:23 PM, Neil Horman wrote:
> > > > > > >>> On Fri, Aug 26, 2016 at 03:20:46PM +0200, Olivier Matz wrote:
> > > > > > >>>> Add a new macro DRIVER_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>
> > > > > > >>>>
> > > > > > >>>> ---
> > > > > > >>>> In this RFC, I supposed that all PCI drivers require a the
> > > > > > >>>> loading of a uio/vfio module (except mlx*), this may be wrong.
> > > > > > >>>> Comments are welcome!
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> buildtools/pmdinfogen/pmdinfogen.c | 1 +
> > > > > > >>>> buildtools/pmdinfogen/pmdinfogen.h | 1 +
> > > > > > >>>> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
> > > > > > >>>> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
> > > > > > >>>> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
> > > > > > >>>> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
> > > > > > >>>> drivers/net/e1000/em_ethdev.c | 2 ++
> > > > > > >>>> drivers/net/e1000/igb_ethdev.c | 4 ++++
> > > > > > >>>> drivers/net/ena/ena_ethdev.c | 2 ++
> > > > > > >>>> drivers/net/enic/enic_ethdev.c | 2 ++
> > > > > > >>>> drivers/net/fm10k/fm10k_ethdev.c | 2 ++
> > > > > > >>>> drivers/net/i40e/i40e_ethdev.c | 2 ++
> > > > > > >>>> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
> > > > > > >>>> drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
> > > > > > >>>> drivers/net/mlx4/mlx4.c | 2 ++
> > > > > > >>>> drivers/net/mlx5/mlx5.c | 3 +++
> > > > > > >>>> drivers/net/nfp/nfp_net.c | 2 ++
> > > > > > >>>> drivers/net/qede/qede_ethdev.c | 4 ++++
> > > > > > >>>> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
> > > > > > >>>> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
> > > > > > >>>> drivers/net/virtio/virtio_ethdev.c | 2 ++
> > > > > > >>>> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
> > > > > > >>>> lib/librte_eal/common/include/rte_dev.h | 14 ++++++++++++++
> > > > > > >>>> tools/dpdk-pmdinfo.py | 5 ++++-
> > > > > > >>>> 24 files changed, 69 insertions(+), 1 deletion(-)
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>> Generally speaking, I like the idea, it makes sense to me in
> > > > > > >>> terms of using pmdinfo to export this information
> > > > > > >>>
> > > > > > >>> That said, This may need to be a set of macros. By that I
> > > > > > >>> mean (and correct
> > > > > > me
> > > > > > >>> if I'm wrong here), but the relationship between pmd's and
> > > > > > >>> kernel modules
> > > > > > is in
> > > > > > >>> some cases, more complex than a 'requires' or 'depends'
> > > > > > >>> relationship. That
> > > > > > is
> > > > > > >>> to say, some pmd may need user space hardware access, but
> > > > > > >>> can use either
> > > > > > uio OR
> > > > > > >>> vfio, but doesn't need both, and can continue to function if
> > > > > > >>> only one is available. Other PMD's may be able to use vfio
> > > > > > >>> or uio, but can still function without either. And some, as
> > > > > > >>> your patch implements, simply require one or
> > > > > > the
> > > > > > >>> other to function. As such it seems like you may want a few
> > > > > > >>> macros, in the
> > > > > > form
> > > > > > >>> of:
> > > > > > >>>
> > > > > > >>> DRIVER_REGISTER_KMOD_REQUEST - List of modules to attempt
> > > > > > >>> loading,
> > > > > > ignore any
> > > > > > >>> failures
> > > > > > >>> DRIVER_REGISTER_KMOD_REQUIRE - List of modules required to
> > > > > > >>> be
> > > > > > loaded after
> > > > > > >>> request macro completes, fail if any are not loaded
> > > > > > >>>
> > > > > > >>> Thats just spitballing, mind you, theres probably a better
> > > > > > >>> way to do it, but
> > > > > > the
> > > > > > >>> idea is to list a set of modules you would like to have, and
> > > > > > >>> then create a parsable syntax to describe the modules that
> > > > > > >>> need to be loaded after the
> > > > > > request
> > > > > > >>> is complete so that you can accurately codify the situations
> > > > > > >>> I described
> > > > > > above.
> > > > > > >>
> > > > > > >> Thank you for your feedback.
> > > > > > >> However, I'm not sure I'm perfectly getting what you suggest.
> > > > > > >>
> > > > > > >> Do you think some PMDs could request a kernel module without
> > > > > > >> really requiring it? Do you have an example in mind?
> > > > > > >>
> > > > > > > Yes, thats precisely it. The most clear example I could think
> > > > > > > of (though I'm not sure if any pmd currently supports this),
> > > > > > > is a pmd that supports both UIO and VFIO communication with
> > > > > > > the kernel. Such a PMD requires that one of
> > > > > > those
> > > > > > > two modules be loaded, but only one (i.e. both are not
> > > > > > > required), so if only
> > > > > > the
> > > > > > > uio kernel module loads is a success case, likewise if only
> > > > > > > the vfio module loads can be treated as success. Both loading
> > > > > > > are clearly successful. Only if neither load do we have a
> > > > > > > failure case. I'm suggesting that the grammer that your
> > > > > > > exports define should take those cases into account. Its not always as
> > simple as "I must have the following modules"
> > > > > > >
> > > > > > >> The syntax I've submitted lets you define several lists of
> > > > > > >> modules, so that the user or the script that starts the
> > > > > > >> application can decide which kmod list is better according to the
> > environment.
> > > > > > >>
> > > > > > > If you have a human intervening in the module load process,
> > > > > > > sure, then its
> > > > > > fine.
> > > > > > > But it seems that this particular feature that you're
> > > > > > > implemnting might have automated uses. That is to say the
> > > > > > > dpdk core library might be interested in parsing this
> > > > > > > particular information to direct module autoloading, and if
> > > > > > > thats desireable then you need to define these lists such that you can
> > codify failure and success conditions.
> > > > > > >
> > > > > > >> For example, most drivers will advertise
> > > > > > >> "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci", and the user
> > > > > > >> or script will have to choose between loading:
> > > > > > >> - uio igb_uio
> > > > > > >> - uio uio_pci_generic
> > > > > > >> - vfio vfio-pci
> > > > > > >>
> > > > > > > Oh, I see, so your list is a colon delimited list of module
> > > > > > > load sets, where at least one set must succeed by loading all
> > > > > > > modules in its set, but the failure of any one set isn't fatal to the
> > process? e.g. a string like this:
> > > > > > >
> > > > > > > uio,igb_uio:vfio,vfio-pci
> > > > > > >
> > > > > > > could be interpreted to mean "I must load (uio AND igb_uio) OR
> > > > > > > (vfio AND vfio-pci). If the evaluation of that statement
> > > > > > > results in false, then the operation fails, otherwise it succedes.
> > > > > > >
> > > > > > > If thats the case, then, apologies, we're on the same page,
> > > > > > > and this will work just fine.
> > > > > >
> > > > > > Yep, that's the idea.
> > > > > >
> > > > > > Colon and commas are the best separators I've thought about, but
> > > > > > any idea to make the syntax clearer is welcome ;)
> > > > > >
> > > > > > Maybe a syntax like is clearer:
> > > > > > "(mod1 & mod2)|(mod3 & mod4)" ?
> > > > > > But it would let the user think that more complex expressions
> > > > > > are valid, like "(mod1 & (mod2 | mod3)) | mod4", which is probably
> > overkill.
> > > > > >
> > > > > > Regards,
> > > > > > Olivier
> > > > >
> > > > > This RFC seems like a good idea - and something the Intel QuickAssist PMD
> > could benefit from.
> > > > > However the (mod1 & mod2) can handle the QAT case better in my
> > opinion.
> > > > > i.e.
> > > > > as well as needing one of
> > > > > * uio igb_uio
> > > > > * uio uio_pci_generic
> > > > > * vfio vfio-pci
> > > > > QAT PMD also needs one of (depending on which physical device is
> > > > > plugged)
> > > > > * qat_dh895xcc
> > > > > * qat_c62x
> > > > > * qat_c3xxx
> > > > >
> > > > > So the original syntax would result in a very long list of possible variations.
> > > > > What really reflects the dependencies would be ((uio & igb_uio) |
> > > > > (uio & uio_pci_generic) | (vfio & vfio_pci)) & (qat_dh895xcc |
> > > > > qat_c62x | qat_c3xxx)
> > > > >
> > > > Ah, I didn't consider that hardware specifics might create a use
> > > > case where a pmd must have one or more kernel modules available for
> > > > hw support. Perhaps it is worthwhile to automate hardware support -
> > > > that is to say, any module loading script should automatically look
> > > > at the pci table exported from a pmd, and, if found, load any
> > > > modules that claim support for that device:vendor tuple? Though
> > > > that might break in the case of uio, if there are separate driver modules that
> > support native hardware and uio access.
>
> Actually if the script output was intended to be used to auto-load dependent kmods,
> then even the above would not suffice for the QAT driver (and presumably for other
> PMDs with specific HW dependencies). i.e. the qat_dhxxxx modules have further dependencies
> themselves on an intel_qat module, and there are other steps documented in the
But any dependency chain such as what you describe is covered in the next step
of the chain. That is to say if the qat pmd has a hardware dependency on
qat_dhxxx (or qat_cxxx, etc), and those modules depend on intel_qat, the pmd
doesn't need to know that, because qat_dhxxx and companions should all list
intel_qat as a dependency that modprobe will resolve when installing the kernel
module.
> guide which must be taken after loading the kmods.
I'm not sure what you mean by this. Are you referring to the qat documentation
that comes with the DPDK? I only see three additional items there to address
1) Removing other modules when using the 01.org kernel modules
2) installation of firmware
3) Binding of the device to user space for VFIO/UIO
All three of these tasks fall outside the scope of what this macro is meant to
do. We could try to create macros for them to export information for use in a
loading script if you like, but I wouldn't. All three of the above items fall
in my mind under the category of administrative responsibilities. That is to
say, they are orthogonoal to defining a module dependency structure, and if
they're arent properly completed, the module dependency chain won't matter
anyway.
> The use-case I'd addressed was for the script to identify and just throw an error where
> dependent modules are missing.
>
That doesn't really add much value then, since missing modules already result in
errors when the PMD tries to initalize.
> I don't see a simple solution, but also don't see a strong need to find one.
> Documentation and if necessary a driver-specific script seem sufficient to me.
>
> My conclusion is the RFC is a nice feature for some drivers, but if introduced needs
> to be optional as it doesn't handle the complexities of all drivers.
>
I agree its an optional export. If there are no dependencies, or if the author
wishes to to simply not supply any, thats fine, the results will be in
accordance with that, but I strongly disagree that its optional implies the fact
that we can ignore the complexities of the depedencies that can be exported.
The more I think about it the more I like Stephens idea, possibly with some
macro assistance. That is to say:
1) Start by loading hardware specific modules, the information for which is
already available. You can parse the pci table that a pmd exports and match it
with the pci aliases retrieved via modinfo
2) Load a special virt driver if no hardware is found on the system in (1).
special virt drivers might be worth tagging with a VIRT/VFIO/UIO tag export for
pmdinfo
That allows to set asside the complexities of our dependency chain, as we can
assume hardware support modules will codify any real dependencies there, and a
VIRT tag will let us find any modules needed for hardware the is assigned into
our guest.
Neil
Neil
> > >
> > > I ended up writing a script that went the other way.
> > > First look at the hardware and load VFIO if IOMMU is available.
> > > Then look for special driver needed for Xen and HyperV Lastly fallback
> > > to loading igb_uio if no VFIO and PCI device present.
> > >
> > > In other words it is a system not driver issue.
> > >
> > That sounds like a reasonable approach, yes.
> > Neil
> >
> > >
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-09-02 13:33 ` Neil Horman
@ 2016-09-02 13:52 ` Trahe, Fiona
2016-09-02 14:15 ` Neil Horman
0 siblings, 1 reply; 46+ messages in thread
From: Trahe, Fiona @ 2016-09-02 13:52 UTC (permalink / raw)
To: Neil Horman
Cc: Stephen Hemminger, dev, Olivier Matz, Thomas Monjalon, Trahe, Fiona
> -----Original Message-----
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Friday, September 2, 2016 2:33 PM
> To: Trahe, Fiona <fiona.trahe@intel.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>; dev@dpdk.org;
> Olivier Matz <olivier.matz@6wind.com>; Thomas Monjalon
> <thomas.monjalon@6wind.com>
> Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod dependencies
> in pmdinfo
>
> On Fri, Sep 02, 2016 at 09:19:26AM +0000, Trahe, Fiona wrote:
> >
> >
> > > -----Original Message-----
> > > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > > Sent: Thursday, September 1, 2016 8:16 PM
> > > To: Stephen Hemminger <stephen@networkplumber.org>
> > > Cc: Trahe, Fiona <fiona.trahe@intel.com>; dev@dpdk.org; Olivier Matz
> > > <olivier.matz@6wind.com>; Thomas Monjalon
> > > <thomas.monjalon@6wind.com>
> > > Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod
> > > dependencies in pmdinfo
> > >
> > > On Thu, Sep 01, 2016 at 10:41:22AM -0700, Stephen Hemminger wrote:
> > > > On Thu, 1 Sep 2016 13:35:19 -0400
> > > > Neil Horman <nhorman@tuxdriver.com> wrote:
> > > >
> > > > > On Thu, Sep 01, 2016 at 12:55:27PM +0000, Trahe, Fiona wrote:
> > > > > > Hi Neil and Olivier,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier
> > > > > > > Matz
> > > > > > > Sent: Wednesday, August 31, 2016 2:40 PM
> > > > > > > To: Neil Horman <nhorman@tuxdriver.com>
> > > > > > > Cc: dev@dpdk.org; thomas.monjalon@6wind.com
> > > > > > > Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise
> > > > > > > kmod dependencies in pmdinfo
> > > > > > >
> > > > > > > Hi Neil,
> > > > > > >
> > > > > > > On 08/31/2016 03:27 PM, Neil Horman wrote:
> > > > > > > > On Wed, Aug 31, 2016 at 11:21:18AM +0200, Olivier Matz wrote:
> > > > > > > >> Hi Neil,
> > > > > > > >>
> > > > > > > >> On 08/30/2016 03:23 PM, Neil Horman wrote:
> > > > > > > >>> On Fri, Aug 26, 2016 at 03:20:46PM +0200, Olivier Matz wrote:
> > > > > > > >>>> Add a new macro DRIVER_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>
> > > > > > > >>>>
> > > > > > > >>>> ---
> > > > > > > >>>> In this RFC, I supposed that all PCI drivers require a
> > > > > > > >>>> the loading of a uio/vfio module (except mlx*), this may be
> wrong.
> > > > > > > >>>> Comments are welcome!
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>> buildtools/pmdinfogen/pmdinfogen.c | 1 +
> > > > > > > >>>> buildtools/pmdinfogen/pmdinfogen.h | 1 +
> > > > > > > >>>> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
> > > > > > > >>>> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
> > > > > > > >>>> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
> > > > > > > >>>> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
> > > > > > > >>>> drivers/net/e1000/em_ethdev.c | 2 ++
> > > > > > > >>>> drivers/net/e1000/igb_ethdev.c | 4 ++++
> > > > > > > >>>> drivers/net/ena/ena_ethdev.c | 2 ++
> > > > > > > >>>> drivers/net/enic/enic_ethdev.c | 2 ++
> > > > > > > >>>> drivers/net/fm10k/fm10k_ethdev.c | 2 ++
> > > > > > > >>>> drivers/net/i40e/i40e_ethdev.c | 2 ++
> > > > > > > >>>> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
> > > > > > > >>>> drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
> > > > > > > >>>> drivers/net/mlx4/mlx4.c | 2 ++
> > > > > > > >>>> drivers/net/mlx5/mlx5.c | 3 +++
> > > > > > > >>>> drivers/net/nfp/nfp_net.c | 2 ++
> > > > > > > >>>> drivers/net/qede/qede_ethdev.c | 4 ++++
> > > > > > > >>>> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
> > > > > > > >>>> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
> > > > > > > >>>> drivers/net/virtio/virtio_ethdev.c | 2 ++
> > > > > > > >>>> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
> > > > > > > >>>> lib/librte_eal/common/include/rte_dev.h | 14
> ++++++++++++++
> > > > > > > >>>> tools/dpdk-pmdinfo.py | 5 ++++-
> > > > > > > >>>> 24 files changed, 69 insertions(+), 1 deletion(-)
> > > > > > > >>>>
> > > > > > > >>>
> > > > > > > >>> Generally speaking, I like the idea, it makes sense to
> > > > > > > >>> me in terms of using pmdinfo to export this information
> > > > > > > >>>
> > > > > > > >>> That said, This may need to be a set of macros. By that
> > > > > > > >>> I mean (and correct
> > > > > > > me
> > > > > > > >>> if I'm wrong here), but the relationship between pmd's
> > > > > > > >>> and kernel modules
> > > > > > > is in
> > > > > > > >>> some cases, more complex than a 'requires' or 'depends'
> > > > > > > >>> relationship. That
> > > > > > > is
> > > > > > > >>> to say, some pmd may need user space hardware access,
> > > > > > > >>> but can use either
> > > > > > > uio OR
> > > > > > > >>> vfio, but doesn't need both, and can continue to
> > > > > > > >>> function if only one is available. Other PMD's may be
> > > > > > > >>> able to use vfio or uio, but can still function without
> > > > > > > >>> either. And some, as your patch implements, simply
> > > > > > > >>> require one or
> > > > > > > the
> > > > > > > >>> other to function. As such it seems like you may want a
> > > > > > > >>> few macros, in the
> > > > > > > form
> > > > > > > >>> of:
> > > > > > > >>>
> > > > > > > >>> DRIVER_REGISTER_KMOD_REQUEST - List of modules to
> > > > > > > >>> attempt loading,
> > > > > > > ignore any
> > > > > > > >>> failures
> > > > > > > >>> DRIVER_REGISTER_KMOD_REQUIRE - List of modules required
> > > > > > > >>> to be
> > > > > > > loaded after
> > > > > > > >>> request macro completes, fail if any are not loaded
> > > > > > > >>>
> > > > > > > >>> Thats just spitballing, mind you, theres probably a
> > > > > > > >>> better way to do it, but
> > > > > > > the
> > > > > > > >>> idea is to list a set of modules you would like to have,
> > > > > > > >>> and then create a parsable syntax to describe the
> > > > > > > >>> modules that need to be loaded after the
> > > > > > > request
> > > > > > > >>> is complete so that you can accurately codify the
> > > > > > > >>> situations I described
> > > > > > > above.
> > > > > > > >>
> > > > > > > >> Thank you for your feedback.
> > > > > > > >> However, I'm not sure I'm perfectly getting what you suggest.
> > > > > > > >>
> > > > > > > >> Do you think some PMDs could request a kernel module
> > > > > > > >> without really requiring it? Do you have an example in mind?
> > > > > > > >>
> > > > > > > > Yes, thats precisely it. The most clear example I could
> > > > > > > > think of (though I'm not sure if any pmd currently
> > > > > > > > supports this), is a pmd that supports both UIO and VFIO
> > > > > > > > communication with the kernel. Such a PMD requires that
> > > > > > > > one of
> > > > > > > those
> > > > > > > > two modules be loaded, but only one (i.e. both are not
> > > > > > > > required), so if only
> > > > > > > the
> > > > > > > > uio kernel module loads is a success case, likewise if
> > > > > > > > only the vfio module loads can be treated as success.
> > > > > > > > Both loading are clearly successful. Only if neither load
> > > > > > > > do we have a failure case. I'm suggesting that the
> > > > > > > > grammer that your exports define should take those cases
> > > > > > > > into account. Its not always as
> > > simple as "I must have the following modules"
> > > > > > > >
> > > > > > > >> The syntax I've submitted lets you define several lists
> > > > > > > >> of modules, so that the user or the script that starts
> > > > > > > >> the application can decide which kmod list is better
> > > > > > > >> according to the
> > > environment.
> > > > > > > >>
> > > > > > > > If you have a human intervening in the module load
> > > > > > > > process, sure, then its
> > > > > > > fine.
> > > > > > > > But it seems that this particular feature that you're
> > > > > > > > implemnting might have automated uses. That is to say the
> > > > > > > > dpdk core library might be interested in parsing this
> > > > > > > > particular information to direct module autoloading, and
> > > > > > > > if thats desireable then you need to define these lists
> > > > > > > > such that you can
> > > codify failure and success conditions.
> > > > > > > >
> > > > > > > >> For example, most drivers will advertise
> > > > > > > >> "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci", and the
> > > > > > > >> user or script will have to choose between loading:
> > > > > > > >> - uio igb_uio
> > > > > > > >> - uio uio_pci_generic
> > > > > > > >> - vfio vfio-pci
> > > > > > > >>
> > > > > > > > Oh, I see, so your list is a colon delimited list of
> > > > > > > > module load sets, where at least one set must succeed by
> > > > > > > > loading all modules in its set, but the failure of any one
> > > > > > > > set isn't fatal to the
> > > process? e.g. a string like this:
> > > > > > > >
> > > > > > > > uio,igb_uio:vfio,vfio-pci
> > > > > > > >
> > > > > > > > could be interpreted to mean "I must load (uio AND
> > > > > > > > igb_uio) OR (vfio AND vfio-pci). If the evaluation of
> > > > > > > > that statement results in false, then the operation fails, otherwise
> it succedes.
> > > > > > > >
> > > > > > > > If thats the case, then, apologies, we're on the same
> > > > > > > > page, and this will work just fine.
> > > > > > >
> > > > > > > Yep, that's the idea.
> > > > > > >
> > > > > > > Colon and commas are the best separators I've thought about,
> > > > > > > but any idea to make the syntax clearer is welcome ;)
> > > > > > >
> > > > > > > Maybe a syntax like is clearer:
> > > > > > > "(mod1 & mod2)|(mod3 & mod4)" ?
> > > > > > > But it would let the user think that more complex
> > > > > > > expressions are valid, like "(mod1 & (mod2 | mod3)) | mod4",
> > > > > > > which is probably
> > > overkill.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Olivier
> > > > > >
> > > > > > This RFC seems like a good idea - and something the Intel
> > > > > > QuickAssist PMD
> > > could benefit from.
> > > > > > However the (mod1 & mod2) can handle the QAT case better in my
> > > opinion.
> > > > > > i.e.
> > > > > > as well as needing one of
> > > > > > * uio igb_uio
> > > > > > * uio uio_pci_generic
> > > > > > * vfio vfio-pci
> > > > > > QAT PMD also needs one of (depending on which physical device
> > > > > > is
> > > > > > plugged)
> > > > > > * qat_dh895xcc
> > > > > > * qat_c62x
> > > > > > * qat_c3xxx
> > > > > >
> > > > > > So the original syntax would result in a very long list of possible
> variations.
> > > > > > What really reflects the dependencies would be ((uio &
> > > > > > igb_uio) | (uio & uio_pci_generic) | (vfio & vfio_pci)) &
> > > > > > (qat_dh895xcc | qat_c62x | qat_c3xxx)
> > > > > >
> > > > > Ah, I didn't consider that hardware specifics might create a use
> > > > > case where a pmd must have one or more kernel modules available
> > > > > for hw support. Perhaps it is worthwhile to automate hardware
> > > > > support - that is to say, any module loading script should
> > > > > automatically look at the pci table exported from a pmd, and, if
> > > > > found, load any modules that claim support for that
> > > > > device:vendor tuple? Though that might break in the case of
> > > > > uio, if there are separate driver modules that
> > > support native hardware and uio access.
> >
> > Actually if the script output was intended to be used to auto-load
> > dependent kmods, then even the above would not suffice for the QAT
> > driver (and presumably for other PMDs with specific HW dependencies).
> > i.e. the qat_dhxxxx modules have further dependencies themselves on an
> > intel_qat module, and there are other steps documented in the
> But any dependency chain such as what you describe is covered in the next step
> of the chain. That is to say if the qat pmd has a hardware dependency on
> qat_dhxxx (or qat_cxxx, etc), and those modules depend on intel_qat, the pmd
> doesn't need to know that, because qat_dhxxx and companions should all list
> intel_qat as a dependency that modprobe will resolve when installing the kernel
> module.
>
> > guide which must be taken after loading the kmods.
> I'm not sure what you mean by this. Are you referring to the qat
> documentation that comes with the DPDK? I only see three additional items
> there to address
>
> 1) Removing other modules when using the 01.org kernel modules
>
> 2) installation of firmware
>
> 3) Binding of the device to user space for VFIO/UIO
>
> All three of these tasks fall outside the scope of what this macro is meant to do.
> We could try to create macros for them to export information for use in a
> loading script if you like, but I wouldn't. All three of the above items fall in my
> mind under the category of administrative responsibilities. That is to say, they
> are orthogonoal to defining a module dependency structure, and if they're
> arent properly completed, the module dependency chain won't matter anyway.
>
Another manual step is documented, which must be done after insmod:
echo 32 > /sys/bus/pci/drivers/dh895xcc/0000\:03\:00.0/sriov_numvfs
(steps will vary for different hardware types)
Which I agree like the others are outside the scope of what this macro is meant to do.
So using the macro to facilitate auto-loading of modules isn't a very useful feature
for the QAT driver.
> > The use-case I'd addressed was for the script to identify and just
> > throw an error where dependent modules are missing.
> >
>
> That doesn't really add much value then, since missing modules already result in
> errors when the PMD tries to initalize.
>
> > I don't see a simple solution, but also don't see a strong need to find one.
> > Documentation and if necessary a driver-specific script seem sufficient to me.
> >
> > My conclusion is the RFC is a nice feature for some drivers, but if introduced
> needs
> > to be optional as it doesn't handle the complexities of all drivers.
> >
>
> I agree its an optional export. If there are no dependencies, or if the author
> wishes to to simply not supply any, thats fine, the results will be in
> accordance with that, but I strongly disagree that its optional implies the fact
> that we can ignore the complexities of the depedencies that can be exported.
>
> The more I think about it the more I like Stephens idea, possibly with some
> macro assistance. That is to say:
>
> 1) Start by loading hardware specific modules, the information for which is
> already available. You can parse the pci table that a pmd exports and match it
> with the pci aliases retrieved via modinfo
>
> 2) Load a special virt driver if no hardware is found on the system in (1).
> special virt drivers might be worth tagging with a VIRT/VFIO/UIO tag export for
> pmdinfo
>
> That allows to set asside the complexities of our dependency chain, as we can
> assume hardware support modules will codify any real dependencies there, and
> a
> VIRT tag will let us find any modules needed for hardware the is assigned into
> our guest.
>
> Neil
>
> Neil
>
> > > >
> > > > I ended up writing a script that went the other way.
> > > > First look at the hardware and load VFIO if IOMMU is available.
> > > > Then look for special driver needed for Xen and HyperV Lastly fallback
> > > > to loading igb_uio if no VFIO and PCI device present.
> > > >
> > > > In other words it is a system not driver issue.
> > > >
> > > That sounds like a reasonable approach, yes.
> > > Neil
> > >
> > > >
> >
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-09-02 13:52 ` Trahe, Fiona
@ 2016-09-02 14:15 ` Neil Horman
2016-09-02 16:13 ` Olivier Matz
0 siblings, 1 reply; 46+ messages in thread
From: Neil Horman @ 2016-09-02 14:15 UTC (permalink / raw)
To: Trahe, Fiona; +Cc: Stephen Hemminger, dev, Olivier Matz, Thomas Monjalon
On Fri, Sep 02, 2016 at 01:52:46PM +0000, Trahe, Fiona wrote:
>
>
> > -----Original Message-----
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > Sent: Friday, September 2, 2016 2:33 PM
> > To: Trahe, Fiona <fiona.trahe@intel.com>
> > Cc: Stephen Hemminger <stephen@networkplumber.org>; dev@dpdk.org;
> > Olivier Matz <olivier.matz@6wind.com>; Thomas Monjalon
> > <thomas.monjalon@6wind.com>
> > Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod dependencies
> > in pmdinfo
> >
> > On Fri, Sep 02, 2016 at 09:19:26AM +0000, Trahe, Fiona wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > > > Sent: Thursday, September 1, 2016 8:16 PM
> > > > To: Stephen Hemminger <stephen@networkplumber.org>
> > > > Cc: Trahe, Fiona <fiona.trahe@intel.com>; dev@dpdk.org; Olivier Matz
> > > > <olivier.matz@6wind.com>; Thomas Monjalon
> > > > <thomas.monjalon@6wind.com>
> > > > Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod
> > > > dependencies in pmdinfo
> > > >
> > > > On Thu, Sep 01, 2016 at 10:41:22AM -0700, Stephen Hemminger wrote:
> > > > > On Thu, 1 Sep 2016 13:35:19 -0400
> > > > > Neil Horman <nhorman@tuxdriver.com> wrote:
> > > > >
> > > > > > On Thu, Sep 01, 2016 at 12:55:27PM +0000, Trahe, Fiona wrote:
> > > > > > > Hi Neil and Olivier,
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier
> > > > > > > > Matz
> > > > > > > > Sent: Wednesday, August 31, 2016 2:40 PM
> > > > > > > > To: Neil Horman <nhorman@tuxdriver.com>
> > > > > > > > Cc: dev@dpdk.org; thomas.monjalon@6wind.com
> > > > > > > > Subject: Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise
> > > > > > > > kmod dependencies in pmdinfo
> > > > > > > >
> > > > > > > > Hi Neil,
> > > > > > > >
> > > > > > > > On 08/31/2016 03:27 PM, Neil Horman wrote:
> > > > > > > > > On Wed, Aug 31, 2016 at 11:21:18AM +0200, Olivier Matz wrote:
> > > > > > > > >> Hi Neil,
> > > > > > > > >>
> > > > > > > > >> On 08/30/2016 03:23 PM, Neil Horman wrote:
> > > > > > > > >>> On Fri, Aug 26, 2016 at 03:20:46PM +0200, Olivier Matz wrote:
> > > > > > > > >>>> Add a new macro DRIVER_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>
> > > > > > > > >>>>
> > > > > > > > >>>> ---
> > > > > > > > >>>> In this RFC, I supposed that all PCI drivers require a
> > > > > > > > >>>> the loading of a uio/vfio module (except mlx*), this may be
> > wrong.
> > > > > > > > >>>> Comments are welcome!
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>> buildtools/pmdinfogen/pmdinfogen.c | 1 +
> > > > > > > > >>>> buildtools/pmdinfogen/pmdinfogen.h | 1 +
> > > > > > > > >>>> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++
> > > > > > > > >>>> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++++
> > > > > > > > >>>> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
> > > > > > > > >>>> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
> > > > > > > > >>>> drivers/net/e1000/em_ethdev.c | 2 ++
> > > > > > > > >>>> drivers/net/e1000/igb_ethdev.c | 4 ++++
> > > > > > > > >>>> drivers/net/ena/ena_ethdev.c | 2 ++
> > > > > > > > >>>> drivers/net/enic/enic_ethdev.c | 2 ++
> > > > > > > > >>>> drivers/net/fm10k/fm10k_ethdev.c | 2 ++
> > > > > > > > >>>> drivers/net/i40e/i40e_ethdev.c | 2 ++
> > > > > > > > >>>> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
> > > > > > > > >>>> drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++++
> > > > > > > > >>>> drivers/net/mlx4/mlx4.c | 2 ++
> > > > > > > > >>>> drivers/net/mlx5/mlx5.c | 3 +++
> > > > > > > > >>>> drivers/net/nfp/nfp_net.c | 2 ++
> > > > > > > > >>>> drivers/net/qede/qede_ethdev.c | 4 ++++
> > > > > > > > >>>> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
> > > > > > > > >>>> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
> > > > > > > > >>>> drivers/net/virtio/virtio_ethdev.c | 2 ++
> > > > > > > > >>>> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
> > > > > > > > >>>> lib/librte_eal/common/include/rte_dev.h | 14
> > ++++++++++++++
> > > > > > > > >>>> tools/dpdk-pmdinfo.py | 5 ++++-
> > > > > > > > >>>> 24 files changed, 69 insertions(+), 1 deletion(-)
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>> Generally speaking, I like the idea, it makes sense to
> > > > > > > > >>> me in terms of using pmdinfo to export this information
> > > > > > > > >>>
> > > > > > > > >>> That said, This may need to be a set of macros. By that
> > > > > > > > >>> I mean (and correct
> > > > > > > > me
> > > > > > > > >>> if I'm wrong here), but the relationship between pmd's
> > > > > > > > >>> and kernel modules
> > > > > > > > is in
> > > > > > > > >>> some cases, more complex than a 'requires' or 'depends'
> > > > > > > > >>> relationship. That
> > > > > > > > is
> > > > > > > > >>> to say, some pmd may need user space hardware access,
> > > > > > > > >>> but can use either
> > > > > > > > uio OR
> > > > > > > > >>> vfio, but doesn't need both, and can continue to
> > > > > > > > >>> function if only one is available. Other PMD's may be
> > > > > > > > >>> able to use vfio or uio, but can still function without
> > > > > > > > >>> either. And some, as your patch implements, simply
> > > > > > > > >>> require one or
> > > > > > > > the
> > > > > > > > >>> other to function. As such it seems like you may want a
> > > > > > > > >>> few macros, in the
> > > > > > > > form
> > > > > > > > >>> of:
> > > > > > > > >>>
> > > > > > > > >>> DRIVER_REGISTER_KMOD_REQUEST - List of modules to
> > > > > > > > >>> attempt loading,
> > > > > > > > ignore any
> > > > > > > > >>> failures
> > > > > > > > >>> DRIVER_REGISTER_KMOD_REQUIRE - List of modules required
> > > > > > > > >>> to be
> > > > > > > > loaded after
> > > > > > > > >>> request macro completes, fail if any are not loaded
> > > > > > > > >>>
> > > > > > > > >>> Thats just spitballing, mind you, theres probably a
> > > > > > > > >>> better way to do it, but
> > > > > > > > the
> > > > > > > > >>> idea is to list a set of modules you would like to have,
> > > > > > > > >>> and then create a parsable syntax to describe the
> > > > > > > > >>> modules that need to be loaded after the
> > > > > > > > request
> > > > > > > > >>> is complete so that you can accurately codify the
> > > > > > > > >>> situations I described
> > > > > > > > above.
> > > > > > > > >>
> > > > > > > > >> Thank you for your feedback.
> > > > > > > > >> However, I'm not sure I'm perfectly getting what you suggest.
> > > > > > > > >>
> > > > > > > > >> Do you think some PMDs could request a kernel module
> > > > > > > > >> without really requiring it? Do you have an example in mind?
> > > > > > > > >>
> > > > > > > > > Yes, thats precisely it. The most clear example I could
> > > > > > > > > think of (though I'm not sure if any pmd currently
> > > > > > > > > supports this), is a pmd that supports both UIO and VFIO
> > > > > > > > > communication with the kernel. Such a PMD requires that
> > > > > > > > > one of
> > > > > > > > those
> > > > > > > > > two modules be loaded, but only one (i.e. both are not
> > > > > > > > > required), so if only
> > > > > > > > the
> > > > > > > > > uio kernel module loads is a success case, likewise if
> > > > > > > > > only the vfio module loads can be treated as success.
> > > > > > > > > Both loading are clearly successful. Only if neither load
> > > > > > > > > do we have a failure case. I'm suggesting that the
> > > > > > > > > grammer that your exports define should take those cases
> > > > > > > > > into account. Its not always as
> > > > simple as "I must have the following modules"
> > > > > > > > >
> > > > > > > > >> The syntax I've submitted lets you define several lists
> > > > > > > > >> of modules, so that the user or the script that starts
> > > > > > > > >> the application can decide which kmod list is better
> > > > > > > > >> according to the
> > > > environment.
> > > > > > > > >>
> > > > > > > > > If you have a human intervening in the module load
> > > > > > > > > process, sure, then its
> > > > > > > > fine.
> > > > > > > > > But it seems that this particular feature that you're
> > > > > > > > > implemnting might have automated uses. That is to say the
> > > > > > > > > dpdk core library might be interested in parsing this
> > > > > > > > > particular information to direct module autoloading, and
> > > > > > > > > if thats desireable then you need to define these lists
> > > > > > > > > such that you can
> > > > codify failure and success conditions.
> > > > > > > > >
> > > > > > > > >> For example, most drivers will advertise
> > > > > > > > >> "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci", and the
> > > > > > > > >> user or script will have to choose between loading:
> > > > > > > > >> - uio igb_uio
> > > > > > > > >> - uio uio_pci_generic
> > > > > > > > >> - vfio vfio-pci
> > > > > > > > >>
> > > > > > > > > Oh, I see, so your list is a colon delimited list of
> > > > > > > > > module load sets, where at least one set must succeed by
> > > > > > > > > loading all modules in its set, but the failure of any one
> > > > > > > > > set isn't fatal to the
> > > > process? e.g. a string like this:
> > > > > > > > >
> > > > > > > > > uio,igb_uio:vfio,vfio-pci
> > > > > > > > >
> > > > > > > > > could be interpreted to mean "I must load (uio AND
> > > > > > > > > igb_uio) OR (vfio AND vfio-pci). If the evaluation of
> > > > > > > > > that statement results in false, then the operation fails, otherwise
> > it succedes.
> > > > > > > > >
> > > > > > > > > If thats the case, then, apologies, we're on the same
> > > > > > > > > page, and this will work just fine.
> > > > > > > >
> > > > > > > > Yep, that's the idea.
> > > > > > > >
> > > > > > > > Colon and commas are the best separators I've thought about,
> > > > > > > > but any idea to make the syntax clearer is welcome ;)
> > > > > > > >
> > > > > > > > Maybe a syntax like is clearer:
> > > > > > > > "(mod1 & mod2)|(mod3 & mod4)" ?
> > > > > > > > But it would let the user think that more complex
> > > > > > > > expressions are valid, like "(mod1 & (mod2 | mod3)) | mod4",
> > > > > > > > which is probably
> > > > overkill.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Olivier
> > > > > > >
> > > > > > > This RFC seems like a good idea - and something the Intel
> > > > > > > QuickAssist PMD
> > > > could benefit from.
> > > > > > > However the (mod1 & mod2) can handle the QAT case better in my
> > > > opinion.
> > > > > > > i.e.
> > > > > > > as well as needing one of
> > > > > > > * uio igb_uio
> > > > > > > * uio uio_pci_generic
> > > > > > > * vfio vfio-pci
> > > > > > > QAT PMD also needs one of (depending on which physical device
> > > > > > > is
> > > > > > > plugged)
> > > > > > > * qat_dh895xcc
> > > > > > > * qat_c62x
> > > > > > > * qat_c3xxx
> > > > > > >
> > > > > > > So the original syntax would result in a very long list of possible
> > variations.
> > > > > > > What really reflects the dependencies would be ((uio &
> > > > > > > igb_uio) | (uio & uio_pci_generic) | (vfio & vfio_pci)) &
> > > > > > > (qat_dh895xcc | qat_c62x | qat_c3xxx)
> > > > > > >
> > > > > > Ah, I didn't consider that hardware specifics might create a use
> > > > > > case where a pmd must have one or more kernel modules available
> > > > > > for hw support. Perhaps it is worthwhile to automate hardware
> > > > > > support - that is to say, any module loading script should
> > > > > > automatically look at the pci table exported from a pmd, and, if
> > > > > > found, load any modules that claim support for that
> > > > > > device:vendor tuple? Though that might break in the case of
> > > > > > uio, if there are separate driver modules that
> > > > support native hardware and uio access.
> > >
> > > Actually if the script output was intended to be used to auto-load
> > > dependent kmods, then even the above would not suffice for the QAT
> > > driver (and presumably for other PMDs with specific HW dependencies).
> > > i.e. the qat_dhxxxx modules have further dependencies themselves on an
> > > intel_qat module, and there are other steps documented in the
> > But any dependency chain such as what you describe is covered in the next step
> > of the chain. That is to say if the qat pmd has a hardware dependency on
> > qat_dhxxx (or qat_cxxx, etc), and those modules depend on intel_qat, the pmd
> > doesn't need to know that, because qat_dhxxx and companions should all list
> > intel_qat as a dependency that modprobe will resolve when installing the kernel
> > module.
> >
> > > guide which must be taken after loading the kmods.
> > I'm not sure what you mean by this. Are you referring to the qat
> > documentation that comes with the DPDK? I only see three additional items
> > there to address
> >
> > 1) Removing other modules when using the 01.org kernel modules
> >
> > 2) installation of firmware
> >
> > 3) Binding of the device to user space for VFIO/UIO
> >
> > All three of these tasks fall outside the scope of what this macro is meant to do.
> > We could try to create macros for them to export information for use in a
> > loading script if you like, but I wouldn't. All three of the above items fall in my
> > mind under the category of administrative responsibilities. That is to say, they
> > are orthogonoal to defining a module dependency structure, and if they're
> > arent properly completed, the module dependency chain won't matter anyway.
> >
>
> Another manual step is documented, which must be done after insmod:
> echo 32 > /sys/bus/pci/drivers/dh895xcc/0000\:03\:00.0/sriov_numvfs
> (steps will vary for different hardware types)
> Which I agree like the others are outside the scope of what this macro is meant to do.
> So using the macro to facilitate auto-loading of modules isn't a very useful feature
> for the QAT driver.
>
Ok, but by that logic then, defining any sort of dependency chain isn't really
usefull at all. If you need a custom per-driver script to load the right
modules and set their parameters correctly, you may as well just codify the
dependencies in the script, and leave the pmd out of it entirely.
Note I don't agree with that stance, It just seems to me like the most
reasonable conclusion to draw from your argument. If your intent is to just
provide a hint to some hardware specific script as to what modules to load, and
the sript then needs to still know independently that it has to set some
site/usecase specific parameters based on which modules were loaded, you may as
well just move the dependency map into that script so its all in one place.
> > > The use-case I'd addressed was for the script to identify and just
> > > throw an error where dependent modules are missing.
> > >
> >
> > That doesn't really add much value then, since missing modules already result in
> > errors when the PMD tries to initalize.
> >
> > > I don't see a simple solution, but also don't see a strong need to find one.
> > > Documentation and if necessary a driver-specific script seem sufficient to me.
> > >
> > > My conclusion is the RFC is a nice feature for some drivers, but if introduced
> > needs
> > > to be optional as it doesn't handle the complexities of all drivers.
> > >
> >
> > I agree its an optional export. If there are no dependencies, or if the author
> > wishes to to simply not supply any, thats fine, the results will be in
> > accordance with that, but I strongly disagree that its optional implies the fact
> > that we can ignore the complexities of the depedencies that can be exported.
> >
> > The more I think about it the more I like Stephens idea, possibly with some
> > macro assistance. That is to say:
> >
> > 1) Start by loading hardware specific modules, the information for which is
> > already available. You can parse the pci table that a pmd exports and match it
> > with the pci aliases retrieved via modinfo
> >
> > 2) Load a special virt driver if no hardware is found on the system in (1).
> > special virt drivers might be worth tagging with a VIRT/VFIO/UIO tag export for
> > pmdinfo
> >
> > That allows to set asside the complexities of our dependency chain, as we can
> > assume hardware support modules will codify any real dependencies there, and
> > a
> > VIRT tag will let us find any modules needed for hardware the is assigned into
> > our guest.
> >
> > Neil
> >
> > Neil
> >
> > > > >
> > > > > I ended up writing a script that went the other way.
> > > > > First look at the hardware and load VFIO if IOMMU is available.
> > > > > Then look for special driver needed for Xen and HyperV Lastly fallback
> > > > > to loading igb_uio if no VFIO and PCI device present.
> > > > >
> > > > > In other words it is a system not driver issue.
> > > > >
> > > > That sounds like a reasonable approach, yes.
> > > > Neil
> > > >
> > > > >
> > >
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
2016-09-02 14:15 ` Neil Horman
@ 2016-09-02 16:13 ` Olivier Matz
0 siblings, 0 replies; 46+ messages in thread
From: Olivier Matz @ 2016-09-02 16:13 UTC (permalink / raw)
To: Neil Horman, Trahe, Fiona; +Cc: Stephen Hemminger, dev, Thomas Monjalon
Hi,
Thank you everyone for all these comments. I'll try to summarize them here:
a- the kmod information should be per-device instead of per-driver
(modalias-like)
b- there is no need to specify kmod dependencies (i.e. "uio_pci_generic"
is enough, not "uio & uio_pci_generic") since it is available via modinfo
c- the syntax with commas and colons is not ideal, we have no better
consensus for now, but maybe "&" and "|" are better.
d- the information provided is not complete:
- some drivers requires module parameters or writing is /sys
- choosing between one kmod or another is a system choice
-> this info could be optional for this reason
e- for usual drivers having a "<generic-uio>" tag instead of a kmod list
may be more simple (I'm not sure of it though)
So we could either:
- drop this RFC, and like today everyone shoule handle the loading of
kmods on its own
- keep the approach of this RFC, enhance it with a- b- c- e-
Examples of string to manage specify the devices wildcards:
/* kmod list for all pci devices */
"pci:v*:d*:sv*:sd*:vfio|uio_pci_generic|igb_uio"
/* if we need device-specific modules: */
"pci:v8086:d1234:sv*:sd*:some_kmod"
"pci:v8086:d4321:sv*:sd*:some_other_kmod"
this is not a perfect solution, but I think it would make the
development of an kmod autoload script easier.
Any other idea?
Thanks,
Olivier
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH] drivers: advertise kmod dependencies in pmdinfo
2016-08-26 13:20 [RFC] drivers: advertise kmod dependencies in pmdinfo Olivier Matz
2016-08-30 8:40 ` Matej Vido
2016-08-30 13:23 ` [dpdk-dev, RFC] " Neil Horman
@ 2016-09-15 14:22 ` Olivier Matz
2016-09-16 9:49 ` Trahe, Fiona
` (2 more replies)
2 siblings, 3 replies; 46+ messages in thread
From: Olivier Matz @ 2016-09-15 14:22 UTC (permalink / raw)
To: dev, nhorman; +Cc: thomas.monjalon, vido, fiona.trahe, stephen
Add a new macro DRIVER_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>
---
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 | 1 +
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, 55 insertions(+), 1 deletion(-)
diff --git a/buildtools/pmdinfogen/pmdinfogen.c b/buildtools/pmdinfogen/pmdinfogen.c
index e1bf2e4..1e5b6f3 100644
--- a/buildtools/pmdinfogen/pmdinfogen.c
+++ b/buildtools/pmdinfogen/pmdinfogen.c
@@ -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)
diff --git a/buildtools/pmdinfogen/pmdinfogen.h b/buildtools/pmdinfogen/pmdinfogen.h
index 1da2966..2fab2aa 100644
--- a/buildtools/pmdinfogen/pmdinfogen.h
+++ b/buildtools/pmdinfogen/pmdinfogen.h
@@ -85,6 +85,7 @@ else \
enum opt_params {
PMD_PARAM_STRING = 0,
+ PMD_KMOD_DEP,
PMD_OPT_MAX
};
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index f3ab355..e422388 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -667,5 +667,7 @@ static struct rte_driver rte_bnx2xvf_driver = {
PMD_REGISTER_DRIVER(rte_bnx2x_driver, bnx2x);
DRIVER_REGISTER_PCI_TABLE(bnx2x, pci_id_bnx2x_map);
+DRIVER_REGISTER_KMOD_DEP(bnx2x, "* igb_uio | uio_pci_generic | vfio");
PMD_REGISTER_DRIVER(rte_bnx2xvf_driver, bnx2xvf);
DRIVER_REGISTER_PCI_TABLE(bnx2xvf, pci_id_bnx2xvf_map);
+DRIVER_REGISTER_KMOD_DEP(bnx2xvf, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 3795fac..cc9e2b2 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1068,3 +1068,4 @@ static struct rte_driver bnxt_pmd_drv = {
PMD_REGISTER_DRIVER(bnxt_pmd_drv, bnxt);
DRIVER_REGISTER_PCI_TABLE(bnxt, bnxt_pci_id_map);
+DRIVER_REGISTER_KMOD_DEP(bnxt, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 9208a61..4bdf0ea 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -1068,4 +1068,5 @@ static struct rte_driver rte_cxgbe_driver = {
PMD_REGISTER_DRIVER(rte_cxgbe_driver, cxgb4);
DRIVER_REGISTER_PCI_TABLE(cxgb4, cxgb4_pci_tbl);
+DRIVER_REGISTER_KMOD_DEP(cxgb4, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index ad104ed..7bb51d4 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -1806,3 +1806,4 @@ struct rte_driver em_pmd_drv = {
PMD_REGISTER_DRIVER(em_pmd_drv, em);
DRIVER_REGISTER_PCI_TABLE(em, pci_id_em_map);
+DRIVER_REGISTER_KMOD_DEP(em, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 4e9e6a3..ba5f5e2 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -5257,5 +5257,7 @@ eth_igb_configure_msix_intr(struct rte_eth_dev *dev)
PMD_REGISTER_DRIVER(pmd_igb_drv, igb);
DRIVER_REGISTER_PCI_TABLE(igb, pci_id_igb_map);
+DRIVER_REGISTER_KMOD_DEP(igb, "* igb_uio | uio_pci_generic | vfio");
PMD_REGISTER_DRIVER(pmd_igbvf_drv, igbvf);
DRIVER_REGISTER_PCI_TABLE(igbvf, pci_id_igbvf_map);
+DRIVER_REGISTER_KMOD_DEP(igbvf, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index ac0803d..8c1ba69 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -1709,3 +1709,4 @@ struct rte_driver ena_pmd_drv = {
PMD_REGISTER_DRIVER(ena_pmd_drv, ena);
DRIVER_REGISTER_PCI_TABLE(ena, pci_id_ena_map);
+DRIVER_REGISTER_KMOD_DEP(ena, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 47b07c9..6ef3a39 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -642,3 +642,4 @@ static struct rte_driver rte_enic_driver = {
PMD_REGISTER_DRIVER(rte_enic_driver, enic);
DRIVER_REGISTER_PCI_TABLE(enic, pci_id_enic_map);
+DRIVER_REGISTER_KMOD_DEP(enic, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 01f4a72..b1b3179 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -3086,3 +3086,4 @@ static struct rte_driver rte_fm10k_driver = {
PMD_REGISTER_DRIVER(rte_fm10k_driver, fm10k);
DRIVER_REGISTER_PCI_TABLE(fm10k, pci_id_fm10k_map);
+DRIVER_REGISTER_KMOD_DEP(fm10k, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index d0aeb70..20b5fd4 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -723,6 +723,7 @@ static struct rte_driver rte_i40e_driver = {
PMD_REGISTER_DRIVER(rte_i40e_driver, i40e);
DRIVER_REGISTER_PCI_TABLE(i40e, pci_id_i40e_map);
+DRIVER_REGISTER_KMOD_DEP(i40e, "* igb_uio | uio_pci_generic | vfio");
/*
* Initialize registers for flexible payload, which should be set by NVM.
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
index a616ae0..ccad3b5 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1586,6 +1586,7 @@ static struct rte_driver rte_i40evf_driver = {
PMD_REGISTER_DRIVER(rte_i40evf_driver, i40evf);
DRIVER_REGISTER_PCI_TABLE(i40evf, pci_id_i40evf_map);
+DRIVER_REGISTER_KMOD_DEP(i40evf, "* igb_uio | uio_pci_generic | vfio");
static int
i40evf_dev_configure(struct rte_eth_dev *dev)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index fb618ef..2b837dc 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -7421,5 +7421,7 @@ static struct rte_driver rte_ixgbevf_driver = {
PMD_REGISTER_DRIVER(rte_ixgbe_driver, ixgbe);
DRIVER_REGISTER_PCI_TABLE(ixgbe, pci_id_ixgbe_map);
+DRIVER_REGISTER_KMOD_DEP(ixgbe, "* igb_uio | uio_pci_generic | vfio");
PMD_REGISTER_DRIVER(rte_ixgbevf_driver, ixgbevf);
DRIVER_REGISTER_PCI_TABLE(ixgbevf, pci_id_ixgbevf_map);
+DRIVER_REGISTER_KMOD_DEP(ixgbevf, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 304c846..b211c37 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -5948,3 +5948,4 @@ static struct rte_driver rte_mlx4_driver = {
PMD_REGISTER_DRIVER(rte_mlx4_driver, mlx4);
DRIVER_REGISTER_PCI_TABLE(mlx4, mlx4_pci_id_map);
+DRIVER_REGISTER_KMOD_DEP(mlx4, "* ib_uverbs & mlx4_en & mlx4_ib");
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index d96a9af..05fc2e2 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -763,3 +763,4 @@ static struct rte_driver rte_mlx5_driver = {
PMD_REGISTER_DRIVER(rte_mlx5_driver, mlx5);
DRIVER_REGISTER_PCI_TABLE(mlx5, mlx5_pci_id_map);
+DRIVER_REGISTER_KMOD_DEP(mlx5, "* ib_uverbs & mlx5_ib");
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 82e3e4e..0d60baa 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -2488,6 +2488,7 @@ static struct rte_driver rte_nfp_net_driver = {
PMD_REGISTER_DRIVER(rte_nfp_net_driver, nfp);
DRIVER_REGISTER_PCI_TABLE(nfp, pci_id_nfp_net_map);
+DRIVER_REGISTER_KMOD_DEP(nfp, "* igb_uio | uio_pci_generic | vfio");
/*
* Local variables:
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 82e44b8..ded45c8 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -1530,5 +1530,7 @@ static struct rte_driver rte_qede_driver = {
PMD_REGISTER_DRIVER(rte_qede_driver, qede);
DRIVER_REGISTER_PCI_TABLE(qede, pci_id_qede_map);
+DRIVER_REGISTER_KMOD_DEP(qede, "* igb_uio | uio_pci_generic | vfio");
PMD_REGISTER_DRIVER(rte_qedevf_driver, qedevf);
DRIVER_REGISTER_PCI_TABLE(qedevf, pci_id_qedevf_map);
+DRIVER_REGISTER_KMOD_DEP(qedevf, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/szedata2/rte_eth_szedata2.c b/drivers/net/szedata2/rte_eth_szedata2.c
index 483d789..dac0157 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -1602,3 +1602,5 @@ static struct rte_driver rte_szedata2_driver = {
PMD_REGISTER_DRIVER(rte_szedata2_driver, RTE_SZEDATA2_DRIVER_NAME);
DRIVER_REGISTER_PCI_TABLE(RTE_SZEDATA2_DRIVER_NAME, rte_szedata2_pci_id_table);
+DRIVER_REGISTER_KMOD_DEP(RTE_SZEDATA2_DRIVER_NAME,
+ "* combo6core & combov3 & szedata2 & szedata2_cv3");
diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c
index 4f875c0..6d0af41 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -1785,3 +1785,4 @@ static struct rte_driver rte_nicvf_driver = {
PMD_REGISTER_DRIVER(rte_nicvf_driver, thunderx_nicvf);
DRIVER_REGISTER_PCI_TABLE(thunderx_nicvf, pci_id_nicvf_map);
+DRIVER_REGISTER_KMOD_DEP(thunderx_nicvf, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 07d6449..3b6ce5e 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1570,3 +1570,4 @@ static struct rte_driver rte_virtio_driver = {
PMD_REGISTER_DRIVER(rte_virtio_driver, virtio_net);
DRIVER_REGISTER_PCI_TABLE(virtio_net, pci_id_virtio_map);
+DRIVER_REGISTER_KMOD_DEP(virtio_net, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 5874215..feff79c 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -955,3 +955,4 @@ static struct rte_driver rte_vmxnet3_driver = {
PMD_REGISTER_DRIVER(rte_vmxnet3_driver, vmxnet3);
DRIVER_REGISTER_PCI_TABLE(vmxnet3, pci_id_vmxnet3_map);
+DRIVER_REGISTER_KMOD_DEP(vmxnet3, "* igb_uio | uio_pci_generic | vfio");
diff --git a/lib/librte_eal/common/include/rte_dev.h b/lib/librte_eal/common/include/rte_dev.h
index 95789f9..1f3e0cc 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -203,6 +203,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 DRIVER_REGISTER_KMOD_DEP(name, str) \
+static const char DRV_EXP_TAG(name, kmod_dep_export)[] \
+__attribute__((used)) = str
+
#ifdef __cplusplus
}
#endif
diff --git a/tools/dpdk-pmdinfo.py b/tools/dpdk-pmdinfo.py
index dcc8db8..9ff76a2 100755
--- a/tools/dpdk-pmdinfo.py
+++ b/tools/dpdk-pmdinfo.py
@@ -312,7 +312,10 @@ class ReadElf(object):
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:]
--
2.8.1
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH] drivers: advertise kmod dependencies in pmdinfo
2016-09-15 14:22 ` [PATCH] " Olivier Matz
@ 2016-09-16 9:49 ` Trahe, Fiona
2016-09-16 14:26 ` David Marchand
2016-11-22 9:50 ` [PATCH v2] " Olivier Matz
2 siblings, 0 replies; 46+ messages in thread
From: Trahe, Fiona @ 2016-09-16 9:49 UTC (permalink / raw)
To: Olivier Matz, dev, nhorman; +Cc: thomas.monjalon, vido, stephen, Trahe, Fiona
Hi Oliver,
> -----Original Message-----
> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Thursday, September 15, 2016 3:23 PM
> To: dev@dpdk.org; nhorman@tuxdriver.com
> Cc: thomas.monjalon@6wind.com; vido@cesnet.cz; Trahe, Fiona
> <fiona.trahe@intel.com>; stephen@networkplumber.org
> Subject: [PATCH] drivers: advertise kmod dependencies in pmdinfo
>
> Add a new macro DRIVER_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>
> ---
>
> 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
>
The per-device info is a nice addition to this feature.
Though for the reasons already described the qat driver dependencies are better
handled through documentation and scripts.
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH] drivers: advertise kmod dependencies in pmdinfo
2016-09-15 14:22 ` [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-11-22 9:50 ` [PATCH v2] " Olivier Matz
2 siblings, 1 reply; 46+ messages in thread
From: David Marchand @ 2016-09-16 14:26 UTC (permalink / raw)
To: Olivier Matz
Cc: Neil Horman, Thomas Monjalon, vido, fiona.trahe, Stephen Hemminger, dev
On Thu, Sep 15, 2016 at 4:22 PM, Olivier Matz <olivier.matz@6wind.com> wrote:
> Add a new macro DRIVER_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>
Thanks Olivier, this looks good to me.
Btw, I remember some issues with binding ixgbevf devices to
uio_pci_generic, so advertising should be carefully checked for each
driver.
Could drivers maintainers have a look at this ?
--
David Marchand
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH] drivers: advertise kmod dependencies in pmdinfo
2016-09-16 14:26 ` David Marchand
@ 2016-09-19 8:17 ` Bruce Richardson
2016-09-19 12:25 ` Olivier Matz
0 siblings, 1 reply; 46+ messages in thread
From: Bruce Richardson @ 2016-09-19 8:17 UTC (permalink / raw)
To: David Marchand
Cc: Olivier Matz, Neil Horman, Thomas Monjalon, vido, fiona.trahe,
Stephen Hemminger, dev
On Fri, Sep 16, 2016 at 04:26:35PM +0200, David Marchand wrote:
> On Thu, Sep 15, 2016 at 4:22 PM, Olivier Matz <olivier.matz@6wind.com> wrote:
> > Add a new macro DRIVER_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>
>
> Thanks Olivier, this looks good to me.
>
> Btw, I remember some issues with binding ixgbevf devices to
> uio_pci_generic, so advertising should be carefully checked for each
> driver.
+1 here. In general, uio_pci_generic will not bind to VF devices as VF devices
don't provide legacy interrupts, which is required to use uio_pci_generic. It's
not limited to just ixgbevf
/Bruce
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH] drivers: advertise kmod dependencies in pmdinfo
2016-09-19 8:17 ` Bruce Richardson
@ 2016-09-19 12:25 ` Olivier Matz
0 siblings, 0 replies; 46+ messages in thread
From: Olivier Matz @ 2016-09-19 12:25 UTC (permalink / raw)
To: Bruce Richardson, David Marchand
Cc: Neil Horman, Thomas Monjalon, vido, fiona.trahe, Stephen Hemminger, dev
Hi,
On 09/19/2016 10:17 AM, Bruce Richardson wrote:
> On Fri, Sep 16, 2016 at 04:26:35PM +0200, David Marchand wrote:
>> On Thu, Sep 15, 2016 at 4:22 PM, Olivier Matz <olivier.matz@6wind.com> wrote:
>>> Add a new macro DRIVER_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>
>>
>> Thanks Olivier, this looks good to me.
>>
>> Btw, I remember some issues with binding ixgbevf devices to
>> uio_pci_generic, so advertising should be carefully checked for each
>> driver.
>
> +1 here. In general, uio_pci_generic will not bind to VF devices as VF devices
> don't provide legacy interrupts, which is required to use uio_pci_generic. It's
> not limited to just ixgbevf
Thanks for commenting, I'll remove uio_pci_generic from *vf drivers in
next version.
Olivier
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v2] drivers: advertise kmod dependencies in pmdinfo
2016-09-15 14:22 ` [PATCH] " Olivier Matz
2016-09-16 9:49 ` Trahe, Fiona
2016-09-16 14:26 ` David Marchand
@ 2016-11-22 9:50 ` Olivier Matz
2016-11-22 10:27 ` Adrien Mazarguil
2016-12-15 13:46 ` [PATCH v3] " Olivier Matz
2 siblings, 2 replies; 46+ messages in thread
From: Olivier Matz @ 2016-11-22 9:50 UTC (permalink / raw)
To: dev; +Cc: nhorman, thomas.monjalon, vido, fiona.trahe, stephen
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>
---
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 | 1 +
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, 55 insertions(+), 1 deletion(-)
diff --git a/buildtools/pmdinfogen/pmdinfogen.c b/buildtools/pmdinfogen/pmdinfogen.c
index 59ab956..5129c57 100644
--- a/buildtools/pmdinfogen/pmdinfogen.c
+++ b/buildtools/pmdinfogen/pmdinfogen.c
@@ -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)
diff --git a/buildtools/pmdinfogen/pmdinfogen.h b/buildtools/pmdinfogen/pmdinfogen.h
index 1da2966..2fab2aa 100644
--- a/buildtools/pmdinfogen/pmdinfogen.h
+++ b/buildtools/pmdinfogen/pmdinfogen.h
@@ -85,6 +85,7 @@ else \
enum opt_params {
PMD_PARAM_STRING = 0,
+ PMD_KMOD_DEP,
PMD_OPT_MAX
};
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 0eae433..0f1e4a2 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -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");
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 035fe07..a24e153 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -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");
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index b7f28eb..317598d 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -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");
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index aee3d34..866a5cf 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -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");
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 2fddf0c..08f2a68 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -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");
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index ab9a178..555fb31 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -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");
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 2b154ec..f997302 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -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");
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 923690c..fe74f6d 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -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");
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 67778ba..b0c0fbf 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -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))
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
index aa306d6..7869b9b 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -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)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index edc9b22..baffc71 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -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");
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index da61a85..a0065bf 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -5937,3 +5937,4 @@ 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, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 90cc35e..b0343f3 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -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, "* igb_uio | uio_pci_generic | vfio");
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index c6b1587..707be8b 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -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:
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index d106dd0..001166a 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -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");
diff --git a/drivers/net/szedata2/rte_eth_szedata2.c b/drivers/net/szedata2/rte_eth_szedata2.c
index f3cd52d..677ba9f 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -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");
diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c
index 466e49c..db03fa8 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -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");
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 079fd6c..1bd60e9 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -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");
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 8bb13e5..93c9ac9 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -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");
diff --git a/lib/librte_eal/common/include/rte_dev.h b/lib/librte_eal/common/include/rte_dev.h
index 8840380..1708244 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -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
diff --git a/tools/dpdk-pmdinfo.py b/tools/dpdk-pmdinfo.py
index 3db9819..17bfed4 100755
--- a/tools/dpdk-pmdinfo.py
+++ b/tools/dpdk-pmdinfo.py
@@ -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:]
--
2.8.1
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v2] drivers: advertise kmod dependencies in pmdinfo
2016-11-22 9:50 ` [PATCH v2] " Olivier Matz
@ 2016-11-22 10:27 ` Adrien Mazarguil
2016-11-22 10:31 ` Olivier Matz
2016-12-15 13:46 ` [PATCH v3] " Olivier Matz
1 sibling, 1 reply; 46+ messages in thread
From: Adrien Mazarguil @ 2016-11-22 10:27 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, nhorman, thomas.monjalon, vido, fiona.trahe, stephen
Hi Olivier,
Neither mlx4 nor mlx5 depend on igb/uio/vfio modules, please see below.
On Tue, Nov 22, 2016 at 10:50:57AM +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>
> ---
[...]
> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
> index da61a85..a0065bf 100644
> --- a/drivers/net/mlx4/mlx4.c
> +++ b/drivers/net/mlx4/mlx4.c
> @@ -5937,3 +5937,4 @@ 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, "* igb_uio | uio_pci_generic | vfio");
RTE_PMD_REGISTER_KMOD_DEP(net_mlx4, "* ib_uverbs & mlx4_en & mlx4_core & mlx4_ib");
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
> index 90cc35e..b0343f3 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -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, "* igb_uio | uio_pci_generic | vfio");
RTE_PMD_REGISTER_KMOD_DEP(net_mlx5, "* ib_uverbs & mlx5_core & mlx5_ib");
--
Adrien Mazarguil
6WIND
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2] drivers: advertise kmod dependencies in pmdinfo
2016-11-22 10:27 ` Adrien Mazarguil
@ 2016-11-22 10:31 ` Olivier Matz
0 siblings, 0 replies; 46+ messages in thread
From: Olivier Matz @ 2016-11-22 10:31 UTC (permalink / raw)
To: Adrien Mazarguil
Cc: dev, nhorman, thomas.monjalon, vido, fiona.trahe, stephen
Hi Adrien,
On 11/22/2016 11:27 AM, Adrien Mazarguil wrote:
> Hi Olivier,
>
> Neither mlx4 nor mlx5 depend on igb/uio/vfio modules, please see below.
>
> On Tue, Nov 22, 2016 at 10:50:57AM +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>
>> ---
> [...]
>> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
>> index da61a85..a0065bf 100644
>> --- a/drivers/net/mlx4/mlx4.c
>> +++ b/drivers/net/mlx4/mlx4.c
>> @@ -5937,3 +5937,4 @@ 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, "* igb_uio | uio_pci_generic | vfio");
>
> RTE_PMD_REGISTER_KMOD_DEP(net_mlx4, "* ib_uverbs & mlx4_en & mlx4_core & mlx4_ib");
>
>> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
>> index 90cc35e..b0343f3 100644
>> --- a/drivers/net/mlx5/mlx5.c
>> +++ b/drivers/net/mlx5/mlx5.c
>> @@ -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, "* igb_uio | uio_pci_generic | vfio");
>
> RTE_PMD_REGISTER_KMOD_DEP(net_mlx5, "* ib_uverbs & mlx5_core & mlx5_ib");
>
Thank you for reviewing. I messed up in the rebase, the v1 was
closer to what you suggest, sorry. I'll send an update.
Olivier
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-11-22 9:50 ` [PATCH v2] " Olivier Matz
2016-11-22 10:27 ` Adrien Mazarguil
@ 2016-12-15 13:46 ` Olivier Matz
2016-12-15 14:52 ` Ferruh Yigit
` (2 more replies)
1 sibling, 3 replies; 46+ messages in thread
From: Olivier Matz @ 2016-12-15 13:46 UTC (permalink / raw)
To: dev
Cc: nhorman, thomas.monjalon, vido, fiona.trahe, stephen, adrien.mazarguil
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(-)
diff --git a/buildtools/pmdinfogen/pmdinfogen.c b/buildtools/pmdinfogen/pmdinfogen.c
index 59ab956..5129c57 100644
--- a/buildtools/pmdinfogen/pmdinfogen.c
+++ b/buildtools/pmdinfogen/pmdinfogen.c
@@ -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)
diff --git a/buildtools/pmdinfogen/pmdinfogen.h b/buildtools/pmdinfogen/pmdinfogen.h
index e9eabff..27bab30 100644
--- a/buildtools/pmdinfogen/pmdinfogen.h
+++ b/buildtools/pmdinfogen/pmdinfogen.h
@@ -89,6 +89,7 @@ else \
enum opt_params {
PMD_PARAM_STRING = 0,
+ PMD_KMOD_DEP,
PMD_OPT_MAX
};
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 0eae433..0f1e4a2 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -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");
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 035fe07..a24e153 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -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");
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index b7f28eb..317598d 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -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");
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index aee3d34..866a5cf 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -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");
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 2fddf0c..08f2a68 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -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");
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index ab9a178..555fb31 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -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");
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 2b154ec..f997302 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -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");
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 923690c..fe74f6d 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -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");
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 67778ba..b0c0fbf 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -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))
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
index aa306d6..7869b9b 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -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)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index edc9b22..baffc71 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -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");
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index da61a85..90c3c07 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -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");
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 90cc35e..206c9f9 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -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");
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index de80b46..e315dd8 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -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:
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index d106dd0..001166a 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -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");
diff --git a/drivers/net/szedata2/rte_eth_szedata2.c b/drivers/net/szedata2/rte_eth_szedata2.c
index f3cd52d..677ba9f 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -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");
diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c
index 466e49c..db03fa8 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -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");
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 079fd6c..1bd60e9 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -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");
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 8bb13e5..93c9ac9 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -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");
diff --git a/lib/librte_eal/common/include/rte_dev.h b/lib/librte_eal/common/include/rte_dev.h
index 8840380..1708244 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -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
diff --git a/tools/dpdk-pmdinfo.py b/tools/dpdk-pmdinfo.py
index 3db9819..17bfed4 100755
--- a/tools/dpdk-pmdinfo.py
+++ b/tools/dpdk-pmdinfo.py
@@ -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:]
--
2.8.1
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-15 13:46 ` [PATCH v3] " Olivier Matz
@ 2016-12-15 14:52 ` Ferruh Yigit
2016-12-16 9:36 ` Olivier Matz
2016-12-15 16:09 ` Neil Horman
2016-12-16 8:23 ` Adrien Mazarguil
2 siblings, 1 reply; 46+ messages in thread
From: Ferruh Yigit @ 2016-12-15 14:52 UTC (permalink / raw)
To: Olivier Matz, dev
Cc: nhorman, thomas.monjalon, vido, fiona.trahe, stephen,
adrien.mazarguil, Thomas Monjalon
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
<...>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-15 13:46 ` [PATCH v3] " Olivier Matz
2016-12-15 14:52 ` Ferruh Yigit
@ 2016-12-15 16:09 ` Neil Horman
2016-12-15 17:22 ` Stephen Hemminger
2016-12-16 8:23 ` Adrien Mazarguil
2 siblings, 1 reply; 46+ messages in thread
From: Neil Horman @ 2016-12-15 16:09 UTC (permalink / raw)
To: Olivier Matz
Cc: dev, thomas.monjalon, vido, fiona.trahe, stephen, adrien.mazarguil
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-15 16:09 ` Neil Horman
@ 2016-12-15 17:22 ` Stephen Hemminger
2016-12-16 9:22 ` Olivier Matz
0 siblings, 1 reply; 46+ messages in thread
From: Stephen Hemminger @ 2016-12-15 17:22 UTC (permalink / raw)
To: Neil Horman
Cc: Olivier Matz, dev, thomas.monjalon, vido, fiona.trahe, adrien.mazarguil
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-15 13:46 ` [PATCH v3] " Olivier Matz
2016-12-15 14:52 ` Ferruh Yigit
2016-12-15 16:09 ` Neil Horman
@ 2016-12-16 8:23 ` Adrien Mazarguil
2016-12-20 17:26 ` Thomas Monjalon
2 siblings, 1 reply; 46+ messages in thread
From: Adrien Mazarguil @ 2016-12-16 8:23 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, nhorman, thomas.monjalon, vido, fiona.trahe, stephen
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>
--
Adrien Mazarguil
6WIND
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-15 17:22 ` Stephen Hemminger
@ 2016-12-16 9:22 ` Olivier Matz
2016-12-16 12:37 ` Neil Horman
0 siblings, 1 reply; 46+ messages in thread
From: Olivier Matz @ 2016-12-16 9:22 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Neil Horman, dev, thomas.monjalon, vido, fiona.trahe, adrien.mazarguil
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-15 14:52 ` Ferruh Yigit
@ 2016-12-16 9:36 ` Olivier Matz
2016-12-19 13:30 ` Thomas Monjalon
0 siblings, 1 reply; 46+ messages in thread
From: Olivier Matz @ 2016-12-16 9:36 UTC (permalink / raw)
To: Ferruh Yigit
Cc: dev, nhorman, thomas.monjalon, vido, fiona.trahe, stephen,
adrien.mazarguil
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-16 9:22 ` Olivier Matz
@ 2016-12-16 12:37 ` Neil Horman
2016-12-16 13:04 ` Bruce Richardson
2016-12-16 14:19 ` Ferruh Yigit
0 siblings, 2 replies; 46+ messages in thread
From: Neil Horman @ 2016-12-16 12:37 UTC (permalink / raw)
To: Olivier Matz
Cc: Stephen Hemminger, dev, thomas.monjalon, vido, fiona.trahe,
adrien.mazarguil
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
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-16 12:37 ` Neil Horman
@ 2016-12-16 13:04 ` Bruce Richardson
2016-12-16 14:19 ` Ferruh Yigit
1 sibling, 0 replies; 46+ messages in thread
From: Bruce Richardson @ 2016-12-16 13:04 UTC (permalink / raw)
To: Neil Horman
Cc: Olivier Matz, Stephen Hemminger, dev, thomas.monjalon, vido,
fiona.trahe, adrien.mazarguil
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-16 12:37 ` Neil Horman
2016-12-16 13:04 ` Bruce Richardson
@ 2016-12-16 14:19 ` Ferruh Yigit
2016-12-19 12:42 ` Neil Horman
1 sibling, 1 reply; 46+ messages in thread
From: Ferruh Yigit @ 2016-12-16 14:19 UTC (permalink / raw)
To: Neil Horman, Olivier Matz
Cc: Stephen Hemminger, dev, thomas.monjalon, vido, fiona.trahe,
adrien.mazarguil
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
>>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-16 14:19 ` Ferruh Yigit
@ 2016-12-19 12:42 ` Neil Horman
2016-12-19 14:12 ` Ferruh Yigit
0 siblings, 1 reply; 46+ messages in thread
From: Neil Horman @ 2016-12-19 12:42 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Olivier Matz, Stephen Hemminger, dev, thomas.monjalon, vido,
fiona.trahe, adrien.mazarguil
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-16 9:36 ` Olivier Matz
@ 2016-12-19 13:30 ` Thomas Monjalon
0 siblings, 0 replies; 46+ messages in thread
From: Thomas Monjalon @ 2016-12-19 13:30 UTC (permalink / raw)
To: Olivier Matz
Cc: Ferruh Yigit, dev, nhorman, vido, fiona.trahe, stephen, adrien.mazarguil
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-19 12:42 ` Neil Horman
@ 2016-12-19 14:12 ` Ferruh Yigit
0 siblings, 0 replies; 46+ messages in thread
From: Ferruh Yigit @ 2016-12-19 14:12 UTC (permalink / raw)
To: Neil Horman
Cc: Olivier Matz, Stephen Hemminger, dev, thomas.monjalon, vido,
fiona.trahe, adrien.mazarguil
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
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-16 8:23 ` Adrien Mazarguil
@ 2016-12-20 17:26 ` Thomas Monjalon
2016-12-21 9:21 ` Andrew Rybchenko
0 siblings, 1 reply; 46+ messages in thread
From: Thomas Monjalon @ 2016-12-20 17:26 UTC (permalink / raw)
To: Olivier Matz; +Cc: Adrien Mazarguil, dev, nhorman, vido, fiona.trahe, stephen
> > 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-20 17:26 ` Thomas Monjalon
@ 2016-12-21 9:21 ` Andrew Rybchenko
2016-12-21 11:37 ` Neil Horman
0 siblings, 1 reply; 46+ messages in thread
From: Andrew Rybchenko @ 2016-12-21 9:21 UTC (permalink / raw)
To: Thomas Monjalon, Olivier Matz
Cc: Adrien Mazarguil, dev, nhorman, vido, fiona.trahe, stephen
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-21 9:21 ` Andrew Rybchenko
@ 2016-12-21 11:37 ` Neil Horman
2016-12-21 11:40 ` Andrew Rybchenko
0 siblings, 1 reply; 46+ messages in thread
From: Neil Horman @ 2016-12-21 11:37 UTC (permalink / raw)
To: Andrew Rybchenko
Cc: Thomas Monjalon, Olivier Matz, Adrien Mazarguil, dev, vido,
fiona.trahe, stephen
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.
>
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-21 11:37 ` Neil Horman
@ 2016-12-21 11:40 ` Andrew Rybchenko
2016-12-22 11:04 ` Ferruh Yigit
0 siblings, 1 reply; 46+ messages in thread
From: Andrew Rybchenko @ 2016-12-21 11:40 UTC (permalink / raw)
To: Neil Horman
Cc: Thomas Monjalon, Olivier Matz, Adrien Mazarguil, dev, vido,
fiona.trahe, stephen
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.
>>
>>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-21 11:40 ` Andrew Rybchenko
@ 2016-12-22 11:04 ` Ferruh Yigit
2016-12-22 11:35 ` Andrew Rybchenko
0 siblings, 1 reply; 46+ messages in thread
From: Ferruh Yigit @ 2016-12-22 11:04 UTC (permalink / raw)
To: Andrew Rybchenko, Neil Horman
Cc: Thomas Monjalon, Olivier Matz, Adrien Mazarguil, dev, vido,
fiona.trahe, stephen
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-22 11:04 ` Ferruh Yigit
@ 2016-12-22 11:35 ` Andrew Rybchenko
2016-12-22 12:07 ` Ferruh Yigit
0 siblings, 1 reply; 46+ messages in thread
From: Andrew Rybchenko @ 2016-12-22 11:35 UTC (permalink / raw)
To: Ferruh Yigit, Neil Horman
Cc: Thomas Monjalon, Olivier Matz, Adrien Mazarguil, dev, vido,
fiona.trahe, stephen
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-22 11:35 ` Andrew Rybchenko
@ 2016-12-22 12:07 ` Ferruh Yigit
2016-12-22 12:08 ` Andrew Rybchenko
0 siblings, 1 reply; 46+ messages in thread
From: Ferruh Yigit @ 2016-12-22 12:07 UTC (permalink / raw)
To: Andrew Rybchenko, Neil Horman
Cc: Thomas Monjalon, Olivier Matz, Adrien Mazarguil, dev, vido,
fiona.trahe, stephen
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.
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3] drivers: advertise kmod dependencies in pmdinfo
2016-12-22 12:07 ` Ferruh Yigit
@ 2016-12-22 12:08 ` Andrew Rybchenko
0 siblings, 0 replies; 46+ messages in thread
From: Andrew Rybchenko @ 2016-12-22 12:08 UTC (permalink / raw)
To: Ferruh Yigit, Neil Horman
Cc: Thomas Monjalon, Olivier Matz, Adrien Mazarguil, dev, vido,
fiona.trahe, stephen
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.
>>
^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2016-12-22 12:08 UTC | newest]
Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-26 13:20 [RFC] drivers: advertise kmod dependencies in pmdinfo Olivier Matz
2016-08-30 8:40 ` Matej Vido
2016-08-30 8:56 ` Olivier Matz
2016-08-30 13:23 ` [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 ` [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 ` [PATCH v2] " Olivier Matz
2016-11-22 10:27 ` Adrien Mazarguil
2016-11-22 10:31 ` Olivier Matz
2016-12-15 13:46 ` [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
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
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.