[dpdk-dev] [PATCHv4 2/5] drivers: Update driver registration macro usage
On Wed, May 25, 2016 at 06:20:06PM +0200, Thomas Monjalon wrote:
> 2016-05-24 15:41, Neil Horman:
> > Modify the PMD_REGISTER_DRIVER macro, adding a name argument to it. The
> > addition of a name argument creates a token that can be used for subsequent
> > macros in the creation of unique symbol names to export additional bits of
> > information for use by the pmdinfogen tool. For example:
> >
> > PMD_REGISTER_DRIVER(ena_driver, ena);
> >
> > registers the ena_driver struct as it always did, and creates a symbol
> > const char this_pmd_name0[] __attribute__((used)) = "ena";
> >
> > which pmdinfogen can search for and extract.
>
> The EAL rework (http://dpdk.org/ml/archives/dev/2016-April/037691.html)
> integrates already a name:
>
> +#define RTE_EAL_PCI_REGISTER(name, d) \
> +RTE_INIT(pciinitfn_ ##name); \
> +static void pciinitfn_ ##name(void) \
> +{ \
> + rte_eal_pci_register(); \
> +}
>
> I think it would be better to rebase on top of it.
>
Those patches are over a month old and still in the new state according to
patchwork. I'm not very comfortable rebasing (and implicitly blocking)
acceptance of this patch on that one. Its really a just two lines of conflict.
I
would suggest that, whichever patch gets integrated first, the other series can
rebase on the new head. It should be a pretty easy fix either way.
> > The subsequent macro
> >
> > DRIVER_REGISTER_PCI_TABLE(ena, ena_pci_id_map);
> >
> > creates a symbol
> > const char ena_pci_tbl_export[] __attribute__((used)) = "ena_pci_id_map";
> >
> > Which allows pmdinfogen to find the pci table of this driver
> >
> > Using this pattern, we can export arbitrary bits of information.
> >
> > pmdinfo uses this information to extract hardware support from an object
> > file
> > and create a json string to make hardware support info discoverable later.
>
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -34,4 +34,6 @@ include $(RTE_SDK)/mk/rte.vars.mk
> > DIRS-y += net
> > DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += crypto
> >
> > +DEPDIRS-y += buildtools/pmdinfo
>
> Why pmdinfo is a build dependency?
>
beause pmdinfogen has to be built and available for use prior to compiling the
rest of the dpdk. I suppose we could build it after, and then go back through
and check all the objects for driver info, but I'd rather build it first, and
search the objects as they are built.
> > --- a/lib/librte_eal/common/include/rte_dev.h
> > +++ b/lib/librte_eal/common/include/rte_dev.h
> > @@ -48,7 +48,7 @@ extern "C" {
> >
> > #include
> > #include
> > -
> > +#include
>
> Why not keep PCI stuff in rte_pci.h?
>
I am.
> > +#define DRV_EXP_TAG(n, t) __##n##_##t
> > +
> > +#define DRIVER_REGISTER_PCI_TABLE(n, t) \
> > +static const char DRV_EXP_TAG(n, pci_tbl_export)[] __attribute__((used)) =
> > RTE_STR(t)
>
> I really dislike one-char variables, especially when there is no comment.
> Please choose comments or explicit variables.
>
You mean you want the macro variables to be longer/more descriptive? I suppose,
but in fairness, we have lots of macros that use single letter variables, I'm
not sure why your concerned about these specifically. I'll change it though.
Neil
[dpdk-dev] [PATCHv4 2/5] drivers: Update driver registration macro usage
Modify the PMD_REGISTER_DRIVER macro, adding a name argument to it. The
addition of a name argument creates a token that can be used for subsequent
macros in the creation of unique symbol names to export additional bits of
information for use by the pmdinfogen tool. For example:
PMD_REGISTER_DRIVER(ena_driver, ena);
registers the ena_driver struct as it always did, and creates a symbol
const char this_pmd_name0[] __attribute__((used)) = "ena";
which pmdinfogen can search for and extract. The subsequent macro
DRIVER_REGISTER_PCI_TABLE(ena, ena_pci_id_map);
creates a symbol
const char ena_pci_tbl_export[] __attribute__((used)) = "ena_pci_id_map";
Which allows pmdinfogen to find the pci table of this driver
Using this pattern, we can export arbitrary bits of information.
pmdinfo uses this information to extract hardware support from an object file
and create a json string to make hardware support info discoverable later.
Signed-off-by: Neil Horman
CC: Bruce Richardson
CC: Thomas Monjalon
CC: Stephen Hemminger
CC: Panu Matilainen
---
drivers/Makefile | 2 ++
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 4 +++-
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 4 +++-
drivers/crypto/null/null_crypto_pmd.c | 4 +++-
drivers/crypto/qat/rte_qat_cryptodev.c | 4 +++-
drivers/crypto/snow3g/rte_snow3g_pmd.c | 4 +++-
drivers/net/af_packet/rte_eth_af_packet.c | 4 +++-
drivers/net/bnx2x/bnx2x_ethdev.c | 6 --
drivers/net/bonding/rte_eth_bond_pmd.c | 7 ++-
drivers/net/cxgbe/cxgbe_ethdev.c | 4 +++-
drivers/net/e1000/em_ethdev.c | 3 ++-
drivers/net/e1000/igb_ethdev.c | 6 --
drivers/net/ena/ena_ethdev.c | 3 ++-
drivers/net/enic/enic_ethdev.c | 3 ++-
drivers/net/fm10k/fm10k_ethdev.c | 3 ++-
drivers/net/i40e/i40e_ethdev.c | 3 ++-
drivers/net/i40e/i40e_ethdev_vf.c | 3 ++-
drivers/net/ixgbe/ixgbe_ethdev.c | 6 --
drivers/net/mlx4/mlx4.c| 3 ++-
drivers/net/mlx5/mlx5.c| 3 ++-
drivers/net/mpipe/mpipe_tilegx.c | 4 ++--
drivers/net/nfp/nfp_net.c | 3 ++-
drivers/net/null/rte_eth_null.c| 3 ++-
drivers/net/pcap/rte_eth_pcap.c| 4 +++-
drivers/net/qede/qede_ethdev.c | 6 --
drivers/net/ring/rte_eth_ring.c| 3 ++-
drivers/net/szedata2/rte_eth_szedata2.c| 3 ++-
drivers/net/vhost/rte_eth_vhost.c | 3 ++-
drivers/net/virtio/virtio_ethdev.c | 3 ++-
drivers/net/vmxnet3/vmxnet3_ethdev.c | 3 ++-
drivers/net/xenvirt/rte_eth_xenvirt.c | 2 +-
lib/librte_eal/common/include/rte_dev.h| 23 +++
32 files changed, 100 insertions(+), 39 deletions(-)
diff --git a/drivers/Makefile b/drivers/Makefile
index 81c03a8..75a3168 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -34,4 +34,6 @@ include $(RTE_SDK)/mk/rte.vars.mk
DIRS-y += net
DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += crypto
+DEPDIRS-y += buildtools/pmdinfo
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index 2987ef6..593769f 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -521,4 +521,6 @@ static struct rte_driver aesni_gcm_pmd_drv = {
.uninit = aesni_gcm_uninit
};
-PMD_REGISTER_DRIVER(aesni_gcm_pmd_drv);
+PMD_REGISTER_DRIVER(aesni_gcm_pmd_drv, aesni_gcm);
+DRIVER_REGISTER_PARAM_STRING(aesni_gcm, "max_nb_queue_pairs= \
+max_nb_sessions= socket_id=");
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index 3415ac1..2e30939 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -716,4 +716,6 @@ static struct rte_driver cryptodev_aesni_mb_pmd_drv = {
.uninit = cryptodev_aesni_mb_uninit
};
-PMD_REGISTER_DRIVER(cryptodev_aesni_mb_pmd_drv);
+PMD_REGISTER_DRIVER(cryptodev_aesni_mb_pmd_drvi, aesni_mb);
+DRIVER_REGISTER_PARAM_STRING(aesni_gcm, "max_nb_queue_pairs= \
+max_nb_sessions= socket_id=");
diff --git a/drivers/crypto/null/null_crypto_pmd.c
b/drivers/crypto/null/null_crypto_pmd.c
index bdaf13c..44c4fba 100644
--- a/drivers/crypto/null/null_crypto_pmd.c
+++ b/drivers/crypto/null/null_crypto_pmd.c
@@ -275,4 +275,6 @@ static struct rte_driver cryptodev_null_pmd_drv = {
.uninit = cryptodev_null_uninit
};
-PMD_REGISTER_DRIVER(cryptodev_null_pmd_drv);
+PMD_REGISTER_DRIVER(cryptodev_null_pmd_drv, cryptodev_null_pmd);
+DRIVER_REGISTER_PARAM_STRING(aesni_gcm, "max_nb_queue_pairs= \
+max_nb_sessions= socket_id=");
diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c
b/drivers/crypto/qat/rte_qat_cryptodev.c
index a7912f5..d2de6a6 100644
--- a/drivers/crypto/qat/rte_qat_cryptodev.c
+++ b/drivers/crypto/qat/rte_qat_cryptodev.c
