[dpdk-dev] [PATCH] drivers: make driver names consistent

[dpdk-dev] [PATCH] drivers: make driver names consistent

[Pablo de Lara]

As discussed in the past release, driver names are modified
to be more consistent, and the future driver should follow
this new convention.

Driver names consist of:
"driver category"_"driver folder name"_"optional extra name".

For example:
- Crypto null driver       -> "crypto_null"
- Network IXGBE VF driver  -> "net_ixgbe_vf"

Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
 app/pdump/main.c                          |  4 ++--
 doc/guides/cryptodevs/aesni_gcm.rst       |  6 +++---
 doc/guides/cryptodevs/aesni_mb.rst        |  6 +++---
 doc/guides/cryptodevs/kasumi.rst          |  6 +++---
 doc/guides/cryptodevs/null.rst            |  6 +++---
 doc/guides/cryptodevs/snow3g.rst          |  6 +++---
 doc/guides/nics/pcap_ring.rst             | 26 +++++++++++++-------------
 doc/guides/nics/vhost.rst                 |  2 +-
 doc/guides/xen/pkt_switch.rst             | 10 +++++-----
 drivers/net/af_packet/rte_eth_af_packet.c |  4 ++--
 drivers/net/bnx2x/bnx2x_ethdev.c          |  8 ++++----
 drivers/net/bnxt/bnxt_ethdev.c            |  4 ++--
 drivers/net/bonding/rte_eth_bond_pmd.c    |  4 ++--
 drivers/net/cxgbe/cxgbe_ethdev.c          |  4 ++--
 drivers/net/e1000/em_ethdev.c             |  4 ++--
 drivers/net/e1000/igb_ethdev.c            |  8 ++++----
 drivers/net/ena/ena_ethdev.c              |  4 ++--
 drivers/net/enic/enic_ethdev.c            |  4 ++--
 drivers/net/fm10k/fm10k_ethdev.c          |  4 ++--
 drivers/net/i40e/i40e_ethdev.c            |  4 ++--
 drivers/net/i40e/i40e_ethdev_vf.c         |  4 ++--
 drivers/net/ixgbe/ixgbe_ethdev.c          |  8 ++++----
 drivers/net/mlx4/mlx4.c                   |  4 ++--
 drivers/net/mlx5/mlx5.c                   |  4 ++--
 drivers/net/mpipe/mpipe_tilegx.c          |  4 ++--
 drivers/net/nfp/nfp_net.c                 |  4 ++--
 drivers/net/null/rte_eth_null.c           |  4 ++--
 drivers/net/pcap/rte_eth_pcap.c           |  4 ++--
 drivers/net/qede/qede_ethdev.c            |  8 ++++----
 drivers/net/ring/rte_eth_ring.c           |  4 ++--
 drivers/net/szedata2/rte_eth_szedata2.c   |  2 +-
 drivers/net/thunderx/nicvf_ethdev.c       |  4 ++--
 drivers/net/vhost/rte_eth_vhost.c         |  4 ++--
 drivers/net/virtio/virtio_ethdev.c        |  4 ++--
 drivers/net/virtio/virtio_user_ethdev.c   |  4 ++--
 drivers/net/vmxnet3/vmxnet3_ethdev.c      |  4 ++--
 drivers/net/xenvirt/rte_eth_xenvirt.c     |  4 ++--
 lib/librte_cryptodev/rte_cryptodev.h      | 12 ++++++------
 38 files changed, 105 insertions(+), 105 deletions(-)

diff --git a/app/pdump/main.c b/app/pdump/main.c
index b76cfd0..f3ef181 100644
--- a/app/pdump/main.c
+++ b/app/pdump/main.c
@@ -68,8 +68,8 @@
 #define CMD_LINE_OPT_SER_SOCK_PATH "server-socket-path"
 #define CMD_LINE_OPT_CLI_SOCK_PATH "client-socket-path"
 
-#define VDEV_PCAP "eth_pcap_%s_%d,tx_pcap=%s"
-#define VDEV_IFACE "eth_pcap_%s_%d,tx_iface=%s"
+#define VDEV_PCAP "net_pcap_%s_%d,tx_pcap=%s"
+#define VDEV_IFACE "net_pcap_%s_%d,tx_iface=%s"
 #define TX_STREAM_SIZE 64
 
 #define MP_NAME "pdump_pool_%d"
diff --git a/doc/guides/cryptodevs/aesni_gcm.rst b/doc/guides/cryptodevs/aesni_gcm.rst
index 7ff1c6b..04bf43c 100644
--- a/doc/guides/cryptodevs/aesni_gcm.rst
+++ b/doc/guides/cryptodevs/aesni_gcm.rst
@@ -64,9 +64,9 @@ In order to enable this virtual crypto PMD, user must:
 
 To use the PMD in an application, user must:
 
-* Call rte_eal_vdev_init("cryptodev_aesni_gcm_pmd") within the application.
+* Call rte_eal_vdev_init("crypto_aesni_gcm") within the application.
 
-* Use --vdev="cryptodev_aesni_gcm_pmd" in the EAL options, which will call rte_eal_vdev_init() internally.
+* Use --vdev="crypto_aesni_gcm" in the EAL options, which will call rte_eal_vdev_init() internally.
 
 The following parameters (all optional) can be provided in the previous two calls:
 
@@ -81,7 +81,7 @@ Example:
 
 .. code-block:: console
 
-    ./l2fwd-crypto -c 40 -n 4 --vdev="cryptodev_aesni_gcm_pmd,socket_id=1,max_nb_sessions=128"
+    ./l2fwd-crypto -c 40 -n 4 --vdev="crypto_aesni_gcm,socket_id=1,max_nb_sessions=128"
 
 Limitations
 -----------
diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
index 60a8914..a827751 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -96,9 +96,9 @@ In order to enable this virtual crypto PMD, user must:
 
 To use the PMD in an application, user must:
 
-* Call rte_eal_vdev_init("cryptodev_aesni_mb_pmd") within the application.
+* Call rte_eal_vdev_init("crypto_aesni_mb") within the application.
 
-* Use --vdev="cryptodev_aesni_mb_pmd" in the EAL options, which will call rte_eal_vdev_init() internally.
+* Use --vdev="crypto_aesni_mb" in the EAL options, which will call rte_eal_vdev_init() internally.
 
 The following parameters (all optional) can be provided in the previous two calls:
 
@@ -113,4 +113,4 @@ Example:
 
 .. code-block:: console
 
-    ./l2fwd-crypto -c 40 -n 4 --vdev="cryptodev_aesni_mb_pmd,socket_id=1,max_nb_sessions=128"
+    ./l2fwd-crypto -c 40 -n 4 --vdev="crypto_aesni_mb,socket_id=1,max_nb_sessions=128"
diff --git a/doc/guides/cryptodevs/kasumi.rst b/doc/guides/cryptodevs/kasumi.rst
index 7346b21..3e126df 100644
--- a/doc/guides/cryptodevs/kasumi.rst
+++ b/doc/guides/cryptodevs/kasumi.rst
@@ -84,9 +84,9 @@ In order to enable this virtual crypto PMD, user must:
 
 To use the PMD in an application, user must:
 
-* Call rte_eal_vdev_init("cryptodev_kasumi_pmd") within the application.
+* Call rte_eal_vdev_init("crypto_kasumi") within the application.
 
-* Use --vdev="cryptodev_kasumi_pmd" in the EAL options, which will call rte_eal_vdev_init() internally.
+* Use --vdev="crypto_kasumi" in the EAL options, which will call rte_eal_vdev_init() internally.
 
 The following parameters (all optional) can be provided in the previous two calls:
 
@@ -101,4 +101,4 @@ Example:
 
 .. code-block:: console
 
-    ./l2fwd-crypto -c 40 -n 4 --vdev="cryptodev_kasumi_pmd,socket_id=1,max_nb_sessions=128"
+    ./l2fwd-crypto -c 40 -n 4 --vdev="crypto_kasumi,socket_id=1,max_nb_sessions=128"
diff --git a/doc/guides/cryptodevs/null.rst b/doc/guides/cryptodevs/null.rst
index b68d4cd..ec5bc70 100644
--- a/doc/guides/cryptodevs/null.rst
+++ b/doc/guides/cryptodevs/null.rst
@@ -76,9 +76,9 @@ Initialization
 
 To use the PMD in an application, user must:
 
-* Call rte_eal_vdev_init("cryptodev_null_pmd") within the application.
+* Call rte_eal_vdev_init("crypto_null") within the application.
 
-* Use --vdev="cryptodev_null_pmd" in the EAL options, which will call rte_eal_vdev_init() internally.
+* Use --vdev="crypto_null" in the EAL options, which will call rte_eal_vdev_init() internally.
 
 The following parameters (all optional) can be provided in the previous two calls:
 
@@ -93,4 +93,4 @@ Example:
 
 .. code-block:: console
 
-    ./l2fwd-crypto -c 40 -n 4 --vdev="cryptodev_null_pmd,socket_id=1,max_nb_sessions=128"
+    ./l2fwd-crypto -c 40 -n 4 --vdev="crypto_null,socket_id=1,max_nb_sessions=128"
diff --git a/doc/guides/cryptodevs/snow3g.rst b/doc/guides/cryptodevs/snow3g.rst
index 670a62a..c2472e9 100644
--- a/doc/guides/cryptodevs/snow3g.rst
+++ b/doc/guides/cryptodevs/snow3g.rst
@@ -83,9 +83,9 @@ In order to enable this virtual crypto PMD, user must:
 
 To use the PMD in an application, user must:
 
-* Call rte_eal_vdev_init("cryptodev_snow3g_pmd") within the application.
+* Call rte_eal_vdev_init("crypto_snow3g") within the application.
 
-* Use --vdev="cryptodev_snow3g_pmd" in the EAL options, which will call rte_eal_vdev_init() internally.
+* Use --vdev="crypto_snow3g" in the EAL options, which will call rte_eal_vdev_init() internally.
 
 The following parameters (all optional) can be provided in the previous two calls:
 
@@ -100,4 +100,4 @@ Example:
 
 .. code-block:: console
 
-    ./l2fwd-crypto -c 40 -n 4 --vdev="cryptodev_snow3g_pmd,socket_id=1,max_nb_sessions=128"
+    ./l2fwd-crypto -c 40 -n 4 --vdev="crypto_snow3g,socket_id=1,max_nb_sessions=128"
diff --git a/doc/guides/nics/pcap_ring.rst b/doc/guides/nics/pcap_ring.rst
index aa48d33..0662d27 100644
--- a/doc/guides/nics/pcap_ring.rst
+++ b/doc/guides/nics/pcap_ring.rst
@@ -62,14 +62,14 @@ Libpcap-based PMD
 ~~~~~~~~~~~~~~~~~
 
 Pcap-based devices can be created using the virtual device --vdev option.
-The device name must start with the eth_pcap prefix followed by numbers or letters.
+The device name must start with the net_pcap prefix followed by numbers or letters.
 The name is unique for each device. Each device can have multiple stream options and multiple devices can be used.
 Multiple device definitions can be arranged using multiple --vdev.
 Device name and stream options must be separated by commas as shown below:
 
 .. code-block:: console
 
-   $RTE_TARGET/app/testpmd -c f -n 4 --vdev  'eth_pcap0,stream_opt0=..,stream_opt1=..' --vdev='eth_pcap1,stream_opt0=..'
+   $RTE_TARGET/app/testpmd -c f -n 4 --vdev  'net_pcap0,stream_opt0=..,stream_opt1=..' --vdev='net_pcap1,stream_opt0=..'
 
 Device Streams
 ^^^^^^^^^^^^^^
@@ -120,25 +120,25 @@ Read packets from one pcap file and write them to another:
 
 .. code-block:: console
 
-    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'eth_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained
+    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'net_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained
 
 Read packets from a network interface and write them to a pcap file:
 
 .. code-block:: console
 
-    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'eth_pcap0,rx_iface=eth0,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained
+    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'net_pcap0,rx_iface=eth0,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained
 
 Read packets from a pcap file and write them to a network interface:
 
 .. code-block:: console
 
-    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'eth_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_iface=eth1' -- --port-topology=chained
+    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'net_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_iface=eth1' -- --port-topology=chained
 
 Forward packets through two network interfaces:
 
 .. code-block:: console
 
-    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'eth_pcap0,iface=eth0' --vdev='eth_pcap1;iface=eth1'
+    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'net_pcap0,iface=eth0' --vdev='net_pcap1;iface=eth1'
 
 Using libpcap-based PMD with the testpmd Application
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -162,19 +162,19 @@ Otherwise, the first 512 packets from the input pcap file will be discarded by t
 
 .. code-block:: console
 
-    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'eth_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained --no-flush-rx
+    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'net_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained --no-flush-rx
 
 
 Rings-based PMD
 ~~~~~~~~~~~~~~~
 
 To run a DPDK application on a machine without any Ethernet devices, a pair of ring-based rte_ethdevs can be used as below.
-The device names passed to the --vdev option must start with eth_ring and take no additional parameters.
+The device names passed to the --vdev option must start with net_ring and take no additional parameters.
 Multiple devices may be specified, separated by commas.
 
 .. code-block:: console
 
-    ./testpmd -c E -n 4 --vdev=eth_ring0 --vdev=eth_ring1 -- -i
+    ./testpmd -c E -n 4 --vdev=net_ring0 --vdev=net_ring1 -- -i
     EAL: Detected lcore 1 as core 1 on socket 0
     ...
 
@@ -243,8 +243,8 @@ for reception on the same port (error handling omitted for clarity):
 
     /* create two ethdev's */
 
-    port0 = rte_eth_from_rings("eth_ring0", ring, NUM_RINGS, ring, NUM_RINGS, SOCKET0);
-    port1 = rte_eth_from_rings("eth_ring1", ring, NUM_RINGS, ring, NUM_RINGS, SOCKET0);
+    port0 = rte_eth_from_rings("net_ring0", ring, NUM_RINGS, ring, NUM_RINGS, SOCKET0);
+    port1 = rte_eth_from_rings("net_ring1", ring, NUM_RINGS, ring, NUM_RINGS, SOCKET0);
 
 
 To create two pseudo-Ethernet ports where the traffic is switched between them,
@@ -253,8 +253,8 @@ the final two lines could be changed as below:
 
 .. code-block:: c
 
-    port0 = rte_eth_from_rings("eth_ring0", &ring[0], 1, &ring[1], 1, SOCKET0);
-    port1 = rte_eth_from_rings("eth_ring1", &ring[1], 1, &ring[0], 1, SOCKET0);
+    port0 = rte_eth_from_rings("net_ring0", &ring[0], 1, &ring[1], 1, SOCKET0);
+    port1 = rte_eth_from_rings("net_ring1", &ring[1], 1, &ring[0], 1, SOCKET0);
 
 This type of configuration could be useful in a pipeline model, for example,
 where one may want to have inter-core communication using pseudo Ethernet devices rather than raw rings,
diff --git a/doc/guides/nics/vhost.rst b/doc/guides/nics/vhost.rst
index 1e3f1ad..6b30b54 100644
--- a/doc/guides/nics/vhost.rst
+++ b/doc/guides/nics/vhost.rst
@@ -92,7 +92,7 @@ This section demonstrates vhost PMD with testpmd DPDK sample application.
 
     .. code-block:: console
 
-        ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0,queues=1' -- -i
+        ./testpmd -c f -n 4 --vdev 'net_vhost0,iface=/tmp/sock0,queues=1' -- -i
 
     Other basic DPDK preparations like hugepage enabling here.
     Please refer to the *DPDK Getting Started Guide* for detailed instructions.
diff --git a/doc/guides/xen/pkt_switch.rst b/doc/guides/xen/pkt_switch.rst
index 00a8f0c..a45841b 100644
--- a/doc/guides/xen/pkt_switch.rst
+++ b/doc/guides/xen/pkt_switch.rst
@@ -409,7 +409,7 @@ Building and Running the Front End
 
     .. code-block:: console
 
-        ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 --vdev="eth_xenvirt0,mac=00:00:00:00:00:11"
+        ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 --vdev="net_xenvirt0,mac=00:00:00:00:00:11"
         testpmd>set fwd mac
         testpmd>start
 
@@ -417,7 +417,7 @@ Building and Running the Front End
 
     .. code-block:: console
 
-        --vdev="eth_xenvirt0,mac=00:00:00:00:00:11" --vdev="eth_xenvirt1;mac=00:00:00:00:00:22"
+        --vdev="net_xenvirt0,mac=00:00:00:00:00:11" --vdev="net_xenvirt1;mac=00:00:00:00:00:22"
 
 
 Usage Examples: Injecting a Packet Stream Using a Packet Generator
@@ -430,7 +430,7 @@ Run TestPMD in a guest VM:
 
 .. code-block:: console
 
-    ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 --vdev="eth_xenvirt0,mac=00:00:00:00:00:11" -- -i --eth-peer=0,00:00:00:00:00:22
+    ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 --vdev="net_xenvirt0,mac=00:00:00:00:00:11" -- -i --eth-peer=0,00:00:00:00:00:22
     testpmd> set fwd mac
     testpmd> start
 
@@ -453,13 +453,13 @@ Run TestPMD in guest VM1:
 
 .. code-block:: console
 
-    ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 --vdev="eth_xenvirt0,mac=00:00:00:00:00:11" -- -i --eth-peer=0,00:00:00:00:00:22 -- -i
+    ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 --vdev="net_xenvirt0,mac=00:00:00:00:00:11" -- -i --eth-peer=0,00:00:00:00:00:22 -- -i
 
 Run TestPMD in guest VM2:
 
 .. code-block:: console
 
-    ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 --vdev="eth_xenvirt0,mac=00:00:00:00:00:22" -- -i --eth-peer=0,00:00:00:00:00:33
+    ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 --vdev="net_xenvirt0,mac=00:00:00:00:00:22" -- -i --eth-peer=0,00:00:00:00:00:33
 
 Configure a packet stream in the packet generator, and set the destination MAC address to 00:00:00:00:00:11 and VLAN to 1000.
 The packets received in Virtio in guest VM1 will be forwarded to Virtio in guest VM2 and
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c b/drivers/net/af_packet/rte_eth_af_packet.c
index f795566..efc5db6 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -895,8 +895,8 @@ static struct rte_driver pmd_af_packet_drv = {
 	.uninit = rte_pmd_af_packet_devuninit,
 };
 
-PMD_REGISTER_DRIVER(pmd_af_packet_drv, eth_af_packet);
-DRIVER_REGISTER_PARAM_STRING(eth_af_packet,
+PMD_REGISTER_DRIVER(pmd_af_packet_drv, net_af_packet);
+DRIVER_REGISTER_PARAM_STRING(net_af_packet,
 	"iface=<string> "
 	"qpairs=<int> "
 	"blocksz=<int> "
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index f3ab355..dcd2d77 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -665,7 +665,7 @@ static struct rte_driver rte_bnx2xvf_driver = {
 	.init = rte_bnx2xvf_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(rte_bnx2x_driver, bnx2x);
-DRIVER_REGISTER_PCI_TABLE(bnx2x, pci_id_bnx2x_map);
-PMD_REGISTER_DRIVER(rte_bnx2xvf_driver, bnx2xvf);
-DRIVER_REGISTER_PCI_TABLE(bnx2xvf, pci_id_bnx2xvf_map);
+PMD_REGISTER_DRIVER(rte_bnx2x_driver, net_bnx2x);
+DRIVER_REGISTER_PCI_TABLE(net_bnx2x, pci_id_bnx2x_map);
+PMD_REGISTER_DRIVER(rte_bnx2xvf_driver, net_bnx2xvf);
+DRIVER_REGISTER_PCI_TABLE(net_bnx2xvf, pci_id_bnx2xvf_map);
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 3795fac..f4eedfd 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1066,5 +1066,5 @@ static struct rte_driver bnxt_pmd_drv = {
 	.init = bnxt_rte_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(bnxt_pmd_drv, bnxt);
-DRIVER_REGISTER_PCI_TABLE(bnxt, bnxt_pci_id_map);
+PMD_REGISTER_DRIVER(bnxt_pmd_drv, net_bnxt);
+DRIVER_REGISTER_PCI_TABLE(net_bnxt, bnxt_pci_id_map);
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c b/drivers/net/bonding/rte_eth_bond_pmd.c
index b20a272..09ce7bf 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -2514,9 +2514,9 @@ static struct rte_driver bond_drv = {
 	.uninit = bond_uninit,
 };
 
-PMD_REGISTER_DRIVER(bond_drv, eth_bond);
+PMD_REGISTER_DRIVER(bond_drv, net_bonding);
 
-DRIVER_REGISTER_PARAM_STRING(eth_bond,
+DRIVER_REGISTER_PARAM_STRING(net_bonding,
 	"slave=<ifc> "
 	"primary=<ifc> "
 	"mode=[0-6] "
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 9208a61..7b7bfdf 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -1066,6 +1066,6 @@ static struct rte_driver rte_cxgbe_driver = {
 	.init = rte_cxgbe_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(rte_cxgbe_driver, cxgb4);
-DRIVER_REGISTER_PCI_TABLE(cxgb4, cxgb4_pci_tbl);
+PMD_REGISTER_DRIVER(rte_cxgbe_driver, net_cxgbe);
+DRIVER_REGISTER_PCI_TABLE(net_cxgbe, cxgb4_pci_tbl);
 
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index ad104ed..c5bf294 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -1804,5 +1804,5 @@ struct rte_driver em_pmd_drv = {
 	.init = rte_em_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(em_pmd_drv, em);
-DRIVER_REGISTER_PCI_TABLE(em, pci_id_em_map);
+PMD_REGISTER_DRIVER(em_pmd_drv, net_e1000_em);
+DRIVER_REGISTER_PCI_TABLE(net_e1000_em, pci_id_em_map);
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index fbf4d09..bed4765 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -5220,7 +5220,7 @@ eth_igb_configure_msix_intr(struct rte_eth_dev *dev)
 	E1000_WRITE_FLUSH(hw);
 }
 
-PMD_REGISTER_DRIVER(pmd_igb_drv, igb);
-DRIVER_REGISTER_PCI_TABLE(igb, pci_id_igb_map);
-PMD_REGISTER_DRIVER(pmd_igbvf_drv, igbvf);
-DRIVER_REGISTER_PCI_TABLE(igbvf, pci_id_igbvf_map);
+PMD_REGISTER_DRIVER(pmd_igb_drv, net_e1000_igb);
+DRIVER_REGISTER_PCI_TABLE(net_e1000_igb, pci_id_igb_map);
+PMD_REGISTER_DRIVER(pmd_igbvf_drv, net_e1000_igb_vf);
+DRIVER_REGISTER_PCI_TABLE(net_e1000_igb_vf, pci_id_igbvf_map);
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index ac0803d..d106f5f 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -1707,5 +1707,5 @@ struct rte_driver ena_pmd_drv = {
 	.init = rte_ena_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(ena_pmd_drv, ena);
-DRIVER_REGISTER_PCI_TABLE(ena, pci_id_ena_map);
+PMD_REGISTER_DRIVER(ena_pmd_drv, net_ena);
+DRIVER_REGISTER_PCI_TABLE(net_ena, pci_id_ena_map);
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 47b07c9..6cbecb1 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -640,5 +640,5 @@ static struct rte_driver rte_enic_driver = {
 	.init = rte_enic_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(rte_enic_driver, enic);
-DRIVER_REGISTER_PCI_TABLE(enic, pci_id_enic_map);
+PMD_REGISTER_DRIVER(rte_enic_driver, net_enic);
+DRIVER_REGISTER_PCI_TABLE(net_enic, pci_id_enic_map);
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 01f4a72..0ecc167 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -3084,5 +3084,5 @@ static struct rte_driver rte_fm10k_driver = {
 	.init = rte_pmd_fm10k_init,
 };
 
-PMD_REGISTER_DRIVER(rte_fm10k_driver, fm10k);
-DRIVER_REGISTER_PCI_TABLE(fm10k, pci_id_fm10k_map);
+PMD_REGISTER_DRIVER(rte_fm10k_driver, net_fm10k);
+DRIVER_REGISTER_PCI_TABLE(net_fm10k, pci_id_fm10k_map);
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index d0aeb70..b04c833 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -721,8 +721,8 @@ static struct rte_driver rte_i40e_driver = {
 	.init = rte_i40e_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(rte_i40e_driver, i40e);
-DRIVER_REGISTER_PCI_TABLE(i40e, pci_id_i40e_map);
+PMD_REGISTER_DRIVER(rte_i40e_driver, net_i40e);
+DRIVER_REGISTER_PCI_TABLE(net_i40e, pci_id_i40e_map);
 
 /*
  * 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..2e1c64a 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1584,8 +1584,8 @@ static struct rte_driver rte_i40evf_driver = {
 	.init = rte_i40evf_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(rte_i40evf_driver, i40evf);
-DRIVER_REGISTER_PCI_TABLE(i40evf, pci_id_i40evf_map);
+PMD_REGISTER_DRIVER(rte_i40evf_driver, net_i40e_vf);
+DRIVER_REGISTER_PCI_TABLE(net_i40e_vf, pci_id_i40evf_map);
 
 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 d478a15..95fd5ec 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -7362,7 +7362,7 @@ static struct rte_driver rte_ixgbevf_driver = {
 	.init = rte_ixgbevf_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(rte_ixgbe_driver, ixgbe);
-DRIVER_REGISTER_PCI_TABLE(ixgbe, pci_id_ixgbe_map);
-PMD_REGISTER_DRIVER(rte_ixgbevf_driver, ixgbevf);
-DRIVER_REGISTER_PCI_TABLE(ixgbevf, pci_id_ixgbevf_map);
+PMD_REGISTER_DRIVER(rte_ixgbe_driver, net_ixgbe);
+DRIVER_REGISTER_PCI_TABLE(net_ixgbe, pci_id_ixgbe_map);
+PMD_REGISTER_DRIVER(rte_ixgbevf_driver, net_ixgbe_vf);
+DRIVER_REGISTER_PCI_TABLE(net_ixgbe_vf, pci_id_ixgbevf_map);
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 304c846..efe60cf 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -5946,5 +5946,5 @@ static struct rte_driver rte_mlx4_driver = {
 	.init = rte_mlx4_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(rte_mlx4_driver, mlx4);
-DRIVER_REGISTER_PCI_TABLE(mlx4, mlx4_pci_id_map);
+PMD_REGISTER_DRIVER(rte_mlx4_driver, net_mlx4);
+DRIVER_REGISTER_PCI_TABLE(net_mlx4, mlx4_pci_id_map);
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index d96a9af..7264968 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -761,5 +761,5 @@ static struct rte_driver rte_mlx5_driver = {
 	.init = rte_mlx5_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(rte_mlx5_driver, mlx5);
-DRIVER_REGISTER_PCI_TABLE(mlx5, mlx5_pci_id_map);
+PMD_REGISTER_DRIVER(rte_mlx5_driver, net_mlx5);
+DRIVER_REGISTER_PCI_TABLE(net_mlx5, mlx5_pci_id_map);
diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index 93f8730..6fe1c55 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -1633,8 +1633,8 @@ static struct rte_driver pmd_mpipe_gbe_drv = {
 	.init = rte_pmd_mpipe_devinit,
 };
 
-PMD_REGISTER_DRIVER(pmd_mpipe_xgbe_drv, xgbe);
-PMD_REGISTER_DRIVER(pmd_mpipe_gbe_drv, gbe);
+PMD_REGISTER_DRIVER(pmd_mpipe_xgbe_drv, net_mpipe_xgbe);
+PMD_REGISTER_DRIVER(pmd_mpipe_gbe_drv, net_mpipe_gbe);
 
 static void __attribute__((constructor, used))
 mpipe_init_contexts(void)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 82e3e4e..19a5f86 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -2486,8 +2486,8 @@ static struct rte_driver rte_nfp_net_driver = {
 	.init = nfp_net_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(rte_nfp_net_driver, nfp);
-DRIVER_REGISTER_PCI_TABLE(nfp, pci_id_nfp_net_map);
+PMD_REGISTER_DRIVER(rte_nfp_net_driver, net_nfp);
+DRIVER_REGISTER_PCI_TABLE(net_nfp, pci_id_nfp_net_map);
 
 /*
  * Local variables:
diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 7a24884..29e5954 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -692,7 +692,7 @@ static struct rte_driver pmd_null_drv = {
 	.uninit = rte_pmd_null_devuninit,
 };
 
-PMD_REGISTER_DRIVER(pmd_null_drv, eth_null);
-DRIVER_REGISTER_PARAM_STRING(eth_null,
+PMD_REGISTER_DRIVER(pmd_null_drv, net_null);
+DRIVER_REGISTER_PARAM_STRING(net_null,
 	"size=<int> "
 	"copy=<int>");
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index 7e213eb..b7a3b03 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -1089,8 +1089,8 @@ static struct rte_driver pmd_pcap_drv = {
 	.uninit = rte_pmd_pcap_devuninit,
 };
 
-PMD_REGISTER_DRIVER(pmd_pcap_drv, eth_pcap);
-DRIVER_REGISTER_PARAM_STRING(eth_pcap,
+PMD_REGISTER_DRIVER(pmd_pcap_drv, net_pcap);
+DRIVER_REGISTER_PARAM_STRING(net_pcap,
 	"rx_pcap=<string> "
 	"tx_pcap=<string> "
 	"rx_iface=<ifc> "
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 82e44b8..3b2d8ea 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -1528,7 +1528,7 @@ static struct rte_driver rte_qede_driver = {
 	.init = rte_qedevf_pmd_init
 };
 
-PMD_REGISTER_DRIVER(rte_qede_driver, qede);
-DRIVER_REGISTER_PCI_TABLE(qede, pci_id_qede_map);
-PMD_REGISTER_DRIVER(rte_qedevf_driver, qedevf);
-DRIVER_REGISTER_PCI_TABLE(qedevf, pci_id_qedevf_map);
+PMD_REGISTER_DRIVER(rte_qede_driver, net_qede);
+DRIVER_REGISTER_PCI_TABLE(net_qede, pci_id_qede_map);
+PMD_REGISTER_DRIVER(rte_qedevf_driver, net_qede_vf);
+DRIVER_REGISTER_PCI_TABLE(net_qede_vf, pci_id_qedevf_map);
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index a7048c7..5d2580a 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -629,6 +629,6 @@ static struct rte_driver pmd_ring_drv = {
 	.uninit = rte_pmd_ring_devuninit,
 };
 
-PMD_REGISTER_DRIVER(pmd_ring_drv, eth_ring);
-DRIVER_REGISTER_PARAM_STRING(eth_ring,
+PMD_REGISTER_DRIVER(pmd_ring_drv, net_ring);
+DRIVER_REGISTER_PARAM_STRING(net_ring,
 	"nodeaction=[attach|detach]");
diff --git a/drivers/net/szedata2/rte_eth_szedata2.c b/drivers/net/szedata2/rte_eth_szedata2.c
index 483d789..f665248 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -62,7 +62,7 @@
  */
 #define RTE_SZE2_PACKET_HEADER_SIZE_ALIGNED 8
 
-#define RTE_SZEDATA2_DRIVER_NAME rte_szedata2_pmd
+#define RTE_SZEDATA2_DRIVER_NAME net_szedata2
 #define RTE_SZEDATA2_PCI_DRIVER_NAME "rte_szedata2_pmd"
 
 #define SZEDATA2_DEV_PATH_FMT "/dev/szedataII%u"
diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c
index 4f875c0..637794c 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -1783,5 +1783,5 @@ static struct rte_driver rte_nicvf_driver = {
 	.init = rte_nicvf_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(rte_nicvf_driver, thunderx_nicvf);
-DRIVER_REGISTER_PCI_TABLE(thunderx_nicvf, pci_id_nicvf_map);
+PMD_REGISTER_DRIVER(rte_nicvf_driver, net_thunderx);
+DRIVER_REGISTER_PCI_TABLE(net_thunderx, pci_id_nicvf_map);
diff --git a/drivers/net/vhost/rte_eth_vhost.c b/drivers/net/vhost/rte_eth_vhost.c
index 7539cd4..80c3f4c 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -930,7 +930,7 @@ static struct rte_driver pmd_vhost_drv = {
 	.uninit = rte_pmd_vhost_devuninit,
 };
 
-PMD_REGISTER_DRIVER(pmd_vhost_drv, eth_vhost);
-DRIVER_REGISTER_PARAM_STRING(eth_vhost,
+PMD_REGISTER_DRIVER(pmd_vhost_drv, net_vhost);
+DRIVER_REGISTER_PARAM_STRING(net_vhost,
 	"iface=<ifc> "
 	"queues=<int>");
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 07d6449..ef0d6ee 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1568,5 +1568,5 @@ static struct rte_driver rte_virtio_driver = {
 	.init = rte_virtio_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(rte_virtio_driver, virtio_net);
-DRIVER_REGISTER_PCI_TABLE(virtio_net, pci_id_virtio_map);
+PMD_REGISTER_DRIVER(rte_virtio_driver, net_virtio);
+DRIVER_REGISTER_PCI_TABLE(net_virtio, pci_id_virtio_map);
diff --git a/drivers/net/virtio/virtio_user_ethdev.c b/drivers/net/virtio/virtio_user_ethdev.c
index daef09b..8077f2e 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -467,8 +467,8 @@ static struct rte_driver virtio_user_driver = {
 	.uninit = virtio_user_pmd_devuninit,
 };
 
-PMD_REGISTER_DRIVER(virtio_user_driver, virtio_user);
-DRIVER_REGISTER_PARAM_STRING(virtio_user,
+PMD_REGISTER_DRIVER(virtio_user_driver, net_virtio_user);
+DRIVER_REGISTER_PARAM_STRING(net_virtio_user,
 	"path=<path> "
 	"mac=<mac addr> "
 	"cq=<int> "
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 5874215..e6873aa 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -953,5 +953,5 @@ static struct rte_driver rte_vmxnet3_driver = {
 	.init = rte_vmxnet3_pmd_init,
 };
 
-PMD_REGISTER_DRIVER(rte_vmxnet3_driver, vmxnet3);
-DRIVER_REGISTER_PCI_TABLE(vmxnet3, pci_id_vmxnet3_map);
+PMD_REGISTER_DRIVER(rte_vmxnet3_driver, net_vmxnet3);
+DRIVER_REGISTER_PCI_TABLE(net_vmxnet3, pci_id_vmxnet3_map);
diff --git a/drivers/net/xenvirt/rte_eth_xenvirt.c b/drivers/net/xenvirt/rte_eth_xenvirt.c
index 99f6cc8..8cb26ce 100644
--- a/drivers/net/xenvirt/rte_eth_xenvirt.c
+++ b/drivers/net/xenvirt/rte_eth_xenvirt.c
@@ -765,6 +765,6 @@ static struct rte_driver pmd_xenvirt_drv = {
 	.uninit = rte_pmd_xenvirt_devuninit,
 };
 
-PMD_REGISTER_DRIVER(pmd_xenvirt_drv, eth_xenvirt);
-DRIVER_REGISTER_PARAM_STRING(eth_xenvirt,
+PMD_REGISTER_DRIVER(pmd_xenvirt_drv, net_xenvirt);
+DRIVER_REGISTER_PARAM_STRING(net_xenvirt,
 	"mac=<mac addr>");
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index affbdec..9bb25d9 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -49,17 +49,17 @@ extern "C" {
 #include "rte_crypto.h"
 #include "rte_dev.h"
 
-#define CRYPTODEV_NAME_NULL_PMD		cryptodev_null_pmd
+#define CRYPTODEV_NAME_NULL_PMD		crypto_null
 /**< Null crypto PMD device name */
-#define CRYPTODEV_NAME_AESNI_MB_PMD	cryptodev_aesni_mb_pmd
+#define CRYPTODEV_NAME_AESNI_MB_PMD	crypto_aesni_mb
 /**< AES-NI Multi buffer PMD device name */
-#define CRYPTODEV_NAME_AESNI_GCM_PMD	cryptodev_aesni_gcm_pmd
+#define CRYPTODEV_NAME_AESNI_GCM_PMD	crypto_aesni_gcm
 /**< AES-NI GCM PMD device name */
-#define CRYPTODEV_NAME_QAT_SYM_PMD	cryptodev_qat_sym_pmd
+#define CRYPTODEV_NAME_QAT_SYM_PMD	crypto_qat
 /**< Intel QAT Symmetric Crypto PMD device name */
-#define CRYPTODEV_NAME_SNOW3G_PMD	cryptodev_snow3g_pmd
+#define CRYPTODEV_NAME_SNOW3G_PMD	crypto_snow3g
 /**< SNOW 3G PMD device name */
-#define CRYPTODEV_NAME_KASUMI_PMD	cryptodev_kasumi_pmd
+#define CRYPTODEV_NAME_KASUMI_PMD	crypto_kasumi
 /**< KASUMI PMD device name */
 
 /** Crypto device type */
-- 
2.7.4

Re: [dpdk-dev] [PATCH] drivers: make driver names consistent

[De Lara Guarch, Pablo]

> -----Original Message-----
> From: De Lara Guarch, Pablo
> Sent: Wednesday, August 24, 2016 3:25 PM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo
> Subject: [PATCH] drivers: make driver names consistent
> 
> As discussed in the past release, driver names are modified
> to be more consistent, and the future driver should follow
> this new convention.
> 
> Driver names consist of:
> "driver category"_"driver folder name"_"optional extra name".
> 
> For example:
> - Crypto null driver       -> "crypto_null"
> - Network IXGBE VF driver  -> "net_ixgbe_vf"
> 
> Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>

Some people asked to use "/" instead of "_", but there were compilation issues, so I had to use "_".

Re: [dpdk-dev] [PATCH] drivers: make driver names consistent

[Mcnamara, John]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, August 24, 2016 11:25 PM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: [dpdk-dev] [PATCH] drivers: make driver names consistent
>
> ...
>
> -    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'eth_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained
> +    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'net_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained


I know that this is an existing issue but there shouldn't be a space in
"/path/to/ file". Perhaps you could fix that (in a number of places) as part
of this patch. You could probably leave out the "/path/to/" part altogether as 
it may be clearer, see below.

Also, could you wrap the long code lines in the sections that you change at 
80 chars using "\" to keep them on the page in the PDF docs, like:

    $RTE_TARGET/app/testpmd -c '0xf' -n 4 \
        --vdev 'net_pcap0,rx_pcap=/path/to/file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' \
        -- --port-topology=chained

Or without the path part:

    $RTE_TARGET/app/testpmd -c '0xf' -n 4 \
        --vdev 'net_pcap0,rx_pcap=file_rx.pcap,tx_pcap=file_tx.pcap' \
        -- --port-topology=chained

John

Re: [dpdk-dev] [PATCH] drivers: make driver names consistent

[Thomas Monjalon]

2016-08-24 22:37, Mcnamara, John:
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pablo de Lara
> >
> > ...
> >
> > -    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'eth_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained
> > +    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'net_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained
> 
> 
> I know that this is an existing issue but there shouldn't be a space in
> "/path/to/ file". Perhaps you could fix that (in a number of places) as part
> of this patch. You could probably leave out the "/path/to/" part altogether as 
> it may be clearer, see below.
> 
> Also, could you wrap the long code lines in the sections that you change at 
> 80 chars using "\" to keep them on the page in the PDF docs, like:
> 
>     $RTE_TARGET/app/testpmd -c '0xf' -n 4 \
>         --vdev 'net_pcap0,rx_pcap=/path/to/file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' \
>         -- --port-topology=chained
> 
> Or without the path part:
> 
>     $RTE_TARGET/app/testpmd -c '0xf' -n 4 \
>         --vdev 'net_pcap0,rx_pcap=file_rx.pcap,tx_pcap=file_tx.pcap' \
>         -- --port-topology=chained

Applied with above comments fixed and release notes updated, thanks.

Re: [dpdk-dev] [PATCH] drivers: make driver names consistent

[Jan Blunck]

>From my understanding this is a massive API breakage. This forces all
existing users of the virtual PMDs to change with zero benefit. Even
if that isn't enough it also makes it impossible to switch between
releases by recompiling.

Can we please revert these changes and work on some aliasing support
for the PMDs to fix it long term?

Thanks,
Jan


On Fri, Sep 16, 2016 at 11:58 AM, Thomas Monjalon
<thomas.monjalon@6wind.com> wrote:
> 2016-08-24 22:37, Mcnamara, John:
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pablo de Lara
>> >
>> > ...
>> >
>> > -    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'eth_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained
>> > +    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'net_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained
>>
>>
>> I know that this is an existing issue but there shouldn't be a space in
>> "/path/to/ file". Perhaps you could fix that (in a number of places) as part
>> of this patch. You could probably leave out the "/path/to/" part altogether as
>> it may be clearer, see below.
>>
>> Also, could you wrap the long code lines in the sections that you change at
>> 80 chars using "\" to keep them on the page in the PDF docs, like:
>>
>>     $RTE_TARGET/app/testpmd -c '0xf' -n 4 \
>>         --vdev 'net_pcap0,rx_pcap=/path/to/file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' \
>>         -- --port-topology=chained
>>
>> Or without the path part:
>>
>>     $RTE_TARGET/app/testpmd -c '0xf' -n 4 \
>>         --vdev 'net_pcap0,rx_pcap=file_rx.pcap,tx_pcap=file_tx.pcap' \
>>         -- --port-topology=chained
>
> Applied with above comments fixed and release notes updated, thanks.

Re: [dpdk-dev] [PATCH] drivers: make driver names consistent

[Yuanhan Liu]

On Tue, Oct 18, 2016 at 02:50:16PM +0200, Jan Blunck wrote:
> >From my understanding this is a massive API breakage. This forces all
> existing users of the virtual PMDs to change with zero benefit. Even
> if that isn't enough it also makes it impossible to switch between
> releases by recompiling.
> 
> Can we please revert these changes and work on some aliasing support
> for the PMDs to fix it long term?

+1. Aliasing is also something I would suggest before making such renames.

	--yliu
> 
> Thanks,
> Jan
> 
> 
> On Fri, Sep 16, 2016 at 11:58 AM, Thomas Monjalon
> <thomas.monjalon@6wind.com> wrote:
> > 2016-08-24 22:37, Mcnamara, John:
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pablo de Lara
> >> >
> >> > ...
> >> >
> >> > -    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'eth_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained
> >> > +    $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'net_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- --port-topology=chained
> >>
> >>
> >> I know that this is an existing issue but there shouldn't be a space in
> >> "/path/to/ file". Perhaps you could fix that (in a number of places) as part
> >> of this patch. You could probably leave out the "/path/to/" part altogether as
> >> it may be clearer, see below.
> >>
> >> Also, could you wrap the long code lines in the sections that you change at
> >> 80 chars using "\" to keep them on the page in the PDF docs, like:
> >>
> >>     $RTE_TARGET/app/testpmd -c '0xf' -n 4 \
> >>         --vdev 'net_pcap0,rx_pcap=/path/to/file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' \
> >>         -- --port-topology=chained
> >>
> >> Or without the path part:
> >>
> >>     $RTE_TARGET/app/testpmd -c '0xf' -n 4 \
> >>         --vdev 'net_pcap0,rx_pcap=file_rx.pcap,tx_pcap=file_tx.pcap' \
> >>         -- --port-topology=chained
> >
> > Applied with above comments fixed and release notes updated, thanks.

Re: [dpdk-dev] [PATCH] drivers: make driver names consistent

[Thomas Monjalon]

2016-10-18 21:06, Yuanhan Liu:
> On Tue, Oct 18, 2016 at 02:50:16PM +0200, Jan Blunck wrote:
> > >From my understanding this is a massive API breakage. This forces all
> > existing users of the virtual PMDs to change with zero benefit. Even
> > if that isn't enough it also makes it impossible to switch between
> > releases by recompiling.
> > 
> > Can we please revert these changes and work on some aliasing support
> > for the PMDs to fix it long term?
> 
> +1. Aliasing is also something I would suggest before making such renames.

It is a brutal change, yes.
It was announced in 16.07 release notes though.

We can try to make this change more progressive by keeping old names
as aliases for some time.
Is there a volunteer to work on vdev names aliases,
with the target of integrating them in RC2 or RC3?

Re: [dpdk-dev] [PATCH] drivers: make driver names consistent

[Yuanhan Liu]

On Tue, Oct 18, 2016 at 03:42:54PM +0200, Thomas Monjalon wrote:
> 2016-10-18 21:06, Yuanhan Liu:
> > On Tue, Oct 18, 2016 at 02:50:16PM +0200, Jan Blunck wrote:
> > > >From my understanding this is a massive API breakage. This forces all
> > > existing users of the virtual PMDs to change with zero benefit. Even
> > > if that isn't enough it also makes it impossible to switch between
> > > releases by recompiling.
> > > 
> > > Can we please revert these changes and work on some aliasing support
> > > for the PMDs to fix it long term?
> > 
> > +1. Aliasing is also something I would suggest before making such renames.
> 
> It is a brutal change, yes.
> It was announced in 16.07 release notes though.

Yes, but it still took me a while (by running git bisect) to figure out
what went wrong: I wasn't aware of such note, that I was thinking maybe
something is broken.

Later I also got quite few same complains. It may also took them a while
to know what's happened.

Anyway, my point is, for this kind of change, we should have added the
alias support firstly. If that's been done, then the announcement is not
needed at all?

	--yliu
> 
> We can try to make this change more progressive by keeping old names
> as aliases for some time.
> Is there a volunteer to work on vdev names aliases,
> with the target of integrating them in RC2 or RC3?

Re: [dpdk-dev] [PATCH] drivers: make driver names consistent

[Jan Blunck]

On Tue, Oct 18, 2016 at 3:42 PM, Thomas Monjalon
<thomas.monjalon@6wind.com> wrote:
> 2016-10-18 21:06, Yuanhan Liu:
>> On Tue, Oct 18, 2016 at 02:50:16PM +0200, Jan Blunck wrote:
>> > >From my understanding this is a massive API breakage. This forces all
>> > existing users of the virtual PMDs to change with zero benefit. Even
>> > if that isn't enough it also makes it impossible to switch between
>> > releases by recompiling.
>> >
>> > Can we please revert these changes and work on some aliasing support
>> > for the PMDs to fix it long term?
>>
>> +1. Aliasing is also something I would suggest before making such renames.
>
> It is a brutal change, yes.
> It was announced in 16.07 release notes though.
>

"But the plans were on display ..." (HHGTTG)

> We can try to make this change more progressive by keeping old names
> as aliases for some time.
> Is there a volunteer to work on vdev names aliases,
> with the target of integrating them in RC2 or RC3?
>

I'll give it a try ...

Re: [dpdk-dev] [PATCH] drivers: make driver names consistent

[Thomas Monjalon]

2016-10-18 17:26, Jan Blunck:
> On Tue, Oct 18, 2016 at 3:42 PM, Thomas Monjalon
> <thomas.monjalon@6wind.com> wrote:
> > 2016-10-18 21:06, Yuanhan Liu:
> >> On Tue, Oct 18, 2016 at 02:50:16PM +0200, Jan Blunck wrote:
> >> > >From my understanding this is a massive API breakage. This forces all
> >> > existing users of the virtual PMDs to change with zero benefit. Even
> >> > if that isn't enough it also makes it impossible to switch between
> >> > releases by recompiling.
> >> >
> >> > Can we please revert these changes and work on some aliasing support
> >> > for the PMDs to fix it long term?
> >>
> >> +1. Aliasing is also something I would suggest before making such renames.
> >
> > It is a brutal change, yes.
> > It was announced in 16.07 release notes though.
> >
> 
> "But the plans were on display ..." (HHGTTG)
> 
> > We can try to make this change more progressive by keeping old names
> > as aliases for some time.
> > Is there a volunteer to work on vdev names aliases,
> > with the target of integrating them in RC2 or RC3?
> >
> 
> I'll give it a try ...

Thanks Jan

Re: [dpdk-dev] [PATCH] drivers: make driver names consistent

[Thomas Monjalon]

2016-10-18 22:18, Yuanhan Liu:
> On Tue, Oct 18, 2016 at 03:42:54PM +0200, Thomas Monjalon wrote:
> > 2016-10-18 21:06, Yuanhan Liu:
> > > On Tue, Oct 18, 2016 at 02:50:16PM +0200, Jan Blunck wrote:
> > > > >From my understanding this is a massive API breakage. This forces all
> > > > existing users of the virtual PMDs to change with zero benefit. Even
> > > > if that isn't enough it also makes it impossible to switch between
> > > > releases by recompiling.
> > > > 
> > > > Can we please revert these changes and work on some aliasing support
> > > > for the PMDs to fix it long term?
> > > 
> > > +1. Aliasing is also something I would suggest before making such renames.
> > 
> > It is a brutal change, yes.
> > It was announced in 16.07 release notes though.
> 
> Yes, but it still took me a while (by running git bisect) to figure out
> what went wrong: I wasn't aware of such note, that I was thinking maybe
> something is broken.
> 
> Later I also got quite few same complains. It may also took them a while
> to know what's happened.
> 
> Anyway, my point is, for this kind of change, we should have added the
> alias support firstly.

Yes.

> If that's been done, then the announcement is not
> needed at all?

The announcement would be needed to remove the aliases, later.


> > We can try to make this change more progressive by keeping old names
> > as aliases for some time.
> > Is there a volunteer to work on vdev names aliases,
> > with the target of integrating them in RC2 or RC3?

Re: [dpdk-dev] [PATCH] drivers: make driver names consistent

[Yuanhan Liu]

On Tue, Oct 18, 2016 at 06:46:40PM +0200, Thomas Monjalon wrote:
> 2016-10-18 22:18, Yuanhan Liu:
> > On Tue, Oct 18, 2016 at 03:42:54PM +0200, Thomas Monjalon wrote:
> > > 2016-10-18 21:06, Yuanhan Liu:
> > > > On Tue, Oct 18, 2016 at 02:50:16PM +0200, Jan Blunck wrote:
> > > > > >From my understanding this is a massive API breakage. This forces all
> > > > > existing users of the virtual PMDs to change with zero benefit. Even
> > > > > if that isn't enough it also makes it impossible to switch between
> > > > > releases by recompiling.
> > > > > 
> > > > > Can we please revert these changes and work on some aliasing support
> > > > > for the PMDs to fix it long term?
> > > > 
> > > > +1. Aliasing is also something I would suggest before making such renames.
> > > 
> > > It is a brutal change, yes.
> > > It was announced in 16.07 release notes though.
> > 
> > Yes, but it still took me a while (by running git bisect) to figure out
> > what went wrong: I wasn't aware of such note, that I was thinking maybe
> > something is broken.
> > 
> > Later I also got quite few same complains. It may also took them a while
> > to know what's happened.
> > 
> > Anyway, my point is, for this kind of change, we should have added the
> > alias support firstly.
> 
> Yes.
> 
> > If that's been done, then the announcement is not
> > needed at all?
> 
> The announcement would be needed to remove the aliases, later.
 
Why do you have to remove an aliase? What's wrong if they stay there
forever. I think the naming will be switched (maybe slowly) when we
haved updated the doc (whereas it states "net_vhost" but not "eth_vhost"
only).

After few releases, the name should have been switched fluently. And
we should not care about those alias.

	--yliu

Re: [dpdk-dev] [PATCH] drivers: make driver names consistent

[Thomas Monjalon]

2016-10-19 18:05, Yuanhan Liu:
> On Tue, Oct 18, 2016 at 06:46:40PM +0200, Thomas Monjalon wrote:
> > 2016-10-18 22:18, Yuanhan Liu:
> > > On Tue, Oct 18, 2016 at 03:42:54PM +0200, Thomas Monjalon wrote:
> > > > 2016-10-18 21:06, Yuanhan Liu:
> > > > > On Tue, Oct 18, 2016 at 02:50:16PM +0200, Jan Blunck wrote:
> > > > > > >From my understanding this is a massive API breakage. This forces all
> > > > > > existing users of the virtual PMDs to change with zero benefit. Even
> > > > > > if that isn't enough it also makes it impossible to switch between
> > > > > > releases by recompiling.
> > > > > > 
> > > > > > Can we please revert these changes and work on some aliasing support
> > > > > > for the PMDs to fix it long term?
> > > > > 
> > > > > +1. Aliasing is also something I would suggest before making such renames.
> > > > 
> > > > It is a brutal change, yes.
> > > > It was announced in 16.07 release notes though.
> > > 
> > > Yes, but it still took me a while (by running git bisect) to figure out
> > > what went wrong: I wasn't aware of such note, that I was thinking maybe
> > > something is broken.
> > > 
> > > Later I also got quite few same complains. It may also took them a while
> > > to know what's happened.
> > > 
> > > Anyway, my point is, for this kind of change, we should have added the
> > > alias support firstly.
> > 
> > Yes.
> > 
> > > If that's been done, then the announcement is not
> > > needed at all?
> > 
> > The announcement would be needed to remove the aliases, later.
>  
> Why do you have to remove an aliase? What's wrong if they stay there
> forever. I think the naming will be switched (maybe slowly) when we
> haved updated the doc (whereas it states "net_vhost" but not "eth_vhost"
> only).
> 
> After few releases, the name should have been switched fluently. And
> we should not care about those alias.

Yes
I was just thinking removing dead code later.
And it's generally simpler to end with only one way of doing things.

Re: [dpdk-dev] [PATCH] drivers: make driver names consistent

[Bruce Richardson]

On Tue, Oct 18, 2016 at 05:26:22PM +0200, Jan Blunck wrote:
> On Tue, Oct 18, 2016 at 3:42 PM, Thomas Monjalon
> <thomas.monjalon@6wind.com> wrote:
> > 2016-10-18 21:06, Yuanhan Liu:
> >> On Tue, Oct 18, 2016 at 02:50:16PM +0200, Jan Blunck wrote:
> >> > >From my understanding this is a massive API breakage. This forces all
> >> > existing users of the virtual PMDs to change with zero benefit. Even
> >> > if that isn't enough it also makes it impossible to switch between
> >> > releases by recompiling.
> >> >
> >> > Can we please revert these changes and work on some aliasing support
> >> > for the PMDs to fix it long term?
> >>
> >> +1. Aliasing is also something I would suggest before making such renames.
> >
> > It is a brutal change, yes.
> > It was announced in 16.07 release notes though.
> >
> 
> "But the plans were on display ..." (HHGTTG)
> 
Yes, 16.07, better known as the "Beware of the leopard" release of DPDK.
:-)

/Bruce