* [dpdk-dev] [PATCH v6] ethdev: add max LRO packet size
2019-11-05 8:40 3% ` [dpdk-dev] [PATCH 1/3] ethdev: " Dekel Peled
@ 2019-11-08 23:07 4% ` Thomas Monjalon
2 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-11-08 23:07 UTC (permalink / raw)
To: John McNamara, Marko Kovacevic, Neil Horman, Ajit Khaparde,
Somnath Kotur, Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou,
Wenzhuo Lu, Konstantin Ananyev, Matan Azrad, Shahaf Shuler,
Viacheslav Ovsiienko, Rasesh Mody, Shahed Shaikh,
Maxime Coquelin, Tiwei Bie, Zhihong Wang, Yong Wang,
Ferruh Yigit, Andrew Rybchenko
Cc: dev, Dekel Peled
From: Dekel Peled <dekelp@mellanox.com>
The maximum supported aggregated packet size for LRO
is advertised in rte_eth_dev_info.
For some devices, max_lro_pktlen may be different of
the basic max_rx_pktlen property.
Various PMDs supporting LRO are updated.
Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
v6: This is half of v5 1/3. Only the agreed part is here.
Hope it represents the consensus, so we make a step forward.
The field max_lro_pkt_size is renamed to max_lro_pktlen
in order to look like max_rx_pktlen.
---
doc/guides/nics/features.rst | 1 +
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_19_11.rst | 3 +++
drivers/net/bnxt/bnxt_ethdev.c | 1 +
drivers/net/hinic/hinic_pmd_ethdev.c | 1 +
drivers/net/ixgbe/ixgbe_ethdev.c | 1 +
drivers/net/mlx5/mlx5.h | 3 +++
drivers/net/mlx5/mlx5_ethdev.c | 1 +
drivers/net/mlx5/mlx5_rxq.c | 1 -
drivers/net/qede/qede_ethdev.c | 1 +
drivers/net/virtio/virtio_ethdev.c | 1 +
drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 +
lib/librte_ethdev/rte_ethdev.h | 1 +
13 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index d96696801a..1b2e120a9d 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -197,6 +197,7 @@ Supports Large Receive Offload.
* **[implements] rte_eth_dev_data**: ``lro``.
* **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``.
* **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``.
+* **[provides] rte_eth_dev_info**: ``max_lro_pktlen``.
.. _nic_features_tso:
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b0b992dcb5..d4fcf9975b 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -88,10 +88,6 @@ Deprecation Notices
This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and
thereby improve Rx performance if application wishes do so.
-* ethdev: New 32-bit fields may be added for maximum LRO session size, in
- struct ``rte_eth_dev_info`` for the port capability and in struct
- ``rte_eth_rxmode`` for the port configuration.
-
* cryptodev: support for using IV with all sizes is added, J0 still can
be used but only when IV length in following structs ``rte_crypto_auth_xform``,
``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index 795c7601c0..473af44374 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -403,6 +403,9 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
+* ethdev: Added 32-bit field for maximum LRO aggregated packet size,
+ as port capability in the struct ``rte_eth_dev_info``.
+
* security: The field ``replay_win_sz`` has been moved from ipsec library
based ``rte_ipsec_sa_prm`` structure to security library based structure
``rte_security_ipsec_xform``, which specify the Anti replay window size
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 58a4f98c9f..95c60a3757 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -535,6 +535,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,
/* Fast path specifics */
dev_info->min_rx_bufsize = 1;
dev_info->max_rx_pktlen = BNXT_MAX_PKT_LEN;
+ dev_info->max_lro_pktlen = BNXT_MAX_PKT_LEN;
dev_info->rx_offload_capa = BNXT_DEV_RX_OFFLOAD_SUPPORT;
if (bp->flags & BNXT_FLAG_PTP_SUPPORTED)
diff --git a/drivers/net/hinic/hinic_pmd_ethdev.c b/drivers/net/hinic/hinic_pmd_ethdev.c
index 9f37a404be..cbd2d032f9 100644
--- a/drivers/net/hinic/hinic_pmd_ethdev.c
+++ b/drivers/net/hinic/hinic_pmd_ethdev.c
@@ -727,6 +727,7 @@ hinic_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
info->max_tx_queues = nic_dev->nic_cap.max_sqs;
info->min_rx_bufsize = HINIC_MIN_RX_BUF_SIZE;
info->max_rx_pktlen = HINIC_MAX_JUMBO_FRAME_SIZE;
+ info->max_lro_pktlen = HINIC_MAX_JUMBO_FRAME_SIZE;
info->max_mac_addrs = HINIC_MAX_UC_MAC_ADDRS;
info->min_mtu = HINIC_MIN_MTU_SIZE;
info->max_mtu = HINIC_MAX_MTU_SIZE;
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index dbce7a80e9..a01b8bbf10 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3804,6 +3804,7 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
}
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL register */
dev_info->max_rx_pktlen = 15872; /* includes CRC, cf MAXFRS register */
+ dev_info->max_lro_pktlen = RTE_IPV4_MAX_PKT_LEN;
dev_info->max_mac_addrs = hw->mac.num_rar_entries;
dev_info->max_hash_mac_addrs = IXGBE_VMDQ_NUM_UC_MAC;
dev_info->max_vfs = pci_dev->max_vfs;
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index b6a51b2b4d..935adbbbf3 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -198,6 +198,9 @@ TAILQ_HEAD(mlx5_flows, rte_flow);
#define MLX5_LRO_SUPPORTED(dev) \
(((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported)
+/* Maximal size of aggregated LRO packet. */
+#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)
+
/* LRO configurations structure. */
struct mlx5_lro_config {
uint32_t supported:1; /* Whether LRO is supported. */
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 2278b24c01..91de186365 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -552,6 +552,7 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
/* FIXME: we should ask the device for these values. */
info->min_rx_bufsize = 32;
info->max_rx_pktlen = 65536;
+ info->max_lro_pktlen = MLX5_MAX_LRO_SIZE;
/*
* Since we need one CQ per QP, the limit is the minimum number
* between the two values.
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index f0ab8438d3..aca2e67e0c 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -1524,7 +1524,6 @@ mlx5_mprq_alloc_mp(struct rte_eth_dev *dev)
return 0;
}
-#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)
#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \
sizeof(struct rte_vlan_hdr) * 2 + \
sizeof(struct rte_ipv6_hdr)))
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 53fdfde9a8..fd05856836 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -1273,6 +1273,7 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
dev_info->min_rx_bufsize = (uint32_t)QEDE_MIN_RX_BUFF_SIZE;
dev_info->max_rx_pktlen = (uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
+ dev_info->max_lro_pktlen = (uint32_t)0x7FFF;
dev_info->rx_desc_lim = qede_rx_desc_lim;
dev_info->tx_desc_lim = qede_tx_desc_lim;
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 646de9945c..d97f3c6645 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -2435,6 +2435,7 @@ virtio_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
RTE_MIN(hw->max_queue_pairs, VIRTIO_MAX_TX_QUEUES);
dev_info->min_rx_bufsize = VIRTIO_MIN_RX_BUFSIZE;
dev_info->max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN;
+ dev_info->max_lro_pktlen = VIRTIO_MAX_RX_PKTLEN;
dev_info->max_mac_addrs = VIRTIO_MAX_MAC_ADDRS;
host_features = VTPCI_OPS(hw)->get_features(hw);
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index d1faeaa81b..6c99a2a8e0 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -1161,6 +1161,7 @@ vmxnet3_dev_info_get(struct rte_eth_dev *dev,
dev_info->max_tx_queues = VMXNET3_MAX_TX_QUEUES;
dev_info->min_rx_bufsize = 1518 + RTE_PKTMBUF_HEADROOM;
dev_info->max_rx_pktlen = 16384; /* includes CRC, cf MAXFRS register */
+ dev_info->max_lro_pktlen = 16384;
dev_info->speed_capa = ETH_LINK_SPEED_10G;
dev_info->max_mac_addrs = VMXNET3_MAX_MAC_ADDRS;
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index c36c1b631f..b47eea60d9 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1183,6 +1183,7 @@ struct rte_eth_dev_info {
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
+ uint32_t max_lro_pktlen; /**< Maximum size of LRO aggregated packet. */
uint16_t max_rx_queues; /**< Maximum number of RX queues. */
uint16_t max_tx_queues; /**< Maximum number of TX queues. */
uint32_t max_mac_addrs; /**< Maximum number of MAC addresses. */
--
2.23.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v7 09/10] build: change ABI version to 20.0
2019-11-06 16:54 8% ` [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
` (8 preceding siblings ...)
2019-11-08 16:25 3% ` [dpdk-dev] [PATCH v7 08/10] drivers/octeontx: add missing public symbol Anatoly Burakov
@ 2019-11-08 16:25 2% ` Anatoly Burakov
2019-11-08 16:25 23% ` [dpdk-dev] [PATCH v7 10/10] buildtools: add ABI versioning check script Anatoly Burakov
10 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-08 16:25 UTC (permalink / raw)
To: dev
Cc: Pawel Modrak, Nicolas Chautru, Hemant Agrawal, Sachin Saxena,
Rosen Xu, Stephen Hemminger, Anoob Joseph, Tomasz Duszynski,
Liron Himi, Jerin Jacob, Nithin Dabilpuram, Vamsi Attunuru,
Lee Daly, Fiona Trahe, Ashish Gupta, Sunila Sahu, Declan Doherty,
Pablo de Lara, Gagandeep Singh, Ravi Kumar, Akhil Goyal,
Michael Shamis, Nagadheeraj Rottela, Srikanth Jampala,
Ankur Dwivedi, Fan Zhang, Jay Zhou, Nipun Gupta,
Mattias Rönnblom, Pavan Nikhilesh, Liang Ma, Peter Mccarthy,
Harry van Haaren, Artem V. Andreev, Andrew Rybchenko,
Olivier Matz, Gage Eads, John W. Linville, Xiaolong Ye, Qi Zhang,
Shepard Siegel, Ed Czeck, John Miller, Igor Russkikh,
Pavel Belous, Allain Legacy, Matt Peters, Rasesh Mody,
Shahed Shaikh, Ajit Khaparde, Somnath Kotur, Chas Williams,
Rahul Lakkireddy, Wenzhuo Lu, Marcin Wojtas, Michal Krawczyk,
Guy Tzalik, Evgeny Schemeilin, Igor Chauskin, John Daley,
Hyong Youb Kim, Gaetan Rivet, Xiao Wang, Ziyang Xuan,
Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier), Min Hu (Connor),
Yisen Zhuang, Beilei Xing, Jingjing Wu, Qiming Yang,
Konstantin Ananyev, Ferruh Yigit, Shijith Thotton,
Srisivasubramanian Srinivasan, Jakub Grajciar, Matan Azrad,
Shahaf Shuler, Viacheslav Ovsiienko, Zyta Szpak,
K. Y. Srinivasan, Haiyang Zhang, Rastislav Cernay, Jan Remes,
Alejandro Lucero, Tetsuya Mukawa, Kiran Kumar K,
Bruce Richardson, Jasvinder Singh, Cristian Dumitrescu,
Keith Wiles, Maciej Czekaj, Maxime Coquelin, Tiwei Bie,
Zhihong Wang, Yong Wang, Tianfei zhang, Xiaoyun Li, Satha Rao,
Shreyansh Jain, David Hunt, Byron Marohn, Yipeng Wang,
Thomas Monjalon, Jiayu Hu, Sameh Gobriel, Reshma Pattan,
Vladimir Medvedkin, Robert Sanford, Erik Gabriel Carrillo,
john.mcnamara, ray.kinsella, david.marchand
From: Pawel Modrak <pawelx.modrak@intel.com>
Merge all vesions in linker version script files to DPDK_20.0.
This commit was generated by running the following command:
:~/DPDK$ buildtools/update-abi.sh 20.0
Signed-off-by: Pawel Modrak <pawelx.modrak@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
.../rte_pmd_bbdev_fpga_lte_fec_version.map | 8 +-
.../null/rte_pmd_bbdev_null_version.map | 2 +-
.../rte_pmd_bbdev_turbo_sw_version.map | 2 +-
drivers/bus/dpaa/rte_bus_dpaa_version.map | 113 +++---
drivers/bus/fslmc/rte_bus_fslmc_version.map | 154 ++++-----
drivers/bus/ifpga/rte_bus_ifpga_version.map | 14 +-
drivers/bus/pci/rte_bus_pci_version.map | 2 +-
drivers/bus/vdev/rte_bus_vdev_version.map | 12 +-
drivers/bus/vmbus/rte_bus_vmbus_version.map | 12 +-
drivers/common/cpt/rte_common_cpt_version.map | 9 +-
.../common/dpaax/rte_common_dpaax_version.map | 14 +-
.../common/mvep/rte_common_mvep_version.map | 6 +-
.../octeontx/rte_common_octeontx_version.map | 6 +-
.../rte_common_octeontx2_version.map | 16 +-
.../compress/isal/rte_pmd_isal_version.map | 2 +-
.../rte_pmd_octeontx_compress_version.map | 2 +-
drivers/compress/qat/rte_pmd_qat_version.map | 2 +-
.../compress/zlib/rte_pmd_zlib_version.map | 2 +-
.../aesni_gcm/rte_pmd_aesni_gcm_version.map | 2 +-
.../aesni_mb/rte_pmd_aesni_mb_version.map | 2 +-
.../crypto/armv8/rte_pmd_armv8_version.map | 2 +-
.../caam_jr/rte_pmd_caam_jr_version.map | 3 +-
drivers/crypto/ccp/rte_pmd_ccp_version.map | 3 +-
.../dpaa2_sec/rte_pmd_dpaa2_sec_version.map | 10 +-
.../dpaa_sec/rte_pmd_dpaa_sec_version.map | 10 +-
.../crypto/kasumi/rte_pmd_kasumi_version.map | 2 +-
.../crypto/mvsam/rte_pmd_mvsam_version.map | 2 +-
.../crypto/nitrox/rte_pmd_nitrox_version.map | 2 +-
.../null/rte_pmd_null_crypto_version.map | 2 +-
.../rte_pmd_octeontx_crypto_version.map | 3 +-
.../rte_pmd_octeontx2_crypto_version.map | 3 +-
.../openssl/rte_pmd_openssl_version.map | 2 +-
.../rte_pmd_crypto_scheduler_version.map | 19 +-
.../crypto/snow3g/rte_pmd_snow3g_version.map | 2 +-
.../virtio/rte_pmd_virtio_crypto_version.map | 2 +-
drivers/crypto/zuc/rte_pmd_zuc_version.map | 2 +-
.../event/dpaa/rte_pmd_dpaa_event_version.map | 3 +-
.../dpaa2/rte_pmd_dpaa2_event_version.map | 2 +-
.../event/dsw/rte_pmd_dsw_event_version.map | 2 +-
.../rte_pmd_octeontx_event_version.map | 2 +-
.../rte_pmd_octeontx2_event_version.map | 3 +-
.../event/opdl/rte_pmd_opdl_event_version.map | 2 +-
.../rte_pmd_skeleton_event_version.map | 3 +-
drivers/event/sw/rte_pmd_sw_event_version.map | 2 +-
.../bucket/rte_mempool_bucket_version.map | 3 +-
.../mempool/dpaa/rte_mempool_dpaa_version.map | 2 +-
.../dpaa2/rte_mempool_dpaa2_version.map | 12 +-
.../octeontx/rte_mempool_octeontx_version.map | 2 +-
.../rte_mempool_octeontx2_version.map | 4 +-
.../mempool/ring/rte_mempool_ring_version.map | 3 +-
.../stack/rte_mempool_stack_version.map | 3 +-
.../af_packet/rte_pmd_af_packet_version.map | 3 +-
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 2 +-
drivers/net/ark/rte_pmd_ark_version.map | 5 +-
.../net/atlantic/rte_pmd_atlantic_version.map | 4 +-
drivers/net/avp/rte_pmd_avp_version.map | 2 +-
drivers/net/axgbe/rte_pmd_axgbe_version.map | 2 +-
drivers/net/bnx2x/rte_pmd_bnx2x_version.map | 3 +-
drivers/net/bnxt/rte_pmd_bnxt_version.map | 4 +-
drivers/net/bonding/rte_pmd_bond_version.map | 47 +--
drivers/net/cxgbe/rte_pmd_cxgbe_version.map | 3 +-
drivers/net/dpaa/rte_pmd_dpaa_version.map | 11 +-
drivers/net/dpaa2/rte_pmd_dpaa2_version.map | 12 +-
drivers/net/e1000/rte_pmd_e1000_version.map | 3 +-
drivers/net/ena/rte_pmd_ena_version.map | 3 +-
drivers/net/enetc/rte_pmd_enetc_version.map | 3 +-
drivers/net/enic/rte_pmd_enic_version.map | 3 +-
.../net/failsafe/rte_pmd_failsafe_version.map | 3 +-
drivers/net/fm10k/rte_pmd_fm10k_version.map | 3 +-
drivers/net/hinic/rte_pmd_hinic_version.map | 3 +-
drivers/net/hns3/rte_pmd_hns3_version.map | 4 +-
drivers/net/i40e/rte_pmd_i40e_version.map | 65 +---
drivers/net/iavf/rte_pmd_iavf_version.map | 3 +-
drivers/net/ice/rte_pmd_ice_version.map | 3 +-
drivers/net/ifc/rte_pmd_ifc_version.map | 3 +-
drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map | 3 +-
drivers/net/ixgbe/rte_pmd_ixgbe_version.map | 62 ++--
drivers/net/kni/rte_pmd_kni_version.map | 3 +-
.../net/liquidio/rte_pmd_liquidio_version.map | 3 +-
drivers/net/memif/rte_pmd_memif_version.map | 5 +-
drivers/net/mlx4/rte_pmd_mlx4_version.map | 3 +-
drivers/net/mlx5/rte_pmd_mlx5_version.map | 2 +-
drivers/net/mvneta/rte_pmd_mvneta_version.map | 2 +-
drivers/net/mvpp2/rte_pmd_mvpp2_version.map | 2 +-
drivers/net/netvsc/rte_pmd_netvsc_version.map | 4 +-
drivers/net/nfb/rte_pmd_nfb_version.map | 3 +-
drivers/net/nfp/rte_pmd_nfp_version.map | 2 +-
drivers/net/null/rte_pmd_null_version.map | 3 +-
.../net/octeontx/rte_pmd_octeontx_version.map | 10 +-
.../octeontx2/rte_pmd_octeontx2_version.map | 3 +-
drivers/net/pcap/rte_pmd_pcap_version.map | 3 +-
drivers/net/pfe/rte_pmd_pfe_version.map | 3 +-
drivers/net/qede/rte_pmd_qede_version.map | 3 +-
drivers/net/ring/rte_pmd_ring_version.map | 10 +-
drivers/net/sfc/rte_pmd_sfc_version.map | 3 +-
.../net/softnic/rte_pmd_softnic_version.map | 2 +-
.../net/szedata2/rte_pmd_szedata2_version.map | 2 +-
drivers/net/tap/rte_pmd_tap_version.map | 3 +-
.../net/thunderx/rte_pmd_thunderx_version.map | 3 +-
.../rte_pmd_vdev_netvsc_version.map | 3 +-
drivers/net/vhost/rte_pmd_vhost_version.map | 11 +-
drivers/net/virtio/rte_pmd_virtio_version.map | 3 +-
.../net/vmxnet3/rte_pmd_vmxnet3_version.map | 3 +-
.../rte_rawdev_dpaa2_cmdif_version.map | 3 +-
.../rte_rawdev_dpaa2_qdma_version.map | 4 +-
.../raw/ifpga/rte_rawdev_ifpga_version.map | 3 +-
drivers/raw/ioat/rte_rawdev_ioat_version.map | 3 +-
drivers/raw/ntb/rte_rawdev_ntb_version.map | 5 +-
.../rte_rawdev_octeontx2_dma_version.map | 3 +-
.../skeleton/rte_rawdev_skeleton_version.map | 3 +-
lib/librte_acl/rte_acl_version.map | 2 +-
.../rte_bitratestats_version.map | 2 +-
lib/librte_cfgfile/rte_cfgfile_version.map | 34 +-
lib/librte_cmdline/rte_cmdline_version.map | 10 +-
.../rte_cryptodev_version.map | 102 ++----
.../rte_distributor_version.map | 4 +-
lib/librte_eal/rte_eal_version.map | 324 ++++++------------
lib/librte_efd/rte_efd_version.map | 2 +-
lib/librte_ethdev/rte_ethdev_version.map | 160 +++------
lib/librte_eventdev/rte_eventdev_version.map | 130 +++----
lib/librte_gro/rte_gro_version.map | 2 +-
lib/librte_gso/rte_gso_version.map | 2 +-
lib/librte_hash/rte_hash_version.map | 43 +--
lib/librte_ip_frag/rte_ip_frag_version.map | 10 +-
lib/librte_jobstats/rte_jobstats_version.map | 10 +-
lib/librte_kni/rte_kni_version.map | 2 +-
lib/librte_kvargs/rte_kvargs_version.map | 4 +-
.../rte_latencystats_version.map | 2 +-
lib/librte_lpm/rte_lpm_version.map | 39 +--
lib/librte_mbuf/rte_mbuf_version.map | 49 +--
lib/librte_member/rte_member_version.map | 2 +-
lib/librte_mempool/rte_mempool_version.map | 44 +--
lib/librte_meter/rte_meter_version.map | 13 +-
lib/librte_metrics/rte_metrics_version.map | 2 +-
lib/librte_net/rte_net_version.map | 23 +-
lib/librte_pci/rte_pci_version.map | 2 +-
lib/librte_pdump/rte_pdump_version.map | 2 +-
lib/librte_pipeline/rte_pipeline_version.map | 36 +-
lib/librte_port/rte_port_version.map | 64 +---
lib/librte_power/rte_power_version.map | 24 +-
lib/librte_rawdev/rte_rawdev_version.map | 4 +-
lib/librte_reorder/rte_reorder_version.map | 8 +-
lib/librte_ring/rte_ring_version.map | 10 +-
lib/librte_sched/rte_sched_version.map | 14 +-
lib/librte_security/rte_security_version.map | 2 +-
lib/librte_table/rte_table_version.map | 2 +-
lib/librte_timer/rte_timer_version.map | 12 +-
lib/librte_vhost/rte_vhost_version.map | 52 +--
148 files changed, 698 insertions(+), 1433 deletions(-)
diff --git a/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map b/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
index f64b0f9c27..6bcea2cc7f 100644
--- a/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
+++ b/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
@@ -1,10 +1,10 @@
-DPDK_19.08 {
- local: *;
+DPDK_20.0 {
+ local: *;
};
EXPERIMENTAL {
- global:
+ global:
- fpga_lte_fec_configure;
+ fpga_lte_fec_configure;
};
diff --git a/drivers/baseband/null/rte_pmd_bbdev_null_version.map b/drivers/baseband/null/rte_pmd_bbdev_null_version.map
index 58b94270d4..f9f17e4f6e 100644
--- a/drivers/baseband/null/rte_pmd_bbdev_null_version.map
+++ b/drivers/baseband/null/rte_pmd_bbdev_null_version.map
@@ -1,3 +1,3 @@
-DPDK_18.02 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/baseband/turbo_sw/rte_pmd_bbdev_turbo_sw_version.map b/drivers/baseband/turbo_sw/rte_pmd_bbdev_turbo_sw_version.map
index 58b94270d4..f9f17e4f6e 100644
--- a/drivers/baseband/turbo_sw/rte_pmd_bbdev_turbo_sw_version.map
+++ b/drivers/baseband/turbo_sw/rte_pmd_bbdev_turbo_sw_version.map
@@ -1,3 +1,3 @@
-DPDK_18.02 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/bus/dpaa/rte_bus_dpaa_version.map b/drivers/bus/dpaa/rte_bus_dpaa_version.map
index cf428a54dc..e6ca4361e0 100644
--- a/drivers/bus/dpaa/rte_bus_dpaa_version.map
+++ b/drivers/bus/dpaa/rte_bus_dpaa_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
bman_acquire;
@@ -7,123 +7,90 @@ DPDK_17.11 {
bman_new_pool;
bman_query_free_buffers;
bman_release;
+ bman_thread_irq;
+ dpaa_logtype_eventdev;
dpaa_logtype_mempool;
dpaa_logtype_pmd;
dpaa_netcfg;
+ dpaa_svr_family;
fman_ccsr_map_fd;
fman_dealloc_bufs_mask_hi;
fman_dealloc_bufs_mask_lo;
fman_if_add_mac_addr;
fman_if_clear_mac_addr;
fman_if_disable_rx;
- fman_if_enable_rx;
fman_if_discard_rx_errors;
- fman_if_get_fc_threshold;
+ fman_if_enable_rx;
fman_if_get_fc_quanta;
+ fman_if_get_fc_threshold;
fman_if_get_fdoff;
+ fman_if_get_sg_enable;
fman_if_loopback_disable;
fman_if_loopback_enable;
fman_if_promiscuous_disable;
fman_if_promiscuous_enable;
fman_if_reset_mcast_filter_table;
fman_if_set_bp;
- fman_if_set_fc_threshold;
fman_if_set_fc_quanta;
+ fman_if_set_fc_threshold;
fman_if_set_fdoff;
fman_if_set_ic_params;
fman_if_set_maxfrm;
fman_if_set_mcast_filter_table;
+ fman_if_set_sg;
fman_if_stats_get;
fman_if_stats_get_all;
fman_if_stats_reset;
fman_ip_rev;
+ fsl_qman_fq_portal_create;
netcfg_acquire;
netcfg_release;
- qm_channel_caam;
- qman_create_fq;
- qman_dequeue;
- qman_dqrr_consume;
- qman_enqueue;
- qman_enqueue_multi;
- qman_fq_fqid;
- qman_fq_state;
- qman_init_fq;
- qman_poll_dqrr;
- qman_query_fq_np;
- qman_set_vdq;
- qman_reserve_fqid_range;
- qman_volatile_dequeue;
- rte_dpaa_driver_register;
- rte_dpaa_driver_unregister;
- rte_dpaa_mem_ptov;
- rte_dpaa_portal_init;
-
- local: *;
-};
-
-DPDK_18.02 {
- global:
-
- dpaa_logtype_eventdev;
- dpaa_svr_family;
per_lcore_dpaa_io;
per_lcore_held_bufs;
+ qm_channel_caam;
qm_channel_pool1;
qman_alloc_cgrid_range;
qman_alloc_pool_range;
+ qman_clear_irq;
qman_create_cgr;
+ qman_create_fq;
qman_dca_index;
qman_delete_cgr;
+ qman_dequeue;
+ qman_dqrr_consume;
+ qman_enqueue;
+ qman_enqueue_multi;
qman_enqueue_multi_fq;
+ qman_fq_fqid;
+ qman_fq_portal_irqsource_add;
+ qman_fq_portal_irqsource_remove;
+ qman_fq_portal_thread_irq;
+ qman_fq_state;
+ qman_init_fq;
+ qman_irqsource_add;
+ qman_irqsource_remove;
qman_modify_cgr;
qman_oos_fq;
+ qman_poll_dqrr;
qman_portal_dequeue;
qman_portal_poll_rx;
qman_query_fq_frm_cnt;
+ qman_query_fq_np;
qman_release_cgrid_range;
+ qman_reserve_fqid_range;
qman_retire_fq;
+ qman_set_fq_lookup_table;
+ qman_set_vdq;
qman_static_dequeue_add;
- rte_dpaa_portal_fq_close;
- rte_dpaa_portal_fq_init;
-
-} DPDK_17.11;
-
-DPDK_18.08 {
- global:
-
- fman_if_get_sg_enable;
- fman_if_set_sg;
-
-} DPDK_18.02;
-
-DPDK_18.11 {
- global:
-
- bman_thread_irq;
- fman_if_get_sg_enable;
- fman_if_set_sg;
- qman_clear_irq;
-
- qman_irqsource_add;
- qman_irqsource_remove;
qman_thread_fd;
qman_thread_irq;
-
-} DPDK_18.08;
-
-DPDK_19.05 {
- global:
-
- qman_set_fq_lookup_table;
-
-} DPDK_18.11;
-
-DPDK_19.11 {
- global:
-
- fsl_qman_fq_portal_create;
- qman_fq_portal_irqsource_add;
- qman_fq_portal_irqsource_remove;
- qman_fq_portal_thread_irq;
-
-} DPDK_19.05;
+ qman_volatile_dequeue;
+ rte_dpaa_driver_register;
+ rte_dpaa_driver_unregister;
+ rte_dpaa_mem_ptov;
+ rte_dpaa_portal_fq_close;
+ rte_dpaa_portal_fq_init;
+ rte_dpaa_portal_init;
+
+ local: *;
+};
diff --git a/drivers/bus/fslmc/rte_bus_fslmc_version.map b/drivers/bus/fslmc/rte_bus_fslmc_version.map
index 4da787236b..fe45575046 100644
--- a/drivers/bus/fslmc/rte_bus_fslmc_version.map
+++ b/drivers/bus/fslmc/rte_bus_fslmc_version.map
@@ -1,32 +1,67 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
+ dpaa2_affine_qbman_ethrx_swp;
dpaa2_affine_qbman_swp;
dpaa2_alloc_dpbp_dev;
dpaa2_alloc_dq_storage;
+ dpaa2_dpbp_supported;
+ dpaa2_dqrr_size;
+ dpaa2_eqcr_size;
dpaa2_free_dpbp_dev;
dpaa2_free_dq_storage;
+ dpaa2_free_eq_descriptors;
+ dpaa2_get_qbman_swp;
+ dpaa2_io_portal;
+ dpaa2_svr_family;
+ dpaa2_virt_mode;
dpbp_disable;
dpbp_enable;
dpbp_get_attributes;
dpbp_get_num_free_bufs;
dpbp_open;
dpbp_reset;
+ dpci_get_opr;
+ dpci_set_opr;
+ dpci_set_rx_queue;
+ dpcon_get_attributes;
+ dpcon_open;
+ dpdmai_close;
+ dpdmai_disable;
+ dpdmai_enable;
+ dpdmai_get_attributes;
+ dpdmai_get_rx_queue;
+ dpdmai_get_tx_queue;
+ dpdmai_open;
+ dpdmai_set_rx_queue;
+ dpio_add_static_dequeue_channel;
dpio_close;
dpio_disable;
dpio_enable;
dpio_get_attributes;
dpio_open;
+ dpio_remove_static_dequeue_channel;
dpio_reset;
dpio_set_stashing_destination;
+ mc_get_soc_version;
+ mc_get_version;
mc_send_command;
per_lcore__dpaa2_io;
+ per_lcore_dpaa2_held_bufs;
qbman_check_command_complete;
+ qbman_check_new_result;
qbman_eq_desc_clear;
+ qbman_eq_desc_set_dca;
qbman_eq_desc_set_fq;
qbman_eq_desc_set_no_orp;
+ qbman_eq_desc_set_orp;
qbman_eq_desc_set_qd;
qbman_eq_desc_set_response;
+ qbman_eq_desc_set_token;
+ qbman_fq_query_state;
+ qbman_fq_state_frame_count;
+ qbman_get_dqrr_from_idx;
+ qbman_get_dqrr_idx;
qbman_pull_desc_clear;
qbman_pull_desc_set_fq;
qbman_pull_desc_set_numframes;
@@ -35,112 +70,43 @@ DPDK_17.05 {
qbman_release_desc_set_bpid;
qbman_result_DQ_fd;
qbman_result_DQ_flags;
- qbman_result_has_new_result;
- qbman_swp_acquire;
- qbman_swp_pull;
- qbman_swp_release;
- rte_fslmc_driver_register;
- rte_fslmc_driver_unregister;
- rte_fslmc_vfio_dmamap;
- rte_mcp_ptr_list;
-
- local: *;
-};
-
-DPDK_17.08 {
- global:
-
- dpaa2_io_portal;
- dpaa2_get_qbman_swp;
- dpci_set_rx_queue;
- dpcon_open;
- dpcon_get_attributes;
- dpio_add_static_dequeue_channel;
- dpio_remove_static_dequeue_channel;
- mc_get_soc_version;
- mc_get_version;
- qbman_check_new_result;
- qbman_eq_desc_set_dca;
- qbman_get_dqrr_from_idx;
- qbman_get_dqrr_idx;
qbman_result_DQ_fqd_ctx;
+ qbman_result_DQ_odpid;
+ qbman_result_DQ_seqnum;
qbman_result_SCN_state;
+ qbman_result_eqresp_fd;
+ qbman_result_eqresp_rc;
+ qbman_result_eqresp_rspid;
+ qbman_result_eqresp_set_rspid;
+ qbman_result_has_new_result;
+ qbman_swp_acquire;
qbman_swp_dqrr_consume;
+ qbman_swp_dqrr_idx_consume;
qbman_swp_dqrr_next;
qbman_swp_enqueue_multiple;
qbman_swp_enqueue_multiple_desc;
+ qbman_swp_enqueue_multiple_fd;
qbman_swp_interrupt_clear_status;
+ qbman_swp_prefetch_dqrr_next;
+ qbman_swp_pull;
qbman_swp_push_set;
+ qbman_swp_release;
rte_dpaa2_alloc_dpci_dev;
- rte_fslmc_object_register;
- rte_global_active_dqs_list;
-
-} DPDK_17.05;
-
-DPDK_17.11 {
- global:
-
- dpaa2_dpbp_supported;
rte_dpaa2_dev_type;
+ rte_dpaa2_free_dpci_dev;
rte_dpaa2_intr_disable;
rte_dpaa2_intr_enable;
-
-} DPDK_17.08;
-
-DPDK_18.02 {
- global:
-
- dpaa2_svr_family;
- dpaa2_virt_mode;
- per_lcore_dpaa2_held_bufs;
- qbman_fq_query_state;
- qbman_fq_state_frame_count;
- qbman_swp_dqrr_idx_consume;
- qbman_swp_prefetch_dqrr_next;
- rte_fslmc_get_device_count;
-
-} DPDK_17.11;
-
-DPDK_18.05 {
- global:
-
- dpaa2_affine_qbman_ethrx_swp;
- dpdmai_close;
- dpdmai_disable;
- dpdmai_enable;
- dpdmai_get_attributes;
- dpdmai_get_rx_queue;
- dpdmai_get_tx_queue;
- dpdmai_open;
- dpdmai_set_rx_queue;
- rte_dpaa2_free_dpci_dev;
rte_dpaa2_memsegs;
-
-} DPDK_18.02;
-
-DPDK_18.11 {
- global:
- dpaa2_dqrr_size;
- dpaa2_eqcr_size;
- dpci_get_opr;
- dpci_set_opr;
-
-} DPDK_18.05;
-
-DPDK_19.05 {
- global:
- dpaa2_free_eq_descriptors;
-
- qbman_eq_desc_set_orp;
- qbman_eq_desc_set_token;
- qbman_result_DQ_odpid;
- qbman_result_DQ_seqnum;
- qbman_result_eqresp_fd;
- qbman_result_eqresp_rc;
- qbman_result_eqresp_rspid;
- qbman_result_eqresp_set_rspid;
- qbman_swp_enqueue_multiple_fd;
-} DPDK_18.11;
+ rte_fslmc_driver_register;
+ rte_fslmc_driver_unregister;
+ rte_fslmc_get_device_count;
+ rte_fslmc_object_register;
+ rte_fslmc_vfio_dmamap;
+ rte_global_active_dqs_list;
+ rte_mcp_ptr_list;
+
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/drivers/bus/ifpga/rte_bus_ifpga_version.map b/drivers/bus/ifpga/rte_bus_ifpga_version.map
index 964c9a9c45..05b4a28c1b 100644
--- a/drivers/bus/ifpga/rte_bus_ifpga_version.map
+++ b/drivers/bus/ifpga/rte_bus_ifpga_version.map
@@ -1,17 +1,11 @@
-DPDK_18.05 {
+DPDK_20.0 {
global:
- rte_ifpga_get_integer32_arg;
- rte_ifpga_get_string_arg;
rte_ifpga_driver_register;
rte_ifpga_driver_unregister;
+ rte_ifpga_find_afu_by_name;
+ rte_ifpga_get_integer32_arg;
+ rte_ifpga_get_string_arg;
local: *;
};
-
-DPDK_19.05 {
- global:
-
- rte_ifpga_find_afu_by_name;
-
-} DPDK_18.05;
diff --git a/drivers/bus/pci/rte_bus_pci_version.map b/drivers/bus/pci/rte_bus_pci_version.map
index 27e9c4f101..012d817e14 100644
--- a/drivers/bus/pci/rte_bus_pci_version.map
+++ b/drivers/bus/pci/rte_bus_pci_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
rte_pci_dump;
diff --git a/drivers/bus/vdev/rte_bus_vdev_version.map b/drivers/bus/vdev/rte_bus_vdev_version.map
index 590cf9b437..5abb10ecb0 100644
--- a/drivers/bus/vdev/rte_bus_vdev_version.map
+++ b/drivers/bus/vdev/rte_bus_vdev_version.map
@@ -1,18 +1,12 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
+ rte_vdev_add_custom_scan;
rte_vdev_init;
rte_vdev_register;
+ rte_vdev_remove_custom_scan;
rte_vdev_uninit;
rte_vdev_unregister;
local: *;
};
-
-DPDK_18.02 {
- global:
-
- rte_vdev_add_custom_scan;
- rte_vdev_remove_custom_scan;
-
-} DPDK_17.11;
diff --git a/drivers/bus/vmbus/rte_bus_vmbus_version.map b/drivers/bus/vmbus/rte_bus_vmbus_version.map
index ae231ad329..cbaaebc06c 100644
--- a/drivers/bus/vmbus/rte_bus_vmbus_version.map
+++ b/drivers/bus/vmbus/rte_bus_vmbus_version.map
@@ -1,6 +1,4 @@
-/* SPDX-License-Identifier: BSD-3-Clause */
-
-DPDK_18.08 {
+DPDK_20.0 {
global:
rte_vmbus_chan_close;
@@ -20,6 +18,7 @@ DPDK_18.08 {
rte_vmbus_probe;
rte_vmbus_register;
rte_vmbus_scan;
+ rte_vmbus_set_latency;
rte_vmbus_sub_channel_index;
rte_vmbus_subchan_open;
rte_vmbus_unmap_device;
@@ -27,10 +26,3 @@ DPDK_18.08 {
local: *;
};
-
-DPDK_18.11 {
- global:
-
- rte_vmbus_set_latency;
-
-} DPDK_18.08;
diff --git a/drivers/common/cpt/rte_common_cpt_version.map b/drivers/common/cpt/rte_common_cpt_version.map
index 382ec4bd44..7f1929d58e 100644
--- a/drivers/common/cpt/rte_common_cpt_version.map
+++ b/drivers/common/cpt/rte_common_cpt_version.map
@@ -1,14 +1,9 @@
-DPDK_18.11 {
+DPDK_20.0 {
global:
+ cpt_pmd_ops_helper_asym_get_mlen;
cpt_pmd_ops_helper_get_mlen_direct_mode;
cpt_pmd_ops_helper_get_mlen_sg_mode;
-};
-
-DPDK_19.11 {
- global:
-
- cpt_pmd_ops_helper_asym_get_mlen;
local: *;
};
diff --git a/drivers/common/dpaax/rte_common_dpaax_version.map b/drivers/common/dpaax/rte_common_dpaax_version.map
index a7699ae4dd..f72eba761d 100644
--- a/drivers/common/dpaax/rte_common_dpaax_version.map
+++ b/drivers/common/dpaax/rte_common_dpaax_version.map
@@ -1,29 +1,23 @@
-DPDK_18.11 {
+DPDK_20.0 {
global:
- dpaax_iova_table_update;
dpaax_iova_table_depopulate;
dpaax_iova_table_dump;
dpaax_iova_table_p;
dpaax_iova_table_populate;
-
- local: *;
-};
-
-DPDK_19.11 {
- global:
+ dpaax_iova_table_update;
of_device_is_available;
of_device_is_compatible;
of_find_compatible_node;
of_find_node_by_phandle;
of_get_address;
of_get_mac_address;
+ of_get_next_child;
of_get_parent;
of_get_property;
of_init_path;
of_n_addr_cells;
of_translate_address;
- of_get_next_child;
local: *;
-} DPDK_18.11;
+};
diff --git a/drivers/common/mvep/rte_common_mvep_version.map b/drivers/common/mvep/rte_common_mvep_version.map
index c71722d79f..030928439d 100644
--- a/drivers/common/mvep/rte_common_mvep_version.map
+++ b/drivers/common/mvep/rte_common_mvep_version.map
@@ -1,6 +1,8 @@
-DPDK_18.11 {
+DPDK_20.0 {
global:
- rte_mvep_init;
rte_mvep_deinit;
+ rte_mvep_init;
+
+ local: *;
};
diff --git a/drivers/common/octeontx/rte_common_octeontx_version.map b/drivers/common/octeontx/rte_common_octeontx_version.map
index a9b3cff9bc..c15fb89112 100644
--- a/drivers/common/octeontx/rte_common_octeontx_version.map
+++ b/drivers/common/octeontx/rte_common_octeontx_version.map
@@ -1,8 +1,10 @@
-DPDK_18.05 {
+DPDK_20.0 {
global:
octeontx_logtype_mbox;
+ octeontx_mbox_send;
octeontx_mbox_set_ram_mbox_base;
octeontx_mbox_set_reg;
- octeontx_mbox_send;
+
+ local: *;
};
diff --git a/drivers/common/octeontx2/rte_common_octeontx2_version.map b/drivers/common/octeontx2/rte_common_octeontx2_version.map
index 4400120da0..adad21a2d6 100644
--- a/drivers/common/octeontx2/rte_common_octeontx2_version.map
+++ b/drivers/common/octeontx2/rte_common_octeontx2_version.map
@@ -1,39 +1,35 @@
-DPDK_19.08 {
+DPDK_20.0 {
global:
otx2_dev_active_vfs;
otx2_dev_fini;
otx2_dev_priv_init;
-
+ otx2_disable_irqs;
+ otx2_intra_dev_get_cfg;
otx2_logtype_base;
otx2_logtype_dpi;
otx2_logtype_mbox;
+ otx2_logtype_nix;
otx2_logtype_npa;
otx2_logtype_npc;
- otx2_logtype_nix;
otx2_logtype_sso;
- otx2_logtype_tm;
otx2_logtype_tim;
-
+ otx2_logtype_tm;
otx2_mbox_alloc_msg_rsp;
otx2_mbox_get_rsp;
otx2_mbox_get_rsp_tmo;
otx2_mbox_id2name;
otx2_mbox_msg_send;
otx2_mbox_wait_for_rsp;
-
- otx2_intra_dev_get_cfg;
otx2_npa_lf_active;
otx2_npa_lf_obj_get;
otx2_npa_lf_obj_ref;
otx2_npa_pf_func_get;
otx2_npa_set_defaults;
+ otx2_register_irq;
otx2_sso_pf_func_get;
otx2_sso_pf_func_set;
-
- otx2_disable_irqs;
otx2_unregister_irq;
- otx2_register_irq;
local: *;
};
diff --git a/drivers/compress/isal/rte_pmd_isal_version.map b/drivers/compress/isal/rte_pmd_isal_version.map
index de8e412ff1..f9f17e4f6e 100644
--- a/drivers/compress/isal/rte_pmd_isal_version.map
+++ b/drivers/compress/isal/rte_pmd_isal_version.map
@@ -1,3 +1,3 @@
-DPDK_18.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/compress/octeontx/rte_pmd_octeontx_compress_version.map b/drivers/compress/octeontx/rte_pmd_octeontx_compress_version.map
index ad6e191e49..f9f17e4f6e 100644
--- a/drivers/compress/octeontx/rte_pmd_octeontx_compress_version.map
+++ b/drivers/compress/octeontx/rte_pmd_octeontx_compress_version.map
@@ -1,3 +1,3 @@
-DPDK_18.08 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/compress/qat/rte_pmd_qat_version.map b/drivers/compress/qat/rte_pmd_qat_version.map
index ad6e191e49..f9f17e4f6e 100644
--- a/drivers/compress/qat/rte_pmd_qat_version.map
+++ b/drivers/compress/qat/rte_pmd_qat_version.map
@@ -1,3 +1,3 @@
-DPDK_18.08 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/compress/zlib/rte_pmd_zlib_version.map b/drivers/compress/zlib/rte_pmd_zlib_version.map
index ad6e191e49..f9f17e4f6e 100644
--- a/drivers/compress/zlib/rte_pmd_zlib_version.map
+++ b/drivers/compress/zlib/rte_pmd_zlib_version.map
@@ -1,3 +1,3 @@
-DPDK_18.08 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map b/drivers/crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map
index dc4d417b7b..f9f17e4f6e 100644
--- a/drivers/crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map
+++ b/drivers/crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map
@@ -1,3 +1,3 @@
-DPDK_16.04 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/aesni_mb/rte_pmd_aesni_mb_version.map b/drivers/crypto/aesni_mb/rte_pmd_aesni_mb_version.map
index ad607bbedd..f9f17e4f6e 100644
--- a/drivers/crypto/aesni_mb/rte_pmd_aesni_mb_version.map
+++ b/drivers/crypto/aesni_mb/rte_pmd_aesni_mb_version.map
@@ -1,3 +1,3 @@
-DPDK_2.2 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/armv8/rte_pmd_armv8_version.map b/drivers/crypto/armv8/rte_pmd_armv8_version.map
index 1f84b68a83..f9f17e4f6e 100644
--- a/drivers/crypto/armv8/rte_pmd_armv8_version.map
+++ b/drivers/crypto/armv8/rte_pmd_armv8_version.map
@@ -1,3 +1,3 @@
-DPDK_17.02 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/caam_jr/rte_pmd_caam_jr_version.map b/drivers/crypto/caam_jr/rte_pmd_caam_jr_version.map
index 521e51f411..f9f17e4f6e 100644
--- a/drivers/crypto/caam_jr/rte_pmd_caam_jr_version.map
+++ b/drivers/crypto/caam_jr/rte_pmd_caam_jr_version.map
@@ -1,4 +1,3 @@
-DPDK_18.11 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/ccp/rte_pmd_ccp_version.map b/drivers/crypto/ccp/rte_pmd_ccp_version.map
index 9b9ab1a4cf..f9f17e4f6e 100644
--- a/drivers/crypto/ccp/rte_pmd_ccp_version.map
+++ b/drivers/crypto/ccp/rte_pmd_ccp_version.map
@@ -1,4 +1,3 @@
-DPDK_18.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/dpaa2_sec/rte_pmd_dpaa2_sec_version.map b/drivers/crypto/dpaa2_sec/rte_pmd_dpaa2_sec_version.map
index 0bfb986d0b..5952d645fd 100644
--- a/drivers/crypto/dpaa2_sec/rte_pmd_dpaa2_sec_version.map
+++ b/drivers/crypto/dpaa2_sec/rte_pmd_dpaa2_sec_version.map
@@ -1,12 +1,8 @@
-DPDK_17.05 {
-
- local: *;
-};
-
-DPDK_18.11 {
+DPDK_20.0 {
global:
dpaa2_sec_eventq_attach;
dpaa2_sec_eventq_detach;
-} DPDK_17.05;
+ local: *;
+};
diff --git a/drivers/crypto/dpaa_sec/rte_pmd_dpaa_sec_version.map b/drivers/crypto/dpaa_sec/rte_pmd_dpaa_sec_version.map
index cc7f2162e0..8580fa13db 100644
--- a/drivers/crypto/dpaa_sec/rte_pmd_dpaa_sec_version.map
+++ b/drivers/crypto/dpaa_sec/rte_pmd_dpaa_sec_version.map
@@ -1,12 +1,8 @@
-DPDK_17.11 {
-
- local: *;
-};
-
-DPDK_19.11 {
+DPDK_20.0 {
global:
dpaa_sec_eventq_attach;
dpaa_sec_eventq_detach;
-} DPDK_17.11;
+ local: *;
+};
diff --git a/drivers/crypto/kasumi/rte_pmd_kasumi_version.map b/drivers/crypto/kasumi/rte_pmd_kasumi_version.map
index 8ffeca934e..f9f17e4f6e 100644
--- a/drivers/crypto/kasumi/rte_pmd_kasumi_version.map
+++ b/drivers/crypto/kasumi/rte_pmd_kasumi_version.map
@@ -1,3 +1,3 @@
-DPDK_16.07 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/mvsam/rte_pmd_mvsam_version.map b/drivers/crypto/mvsam/rte_pmd_mvsam_version.map
index a753031720..f9f17e4f6e 100644
--- a/drivers/crypto/mvsam/rte_pmd_mvsam_version.map
+++ b/drivers/crypto/mvsam/rte_pmd_mvsam_version.map
@@ -1,3 +1,3 @@
-DPDK_17.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/nitrox/rte_pmd_nitrox_version.map b/drivers/crypto/nitrox/rte_pmd_nitrox_version.map
index 406964d1fc..f9f17e4f6e 100644
--- a/drivers/crypto/nitrox/rte_pmd_nitrox_version.map
+++ b/drivers/crypto/nitrox/rte_pmd_nitrox_version.map
@@ -1,3 +1,3 @@
-DPDK_19.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/null/rte_pmd_null_crypto_version.map b/drivers/crypto/null/rte_pmd_null_crypto_version.map
index dc4d417b7b..f9f17e4f6e 100644
--- a/drivers/crypto/null/rte_pmd_null_crypto_version.map
+++ b/drivers/crypto/null/rte_pmd_null_crypto_version.map
@@ -1,3 +1,3 @@
-DPDK_16.04 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map b/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
index 521e51f411..f9f17e4f6e 100644
--- a/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
+++ b/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
@@ -1,4 +1,3 @@
-DPDK_18.11 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/octeontx2/rte_pmd_octeontx2_crypto_version.map b/drivers/crypto/octeontx2/rte_pmd_octeontx2_crypto_version.map
index b7b7c91683..f9f17e4f6e 100644
--- a/drivers/crypto/octeontx2/rte_pmd_octeontx2_crypto_version.map
+++ b/drivers/crypto/octeontx2/rte_pmd_octeontx2_crypto_version.map
@@ -1,4 +1,3 @@
-DPDK_19.11 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/openssl/rte_pmd_openssl_version.map b/drivers/crypto/openssl/rte_pmd_openssl_version.map
index cc5829e30b..f9f17e4f6e 100644
--- a/drivers/crypto/openssl/rte_pmd_openssl_version.map
+++ b/drivers/crypto/openssl/rte_pmd_openssl_version.map
@@ -1,3 +1,3 @@
-DPDK_16.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/scheduler/rte_pmd_crypto_scheduler_version.map b/drivers/crypto/scheduler/rte_pmd_crypto_scheduler_version.map
index 5c43127cf2..077afedce7 100644
--- a/drivers/crypto/scheduler/rte_pmd_crypto_scheduler_version.map
+++ b/drivers/crypto/scheduler/rte_pmd_crypto_scheduler_version.map
@@ -1,21 +1,16 @@
-DPDK_17.02 {
+DPDK_20.0 {
global:
rte_cryptodev_scheduler_load_user_scheduler;
- rte_cryptodev_scheduler_slave_attach;
- rte_cryptodev_scheduler_slave_detach;
- rte_cryptodev_scheduler_ordering_set;
- rte_cryptodev_scheduler_ordering_get;
-
-};
-
-DPDK_17.05 {
- global:
-
rte_cryptodev_scheduler_mode_get;
rte_cryptodev_scheduler_mode_set;
rte_cryptodev_scheduler_option_get;
rte_cryptodev_scheduler_option_set;
+ rte_cryptodev_scheduler_ordering_get;
+ rte_cryptodev_scheduler_ordering_set;
+ rte_cryptodev_scheduler_slave_attach;
+ rte_cryptodev_scheduler_slave_detach;
rte_cryptodev_scheduler_slaves_get;
-} DPDK_17.02;
+ local: *;
+};
diff --git a/drivers/crypto/snow3g/rte_pmd_snow3g_version.map b/drivers/crypto/snow3g/rte_pmd_snow3g_version.map
index dc4d417b7b..f9f17e4f6e 100644
--- a/drivers/crypto/snow3g/rte_pmd_snow3g_version.map
+++ b/drivers/crypto/snow3g/rte_pmd_snow3g_version.map
@@ -1,3 +1,3 @@
-DPDK_16.04 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/virtio/rte_pmd_virtio_crypto_version.map b/drivers/crypto/virtio/rte_pmd_virtio_crypto_version.map
index de8e412ff1..f9f17e4f6e 100644
--- a/drivers/crypto/virtio/rte_pmd_virtio_crypto_version.map
+++ b/drivers/crypto/virtio/rte_pmd_virtio_crypto_version.map
@@ -1,3 +1,3 @@
-DPDK_18.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/zuc/rte_pmd_zuc_version.map b/drivers/crypto/zuc/rte_pmd_zuc_version.map
index cc5829e30b..f9f17e4f6e 100644
--- a/drivers/crypto/zuc/rte_pmd_zuc_version.map
+++ b/drivers/crypto/zuc/rte_pmd_zuc_version.map
@@ -1,3 +1,3 @@
-DPDK_16.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/dpaa/rte_pmd_dpaa_event_version.map b/drivers/event/dpaa/rte_pmd_dpaa_event_version.map
index 179140fb87..f9f17e4f6e 100644
--- a/drivers/event/dpaa/rte_pmd_dpaa_event_version.map
+++ b/drivers/event/dpaa/rte_pmd_dpaa_event_version.map
@@ -1,4 +1,3 @@
-DPDK_18.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/dpaa2/rte_pmd_dpaa2_event_version.map b/drivers/event/dpaa2/rte_pmd_dpaa2_event_version.map
index 1c0b7559dc..f9f17e4f6e 100644
--- a/drivers/event/dpaa2/rte_pmd_dpaa2_event_version.map
+++ b/drivers/event/dpaa2/rte_pmd_dpaa2_event_version.map
@@ -1,3 +1,3 @@
-DPDK_17.08 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/dsw/rte_pmd_dsw_event_version.map b/drivers/event/dsw/rte_pmd_dsw_event_version.map
index 24bd5cdb35..f9f17e4f6e 100644
--- a/drivers/event/dsw/rte_pmd_dsw_event_version.map
+++ b/drivers/event/dsw/rte_pmd_dsw_event_version.map
@@ -1,3 +1,3 @@
-DPDK_18.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/octeontx/rte_pmd_octeontx_event_version.map b/drivers/event/octeontx/rte_pmd_octeontx_event_version.map
index 5352e7e3bd..f9f17e4f6e 100644
--- a/drivers/event/octeontx/rte_pmd_octeontx_event_version.map
+++ b/drivers/event/octeontx/rte_pmd_octeontx_event_version.map
@@ -1,3 +1,3 @@
-DPDK_17.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/octeontx2/rte_pmd_octeontx2_event_version.map b/drivers/event/octeontx2/rte_pmd_octeontx2_event_version.map
index 41c65c8c9c..f9f17e4f6e 100644
--- a/drivers/event/octeontx2/rte_pmd_octeontx2_event_version.map
+++ b/drivers/event/octeontx2/rte_pmd_octeontx2_event_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
+DPDK_20.0 {
local: *;
};
-
diff --git a/drivers/event/opdl/rte_pmd_opdl_event_version.map b/drivers/event/opdl/rte_pmd_opdl_event_version.map
index 58b94270d4..f9f17e4f6e 100644
--- a/drivers/event/opdl/rte_pmd_opdl_event_version.map
+++ b/drivers/event/opdl/rte_pmd_opdl_event_version.map
@@ -1,3 +1,3 @@
-DPDK_18.02 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/skeleton/rte_pmd_skeleton_event_version.map b/drivers/event/skeleton/rte_pmd_skeleton_event_version.map
index 8591cc0b18..f9f17e4f6e 100644
--- a/drivers/event/skeleton/rte_pmd_skeleton_event_version.map
+++ b/drivers/event/skeleton/rte_pmd_skeleton_event_version.map
@@ -1,4 +1,3 @@
-DPDK_17.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/sw/rte_pmd_sw_event_version.map b/drivers/event/sw/rte_pmd_sw_event_version.map
index 5352e7e3bd..f9f17e4f6e 100644
--- a/drivers/event/sw/rte_pmd_sw_event_version.map
+++ b/drivers/event/sw/rte_pmd_sw_event_version.map
@@ -1,3 +1,3 @@
-DPDK_17.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/mempool/bucket/rte_mempool_bucket_version.map b/drivers/mempool/bucket/rte_mempool_bucket_version.map
index 9b9ab1a4cf..f9f17e4f6e 100644
--- a/drivers/mempool/bucket/rte_mempool_bucket_version.map
+++ b/drivers/mempool/bucket/rte_mempool_bucket_version.map
@@ -1,4 +1,3 @@
-DPDK_18.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/mempool/dpaa/rte_mempool_dpaa_version.map b/drivers/mempool/dpaa/rte_mempool_dpaa_version.map
index 60bf50b2d1..9eebaf7ffd 100644
--- a/drivers/mempool/dpaa/rte_mempool_dpaa_version.map
+++ b/drivers/mempool/dpaa/rte_mempool_dpaa_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
rte_dpaa_bpid_info;
diff --git a/drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map b/drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map
index b45e7a9ac1..cd4bc88273 100644
--- a/drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map
+++ b/drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map
@@ -1,16 +1,10 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
rte_dpaa2_bpid_info;
rte_dpaa2_mbuf_alloc_bulk;
-
- local: *;
-};
-
-DPDK_18.05 {
- global:
-
rte_dpaa2_mbuf_from_buf_addr;
rte_dpaa2_mbuf_pool_bpid;
-} DPDK_17.05;
+ local: *;
+};
diff --git a/drivers/mempool/octeontx/rte_mempool_octeontx_version.map b/drivers/mempool/octeontx/rte_mempool_octeontx_version.map
index a753031720..f9f17e4f6e 100644
--- a/drivers/mempool/octeontx/rte_mempool_octeontx_version.map
+++ b/drivers/mempool/octeontx/rte_mempool_octeontx_version.map
@@ -1,3 +1,3 @@
-DPDK_17.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/mempool/octeontx2/rte_mempool_octeontx2_version.map b/drivers/mempool/octeontx2/rte_mempool_octeontx2_version.map
index d703368c31..d4f81aed8e 100644
--- a/drivers/mempool/octeontx2/rte_mempool_octeontx2_version.map
+++ b/drivers/mempool/octeontx2/rte_mempool_octeontx2_version.map
@@ -1,8 +1,8 @@
-DPDK_19.08 {
+DPDK_20.0 {
global:
- otx2_npa_lf_init;
otx2_npa_lf_fini;
+ otx2_npa_lf_init;
local: *;
};
diff --git a/drivers/mempool/ring/rte_mempool_ring_version.map b/drivers/mempool/ring/rte_mempool_ring_version.map
index 8591cc0b18..f9f17e4f6e 100644
--- a/drivers/mempool/ring/rte_mempool_ring_version.map
+++ b/drivers/mempool/ring/rte_mempool_ring_version.map
@@ -1,4 +1,3 @@
-DPDK_17.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/mempool/stack/rte_mempool_stack_version.map b/drivers/mempool/stack/rte_mempool_stack_version.map
index 8591cc0b18..f9f17e4f6e 100644
--- a/drivers/mempool/stack/rte_mempool_stack_version.map
+++ b/drivers/mempool/stack/rte_mempool_stack_version.map
@@ -1,4 +1,3 @@
-DPDK_17.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/af_packet/rte_pmd_af_packet_version.map b/drivers/net/af_packet/rte_pmd_af_packet_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/af_packet/rte_pmd_af_packet_version.map
+++ b/drivers/net/af_packet/rte_pmd_af_packet_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/af_xdp/rte_pmd_af_xdp_version.map b/drivers/net/af_xdp/rte_pmd_af_xdp_version.map
index c6db030fe6..f9f17e4f6e 100644
--- a/drivers/net/af_xdp/rte_pmd_af_xdp_version.map
+++ b/drivers/net/af_xdp/rte_pmd_af_xdp_version.map
@@ -1,3 +1,3 @@
-DPDK_19.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ark/rte_pmd_ark_version.map b/drivers/net/ark/rte_pmd_ark_version.map
index 1062e0429f..f9f17e4f6e 100644
--- a/drivers/net/ark/rte_pmd_ark_version.map
+++ b/drivers/net/ark/rte_pmd_ark_version.map
@@ -1,4 +1,3 @@
-DPDK_17.05 {
- local: *;
-
+DPDK_20.0 {
+ local: *;
};
diff --git a/drivers/net/atlantic/rte_pmd_atlantic_version.map b/drivers/net/atlantic/rte_pmd_atlantic_version.map
index b16faa999f..9b04838d84 100644
--- a/drivers/net/atlantic/rte_pmd_atlantic_version.map
+++ b/drivers/net/atlantic/rte_pmd_atlantic_version.map
@@ -1,5 +1,4 @@
-DPDK_18.11 {
-
+DPDK_20.0 {
local: *;
};
@@ -13,4 +12,3 @@ EXPERIMENTAL {
rte_pmd_atl_macsec_select_txsa;
rte_pmd_atl_macsec_select_rxsa;
};
-
diff --git a/drivers/net/avp/rte_pmd_avp_version.map b/drivers/net/avp/rte_pmd_avp_version.map
index 5352e7e3bd..f9f17e4f6e 100644
--- a/drivers/net/avp/rte_pmd_avp_version.map
+++ b/drivers/net/avp/rte_pmd_avp_version.map
@@ -1,3 +1,3 @@
-DPDK_17.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/axgbe/rte_pmd_axgbe_version.map b/drivers/net/axgbe/rte_pmd_axgbe_version.map
index de8e412ff1..f9f17e4f6e 100644
--- a/drivers/net/axgbe/rte_pmd_axgbe_version.map
+++ b/drivers/net/axgbe/rte_pmd_axgbe_version.map
@@ -1,3 +1,3 @@
-DPDK_18.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/bnx2x/rte_pmd_bnx2x_version.map b/drivers/net/bnx2x/rte_pmd_bnx2x_version.map
index bd8138a034..f9f17e4f6e 100644
--- a/drivers/net/bnx2x/rte_pmd_bnx2x_version.map
+++ b/drivers/net/bnx2x/rte_pmd_bnx2x_version.map
@@ -1,4 +1,3 @@
-DPDK_2.1 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/bnxt/rte_pmd_bnxt_version.map b/drivers/net/bnxt/rte_pmd_bnxt_version.map
index 4750d40ad6..bb52562347 100644
--- a/drivers/net/bnxt/rte_pmd_bnxt_version.map
+++ b/drivers/net/bnxt/rte_pmd_bnxt_version.map
@@ -1,4 +1,4 @@
-DPDK_17.08 {
+DPDK_20.0 {
global:
rte_pmd_bnxt_get_vf_rx_status;
@@ -10,13 +10,13 @@ DPDK_17.08 {
rte_pmd_bnxt_set_tx_loopback;
rte_pmd_bnxt_set_vf_mac_addr;
rte_pmd_bnxt_set_vf_mac_anti_spoof;
+ rte_pmd_bnxt_set_vf_persist_stats;
rte_pmd_bnxt_set_vf_rate_limit;
rte_pmd_bnxt_set_vf_rxmode;
rte_pmd_bnxt_set_vf_vlan_anti_spoof;
rte_pmd_bnxt_set_vf_vlan_filter;
rte_pmd_bnxt_set_vf_vlan_insert;
rte_pmd_bnxt_set_vf_vlan_stripq;
- rte_pmd_bnxt_set_vf_persist_stats;
local: *;
};
diff --git a/drivers/net/bonding/rte_pmd_bond_version.map b/drivers/net/bonding/rte_pmd_bond_version.map
index 00d955c481..270c7d5d55 100644
--- a/drivers/net/bonding/rte_pmd_bond_version.map
+++ b/drivers/net/bonding/rte_pmd_bond_version.map
@@ -1,9 +1,21 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
+ rte_eth_bond_8023ad_agg_selection_get;
+ rte_eth_bond_8023ad_agg_selection_set;
+ rte_eth_bond_8023ad_conf_get;
+ rte_eth_bond_8023ad_dedicated_queues_disable;
+ rte_eth_bond_8023ad_dedicated_queues_enable;
+ rte_eth_bond_8023ad_ext_collect;
+ rte_eth_bond_8023ad_ext_collect_get;
+ rte_eth_bond_8023ad_ext_distrib;
+ rte_eth_bond_8023ad_ext_distrib_get;
+ rte_eth_bond_8023ad_ext_slowtx;
+ rte_eth_bond_8023ad_setup;
rte_eth_bond_8023ad_slave_info;
rte_eth_bond_active_slaves_get;
rte_eth_bond_create;
+ rte_eth_bond_free;
rte_eth_bond_link_monitoring_set;
rte_eth_bond_mac_address_reset;
rte_eth_bond_mac_address_set;
@@ -19,36 +31,3 @@ DPDK_2.0 {
local: *;
};
-
-DPDK_2.1 {
- global:
-
- rte_eth_bond_free;
-
-} DPDK_2.0;
-
-DPDK_16.04 {
-};
-
-DPDK_16.07 {
- global:
-
- rte_eth_bond_8023ad_ext_collect;
- rte_eth_bond_8023ad_ext_collect_get;
- rte_eth_bond_8023ad_ext_distrib;
- rte_eth_bond_8023ad_ext_distrib_get;
- rte_eth_bond_8023ad_ext_slowtx;
-
-} DPDK_16.04;
-
-DPDK_17.08 {
- global:
-
- rte_eth_bond_8023ad_dedicated_queues_enable;
- rte_eth_bond_8023ad_dedicated_queues_disable;
- rte_eth_bond_8023ad_agg_selection_get;
- rte_eth_bond_8023ad_agg_selection_set;
- rte_eth_bond_8023ad_conf_get;
- rte_eth_bond_8023ad_setup;
-
-} DPDK_16.07;
diff --git a/drivers/net/cxgbe/rte_pmd_cxgbe_version.map b/drivers/net/cxgbe/rte_pmd_cxgbe_version.map
index bd8138a034..f9f17e4f6e 100644
--- a/drivers/net/cxgbe/rte_pmd_cxgbe_version.map
+++ b/drivers/net/cxgbe/rte_pmd_cxgbe_version.map
@@ -1,4 +1,3 @@
-DPDK_2.1 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/dpaa/rte_pmd_dpaa_version.map b/drivers/net/dpaa/rte_pmd_dpaa_version.map
index 8cb4500b51..f403a1526d 100644
--- a/drivers/net/dpaa/rte_pmd_dpaa_version.map
+++ b/drivers/net/dpaa/rte_pmd_dpaa_version.map
@@ -1,12 +1,9 @@
-DPDK_17.11 {
-
- local: *;
-};
-
-DPDK_18.08 {
+DPDK_20.0 {
global:
dpaa_eth_eventq_attach;
dpaa_eth_eventq_detach;
rte_pmd_dpaa_set_tx_loopback;
-} DPDK_17.11;
+
+ local: *;
+};
diff --git a/drivers/net/dpaa2/rte_pmd_dpaa2_version.map b/drivers/net/dpaa2/rte_pmd_dpaa2_version.map
index d1b4cdb232..f2bb793319 100644
--- a/drivers/net/dpaa2/rte_pmd_dpaa2_version.map
+++ b/drivers/net/dpaa2/rte_pmd_dpaa2_version.map
@@ -1,15 +1,11 @@
-DPDK_17.05 {
-
- local: *;
-};
-
-DPDK_17.11 {
+DPDK_20.0 {
global:
dpaa2_eth_eventq_attach;
dpaa2_eth_eventq_detach;
-} DPDK_17.05;
+ local: *;
+};
EXPERIMENTAL {
global:
@@ -17,4 +13,4 @@ EXPERIMENTAL {
rte_pmd_dpaa2_mux_flow_create;
rte_pmd_dpaa2_set_custom_hash;
rte_pmd_dpaa2_set_timestamp;
-} DPDK_17.11;
+};
diff --git a/drivers/net/e1000/rte_pmd_e1000_version.map b/drivers/net/e1000/rte_pmd_e1000_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/e1000/rte_pmd_e1000_version.map
+++ b/drivers/net/e1000/rte_pmd_e1000_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ena/rte_pmd_ena_version.map b/drivers/net/ena/rte_pmd_ena_version.map
index 349c6e1c22..f9f17e4f6e 100644
--- a/drivers/net/ena/rte_pmd_ena_version.map
+++ b/drivers/net/ena/rte_pmd_ena_version.map
@@ -1,4 +1,3 @@
-DPDK_16.04 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/enetc/rte_pmd_enetc_version.map b/drivers/net/enetc/rte_pmd_enetc_version.map
index 521e51f411..f9f17e4f6e 100644
--- a/drivers/net/enetc/rte_pmd_enetc_version.map
+++ b/drivers/net/enetc/rte_pmd_enetc_version.map
@@ -1,4 +1,3 @@
-DPDK_18.11 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/enic/rte_pmd_enic_version.map b/drivers/net/enic/rte_pmd_enic_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/enic/rte_pmd_enic_version.map
+++ b/drivers/net/enic/rte_pmd_enic_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/failsafe/rte_pmd_failsafe_version.map b/drivers/net/failsafe/rte_pmd_failsafe_version.map
index b6d2840be4..f9f17e4f6e 100644
--- a/drivers/net/failsafe/rte_pmd_failsafe_version.map
+++ b/drivers/net/failsafe/rte_pmd_failsafe_version.map
@@ -1,4 +1,3 @@
-DPDK_17.08 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/fm10k/rte_pmd_fm10k_version.map b/drivers/net/fm10k/rte_pmd_fm10k_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/fm10k/rte_pmd_fm10k_version.map
+++ b/drivers/net/fm10k/rte_pmd_fm10k_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/hinic/rte_pmd_hinic_version.map b/drivers/net/hinic/rte_pmd_hinic_version.map
index 9a61188cd5..f9f17e4f6e 100644
--- a/drivers/net/hinic/rte_pmd_hinic_version.map
+++ b/drivers/net/hinic/rte_pmd_hinic_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/hns3/rte_pmd_hns3_version.map b/drivers/net/hns3/rte_pmd_hns3_version.map
index 35e5f2debb..f9f17e4f6e 100644
--- a/drivers/net/hns3/rte_pmd_hns3_version.map
+++ b/drivers/net/hns3/rte_pmd_hns3_version.map
@@ -1,3 +1,3 @@
-DPDK_19.11 {
- local: *;
+DPDK_20.0 {
+ local: *;
};
diff --git a/drivers/net/i40e/rte_pmd_i40e_version.map b/drivers/net/i40e/rte_pmd_i40e_version.map
index cccd5768c2..a80e69b93e 100644
--- a/drivers/net/i40e/rte_pmd_i40e_version.map
+++ b/drivers/net/i40e/rte_pmd_i40e_version.map
@@ -1,23 +1,34 @@
-DPDK_2.0 {
-
- local: *;
-};
-
-DPDK_17.02 {
+DPDK_20.0 {
global:
+ rte_pmd_i40e_add_vf_mac_addr;
+ rte_pmd_i40e_flow_add_del_packet_template;
+ rte_pmd_i40e_flow_type_mapping_get;
+ rte_pmd_i40e_flow_type_mapping_reset;
+ rte_pmd_i40e_flow_type_mapping_update;
+ rte_pmd_i40e_get_ddp_info;
+ rte_pmd_i40e_get_ddp_list;
rte_pmd_i40e_get_vf_stats;
+ rte_pmd_i40e_inset_get;
+ rte_pmd_i40e_inset_set;
rte_pmd_i40e_ping_vfs;
+ rte_pmd_i40e_process_ddp_package;
rte_pmd_i40e_ptype_mapping_get;
rte_pmd_i40e_ptype_mapping_replace;
rte_pmd_i40e_ptype_mapping_reset;
rte_pmd_i40e_ptype_mapping_update;
+ rte_pmd_i40e_query_vfid_by_mac;
rte_pmd_i40e_reset_vf_stats;
+ rte_pmd_i40e_rss_queue_region_conf;
+ rte_pmd_i40e_set_tc_strict_prio;
rte_pmd_i40e_set_tx_loopback;
rte_pmd_i40e_set_vf_broadcast;
rte_pmd_i40e_set_vf_mac_addr;
rte_pmd_i40e_set_vf_mac_anti_spoof;
+ rte_pmd_i40e_set_vf_max_bw;
rte_pmd_i40e_set_vf_multicast_promisc;
+ rte_pmd_i40e_set_vf_tc_bw_alloc;
+ rte_pmd_i40e_set_vf_tc_max_bw;
rte_pmd_i40e_set_vf_unicast_promisc;
rte_pmd_i40e_set_vf_vlan_anti_spoof;
rte_pmd_i40e_set_vf_vlan_filter;
@@ -25,43 +36,5 @@ DPDK_17.02 {
rte_pmd_i40e_set_vf_vlan_stripq;
rte_pmd_i40e_set_vf_vlan_tag;
-} DPDK_2.0;
-
-DPDK_17.05 {
- global:
-
- rte_pmd_i40e_set_tc_strict_prio;
- rte_pmd_i40e_set_vf_max_bw;
- rte_pmd_i40e_set_vf_tc_bw_alloc;
- rte_pmd_i40e_set_vf_tc_max_bw;
- rte_pmd_i40e_process_ddp_package;
- rte_pmd_i40e_get_ddp_list;
-
-} DPDK_17.02;
-
-DPDK_17.08 {
- global:
-
- rte_pmd_i40e_get_ddp_info;
-
-} DPDK_17.05;
-
-DPDK_17.11 {
- global:
-
- rte_pmd_i40e_add_vf_mac_addr;
- rte_pmd_i40e_flow_add_del_packet_template;
- rte_pmd_i40e_flow_type_mapping_update;
- rte_pmd_i40e_flow_type_mapping_get;
- rte_pmd_i40e_flow_type_mapping_reset;
- rte_pmd_i40e_query_vfid_by_mac;
- rte_pmd_i40e_rss_queue_region_conf;
-
-} DPDK_17.08;
-
-DPDK_18.02 {
- global:
-
- rte_pmd_i40e_inset_get;
- rte_pmd_i40e_inset_set;
-} DPDK_17.11;
\ No newline at end of file
+ local: *;
+};
diff --git a/drivers/net/iavf/rte_pmd_iavf_version.map b/drivers/net/iavf/rte_pmd_iavf_version.map
index 179140fb87..f9f17e4f6e 100644
--- a/drivers/net/iavf/rte_pmd_iavf_version.map
+++ b/drivers/net/iavf/rte_pmd_iavf_version.map
@@ -1,4 +1,3 @@
-DPDK_18.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ice/rte_pmd_ice_version.map b/drivers/net/ice/rte_pmd_ice_version.map
index 7b23b609da..f9f17e4f6e 100644
--- a/drivers/net/ice/rte_pmd_ice_version.map
+++ b/drivers/net/ice/rte_pmd_ice_version.map
@@ -1,4 +1,3 @@
-DPDK_19.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ifc/rte_pmd_ifc_version.map b/drivers/net/ifc/rte_pmd_ifc_version.map
index 9b9ab1a4cf..f9f17e4f6e 100644
--- a/drivers/net/ifc/rte_pmd_ifc_version.map
+++ b/drivers/net/ifc/rte_pmd_ifc_version.map
@@ -1,4 +1,3 @@
-DPDK_18.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map b/drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map
index fc8c95e919..f9f17e4f6e 100644
--- a/drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map
+++ b/drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map
@@ -1,4 +1,3 @@
-DPDK_19.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe_version.map b/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
index c814f96d72..21534dbc3d 100644
--- a/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
+++ b/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
@@ -1,57 +1,39 @@
-DPDK_2.0 {
-
- local: *;
-};
-
-DPDK_16.11 {
- global:
-
- rte_pmd_ixgbe_set_all_queues_drop_en;
- rte_pmd_ixgbe_set_tx_loopback;
- rte_pmd_ixgbe_set_vf_mac_addr;
- rte_pmd_ixgbe_set_vf_mac_anti_spoof;
- rte_pmd_ixgbe_set_vf_split_drop_en;
- rte_pmd_ixgbe_set_vf_vlan_anti_spoof;
- rte_pmd_ixgbe_set_vf_vlan_insert;
- rte_pmd_ixgbe_set_vf_vlan_stripq;
-} DPDK_2.0;
-
-DPDK_17.02 {
+DPDK_20.0 {
global:
+ rte_pmd_ixgbe_bypass_event_show;
+ rte_pmd_ixgbe_bypass_event_store;
+ rte_pmd_ixgbe_bypass_init;
+ rte_pmd_ixgbe_bypass_state_set;
+ rte_pmd_ixgbe_bypass_state_show;
+ rte_pmd_ixgbe_bypass_ver_show;
+ rte_pmd_ixgbe_bypass_wd_reset;
+ rte_pmd_ixgbe_bypass_wd_timeout_show;
+ rte_pmd_ixgbe_bypass_wd_timeout_store;
rte_pmd_ixgbe_macsec_config_rxsc;
rte_pmd_ixgbe_macsec_config_txsc;
rte_pmd_ixgbe_macsec_disable;
rte_pmd_ixgbe_macsec_enable;
rte_pmd_ixgbe_macsec_select_rxsa;
rte_pmd_ixgbe_macsec_select_txsa;
+ rte_pmd_ixgbe_ping_vf;
+ rte_pmd_ixgbe_set_all_queues_drop_en;
+ rte_pmd_ixgbe_set_tc_bw_alloc;
+ rte_pmd_ixgbe_set_tx_loopback;
+ rte_pmd_ixgbe_set_vf_mac_addr;
+ rte_pmd_ixgbe_set_vf_mac_anti_spoof;
rte_pmd_ixgbe_set_vf_rate_limit;
rte_pmd_ixgbe_set_vf_rx;
rte_pmd_ixgbe_set_vf_rxmode;
+ rte_pmd_ixgbe_set_vf_split_drop_en;
rte_pmd_ixgbe_set_vf_tx;
+ rte_pmd_ixgbe_set_vf_vlan_anti_spoof;
rte_pmd_ixgbe_set_vf_vlan_filter;
-} DPDK_16.11;
+ rte_pmd_ixgbe_set_vf_vlan_insert;
+ rte_pmd_ixgbe_set_vf_vlan_stripq;
-DPDK_17.05 {
- global:
-
- rte_pmd_ixgbe_ping_vf;
- rte_pmd_ixgbe_set_tc_bw_alloc;
-} DPDK_17.02;
-
-DPDK_17.08 {
- global:
-
- rte_pmd_ixgbe_bypass_event_show;
- rte_pmd_ixgbe_bypass_event_store;
- rte_pmd_ixgbe_bypass_init;
- rte_pmd_ixgbe_bypass_state_set;
- rte_pmd_ixgbe_bypass_state_show;
- rte_pmd_ixgbe_bypass_ver_show;
- rte_pmd_ixgbe_bypass_wd_reset;
- rte_pmd_ixgbe_bypass_wd_timeout_show;
- rte_pmd_ixgbe_bypass_wd_timeout_store;
-} DPDK_17.05;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/drivers/net/kni/rte_pmd_kni_version.map b/drivers/net/kni/rte_pmd_kni_version.map
index 8591cc0b18..f9f17e4f6e 100644
--- a/drivers/net/kni/rte_pmd_kni_version.map
+++ b/drivers/net/kni/rte_pmd_kni_version.map
@@ -1,4 +1,3 @@
-DPDK_17.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/liquidio/rte_pmd_liquidio_version.map b/drivers/net/liquidio/rte_pmd_liquidio_version.map
index 8591cc0b18..f9f17e4f6e 100644
--- a/drivers/net/liquidio/rte_pmd_liquidio_version.map
+++ b/drivers/net/liquidio/rte_pmd_liquidio_version.map
@@ -1,4 +1,3 @@
-DPDK_17.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/memif/rte_pmd_memif_version.map b/drivers/net/memif/rte_pmd_memif_version.map
index 8861484fb3..f9f17e4f6e 100644
--- a/drivers/net/memif/rte_pmd_memif_version.map
+++ b/drivers/net/memif/rte_pmd_memif_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
-
- local: *;
+DPDK_20.0 {
+ local: *;
};
diff --git a/drivers/net/mlx4/rte_pmd_mlx4_version.map b/drivers/net/mlx4/rte_pmd_mlx4_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/mlx4/rte_pmd_mlx4_version.map
+++ b/drivers/net/mlx4/rte_pmd_mlx4_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/mlx5/rte_pmd_mlx5_version.map b/drivers/net/mlx5/rte_pmd_mlx5_version.map
index ad607bbedd..f9f17e4f6e 100644
--- a/drivers/net/mlx5/rte_pmd_mlx5_version.map
+++ b/drivers/net/mlx5/rte_pmd_mlx5_version.map
@@ -1,3 +1,3 @@
-DPDK_2.2 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/mvneta/rte_pmd_mvneta_version.map b/drivers/net/mvneta/rte_pmd_mvneta_version.map
index 24bd5cdb35..f9f17e4f6e 100644
--- a/drivers/net/mvneta/rte_pmd_mvneta_version.map
+++ b/drivers/net/mvneta/rte_pmd_mvneta_version.map
@@ -1,3 +1,3 @@
-DPDK_18.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/mvpp2/rte_pmd_mvpp2_version.map b/drivers/net/mvpp2/rte_pmd_mvpp2_version.map
index a753031720..f9f17e4f6e 100644
--- a/drivers/net/mvpp2/rte_pmd_mvpp2_version.map
+++ b/drivers/net/mvpp2/rte_pmd_mvpp2_version.map
@@ -1,3 +1,3 @@
-DPDK_17.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/netvsc/rte_pmd_netvsc_version.map b/drivers/net/netvsc/rte_pmd_netvsc_version.map
index d534019a6b..f9f17e4f6e 100644
--- a/drivers/net/netvsc/rte_pmd_netvsc_version.map
+++ b/drivers/net/netvsc/rte_pmd_netvsc_version.map
@@ -1,5 +1,3 @@
-/* SPDX-License-Identifier: BSD-3-Clause */
-
-DPDK_18.08 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/nfb/rte_pmd_nfb_version.map b/drivers/net/nfb/rte_pmd_nfb_version.map
index fc8c95e919..f9f17e4f6e 100644
--- a/drivers/net/nfb/rte_pmd_nfb_version.map
+++ b/drivers/net/nfb/rte_pmd_nfb_version.map
@@ -1,4 +1,3 @@
-DPDK_19.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/nfp/rte_pmd_nfp_version.map b/drivers/net/nfp/rte_pmd_nfp_version.map
index ad607bbedd..f9f17e4f6e 100644
--- a/drivers/net/nfp/rte_pmd_nfp_version.map
+++ b/drivers/net/nfp/rte_pmd_nfp_version.map
@@ -1,3 +1,3 @@
-DPDK_2.2 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/null/rte_pmd_null_version.map b/drivers/net/null/rte_pmd_null_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/null/rte_pmd_null_version.map
+++ b/drivers/net/null/rte_pmd_null_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/octeontx/rte_pmd_octeontx_version.map b/drivers/net/octeontx/rte_pmd_octeontx_version.map
index a3161b14d0..f7cae02fac 100644
--- a/drivers/net/octeontx/rte_pmd_octeontx_version.map
+++ b/drivers/net/octeontx/rte_pmd_octeontx_version.map
@@ -1,11 +1,7 @@
-DPDK_17.11 {
-
- local: *;
-};
-
-DPDK_18.02 {
+DPDK_20.0 {
global:
rte_octeontx_pchan_map;
-} DPDK_17.11;
+ local: *;
+};
diff --git a/drivers/net/octeontx2/rte_pmd_octeontx2_version.map b/drivers/net/octeontx2/rte_pmd_octeontx2_version.map
index 9a61188cd5..f9f17e4f6e 100644
--- a/drivers/net/octeontx2/rte_pmd_octeontx2_version.map
+++ b/drivers/net/octeontx2/rte_pmd_octeontx2_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/pcap/rte_pmd_pcap_version.map b/drivers/net/pcap/rte_pmd_pcap_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/pcap/rte_pmd_pcap_version.map
+++ b/drivers/net/pcap/rte_pmd_pcap_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/pfe/rte_pmd_pfe_version.map b/drivers/net/pfe/rte_pmd_pfe_version.map
index b7b7c91683..f9f17e4f6e 100644
--- a/drivers/net/pfe/rte_pmd_pfe_version.map
+++ b/drivers/net/pfe/rte_pmd_pfe_version.map
@@ -1,4 +1,3 @@
-DPDK_19.11 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/qede/rte_pmd_qede_version.map b/drivers/net/qede/rte_pmd_qede_version.map
index 349c6e1c22..f9f17e4f6e 100644
--- a/drivers/net/qede/rte_pmd_qede_version.map
+++ b/drivers/net/qede/rte_pmd_qede_version.map
@@ -1,4 +1,3 @@
-DPDK_16.04 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ring/rte_pmd_ring_version.map b/drivers/net/ring/rte_pmd_ring_version.map
index 1f785d9409..ebb6be2733 100644
--- a/drivers/net/ring/rte_pmd_ring_version.map
+++ b/drivers/net/ring/rte_pmd_ring_version.map
@@ -1,14 +1,8 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
+ rte_eth_from_ring;
rte_eth_from_rings;
local: *;
};
-
-DPDK_2.2 {
- global:
-
- rte_eth_from_ring;
-
-} DPDK_2.0;
diff --git a/drivers/net/sfc/rte_pmd_sfc_version.map b/drivers/net/sfc/rte_pmd_sfc_version.map
index 31eca32ebe..f9f17e4f6e 100644
--- a/drivers/net/sfc/rte_pmd_sfc_version.map
+++ b/drivers/net/sfc/rte_pmd_sfc_version.map
@@ -1,4 +1,3 @@
-DPDK_17.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/softnic/rte_pmd_softnic_version.map b/drivers/net/softnic/rte_pmd_softnic_version.map
index bc44b06f98..50f113d5a2 100644
--- a/drivers/net/softnic/rte_pmd_softnic_version.map
+++ b/drivers/net/softnic/rte_pmd_softnic_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
rte_pmd_softnic_run;
diff --git a/drivers/net/szedata2/rte_pmd_szedata2_version.map b/drivers/net/szedata2/rte_pmd_szedata2_version.map
index ad607bbedd..f9f17e4f6e 100644
--- a/drivers/net/szedata2/rte_pmd_szedata2_version.map
+++ b/drivers/net/szedata2/rte_pmd_szedata2_version.map
@@ -1,3 +1,3 @@
-DPDK_2.2 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/tap/rte_pmd_tap_version.map b/drivers/net/tap/rte_pmd_tap_version.map
index 31eca32ebe..f9f17e4f6e 100644
--- a/drivers/net/tap/rte_pmd_tap_version.map
+++ b/drivers/net/tap/rte_pmd_tap_version.map
@@ -1,4 +1,3 @@
-DPDK_17.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/thunderx/rte_pmd_thunderx_version.map b/drivers/net/thunderx/rte_pmd_thunderx_version.map
index 1901bcb3b3..f9f17e4f6e 100644
--- a/drivers/net/thunderx/rte_pmd_thunderx_version.map
+++ b/drivers/net/thunderx/rte_pmd_thunderx_version.map
@@ -1,4 +1,3 @@
-DPDK_16.07 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/vdev_netvsc/rte_pmd_vdev_netvsc_version.map b/drivers/net/vdev_netvsc/rte_pmd_vdev_netvsc_version.map
index 179140fb87..f9f17e4f6e 100644
--- a/drivers/net/vdev_netvsc/rte_pmd_vdev_netvsc_version.map
+++ b/drivers/net/vdev_netvsc/rte_pmd_vdev_netvsc_version.map
@@ -1,4 +1,3 @@
-DPDK_18.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/vhost/rte_pmd_vhost_version.map b/drivers/net/vhost/rte_pmd_vhost_version.map
index 695db85749..16b591ccc4 100644
--- a/drivers/net/vhost/rte_pmd_vhost_version.map
+++ b/drivers/net/vhost/rte_pmd_vhost_version.map
@@ -1,13 +1,8 @@
-DPDK_16.04 {
+DPDK_20.0 {
global:
rte_eth_vhost_get_queue_event;
-
- local: *;
-};
-
-DPDK_16.11 {
- global:
-
rte_eth_vhost_get_vid_from_port_id;
+
+ local: *;
};
diff --git a/drivers/net/virtio/rte_pmd_virtio_version.map b/drivers/net/virtio/rte_pmd_virtio_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/virtio/rte_pmd_virtio_version.map
+++ b/drivers/net/virtio/rte_pmd_virtio_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/vmxnet3/rte_pmd_vmxnet3_version.map b/drivers/net/vmxnet3/rte_pmd_vmxnet3_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/vmxnet3/rte_pmd_vmxnet3_version.map
+++ b/drivers/net/vmxnet3/rte_pmd_vmxnet3_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map b/drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map
index 9b9ab1a4cf..f9f17e4f6e 100644
--- a/drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map
+++ b/drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map
@@ -1,4 +1,3 @@
-DPDK_18.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map b/drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map
index d16a136fc8..ca6a0d7626 100644
--- a/drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map
+++ b/drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map
@@ -1,4 +1,4 @@
-DPDK_19.05 {
+DPDK_20.0 {
global:
rte_qdma_attr_get;
@@ -9,9 +9,9 @@ DPDK_19.05 {
rte_qdma_start;
rte_qdma_stop;
rte_qdma_vq_create;
- rte_qdma_vq_destroy;
rte_qdma_vq_dequeue;
rte_qdma_vq_dequeue_multi;
+ rte_qdma_vq_destroy;
rte_qdma_vq_enqueue;
rte_qdma_vq_enqueue_multi;
rte_qdma_vq_stats;
diff --git a/drivers/raw/ifpga/rte_rawdev_ifpga_version.map b/drivers/raw/ifpga/rte_rawdev_ifpga_version.map
index 9b9ab1a4cf..f9f17e4f6e 100644
--- a/drivers/raw/ifpga/rte_rawdev_ifpga_version.map
+++ b/drivers/raw/ifpga/rte_rawdev_ifpga_version.map
@@ -1,4 +1,3 @@
-DPDK_18.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/raw/ioat/rte_rawdev_ioat_version.map b/drivers/raw/ioat/rte_rawdev_ioat_version.map
index 9a61188cd5..f9f17e4f6e 100644
--- a/drivers/raw/ioat/rte_rawdev_ioat_version.map
+++ b/drivers/raw/ioat/rte_rawdev_ioat_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/raw/ntb/rte_rawdev_ntb_version.map b/drivers/raw/ntb/rte_rawdev_ntb_version.map
index 8861484fb3..f9f17e4f6e 100644
--- a/drivers/raw/ntb/rte_rawdev_ntb_version.map
+++ b/drivers/raw/ntb/rte_rawdev_ntb_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
-
- local: *;
+DPDK_20.0 {
+ local: *;
};
diff --git a/drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map b/drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map
index 9a61188cd5..f9f17e4f6e 100644
--- a/drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map
+++ b/drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/raw/skeleton/rte_rawdev_skeleton_version.map b/drivers/raw/skeleton/rte_rawdev_skeleton_version.map
index 179140fb87..f9f17e4f6e 100644
--- a/drivers/raw/skeleton/rte_rawdev_skeleton_version.map
+++ b/drivers/raw/skeleton/rte_rawdev_skeleton_version.map
@@ -1,4 +1,3 @@
-DPDK_18.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/lib/librte_acl/rte_acl_version.map b/lib/librte_acl/rte_acl_version.map
index b09370a104..c3daca8115 100644
--- a/lib/librte_acl/rte_acl_version.map
+++ b/lib/librte_acl/rte_acl_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_acl_add_rules;
diff --git a/lib/librte_bitratestats/rte_bitratestats_version.map b/lib/librte_bitratestats/rte_bitratestats_version.map
index fe7454452d..88fc2912db 100644
--- a/lib/librte_bitratestats/rte_bitratestats_version.map
+++ b/lib/librte_bitratestats/rte_bitratestats_version.map
@@ -1,4 +1,4 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
rte_stats_bitrate_calc;
diff --git a/lib/librte_cfgfile/rte_cfgfile_version.map b/lib/librte_cfgfile/rte_cfgfile_version.map
index a0a11cea8d..906eee96bf 100644
--- a/lib/librte_cfgfile/rte_cfgfile_version.map
+++ b/lib/librte_cfgfile/rte_cfgfile_version.map
@@ -1,40 +1,22 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
+ rte_cfgfile_add_entry;
+ rte_cfgfile_add_section;
rte_cfgfile_close;
+ rte_cfgfile_create;
rte_cfgfile_get_entry;
rte_cfgfile_has_entry;
rte_cfgfile_has_section;
rte_cfgfile_load;
+ rte_cfgfile_load_with_params;
rte_cfgfile_num_sections;
+ rte_cfgfile_save;
rte_cfgfile_section_entries;
+ rte_cfgfile_section_entries_by_index;
rte_cfgfile_section_num_entries;
rte_cfgfile_sections;
+ rte_cfgfile_set_entry;
local: *;
};
-
-DPDK_16.04 {
- global:
-
- rte_cfgfile_section_entries_by_index;
-
-} DPDK_2.0;
-
-DPDK_17.05 {
- global:
-
- rte_cfgfile_load_with_params;
-
-} DPDK_16.04;
-
-DPDK_17.11 {
- global:
-
- rte_cfgfile_add_entry;
- rte_cfgfile_add_section;
- rte_cfgfile_create;
- rte_cfgfile_save;
- rte_cfgfile_set_entry;
-
-} DPDK_17.05;
diff --git a/lib/librte_cmdline/rte_cmdline_version.map b/lib/librte_cmdline/rte_cmdline_version.map
index 04bcb387f2..95fce812ff 100644
--- a/lib/librte_cmdline/rte_cmdline_version.map
+++ b/lib/librte_cmdline/rte_cmdline_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
cirbuf_add_buf_head;
@@ -40,6 +40,7 @@ DPDK_2.0 {
cmdline_parse_num;
cmdline_parse_portlist;
cmdline_parse_string;
+ cmdline_poll;
cmdline_printf;
cmdline_quit;
cmdline_set_prompt;
@@ -68,10 +69,3 @@ DPDK_2.0 {
local: *;
};
-
-DPDK_2.1 {
- global:
-
- cmdline_poll;
-
-} DPDK_2.0;
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map b/lib/librte_cryptodev/rte_cryptodev_version.map
index 3deb265ac2..1dd1e259a0 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -1,92 +1,62 @@
-DPDK_16.04 {
+DPDK_20.0 {
global:
- rte_cryptodevs;
+ rte_crypto_aead_algorithm_strings;
+ rte_crypto_aead_operation_strings;
+ rte_crypto_auth_algorithm_strings;
+ rte_crypto_auth_operation_strings;
+ rte_crypto_cipher_algorithm_strings;
+ rte_crypto_cipher_operation_strings;
+ rte_crypto_op_pool_create;
+ rte_cryptodev_allocate_driver;
rte_cryptodev_callback_register;
rte_cryptodev_callback_unregister;
rte_cryptodev_close;
- rte_cryptodev_count;
rte_cryptodev_configure;
+ rte_cryptodev_count;
+ rte_cryptodev_device_count_by_driver;
+ rte_cryptodev_devices_get;
+ rte_cryptodev_driver_id_get;
+ rte_cryptodev_driver_name_get;
+ rte_cryptodev_get_aead_algo_enum;
+ rte_cryptodev_get_auth_algo_enum;
+ rte_cryptodev_get_cipher_algo_enum;
rte_cryptodev_get_dev_id;
rte_cryptodev_get_feature_name;
+ rte_cryptodev_get_sec_ctx;
rte_cryptodev_info_get;
+ rte_cryptodev_name_get;
rte_cryptodev_pmd_allocate;
rte_cryptodev_pmd_callback_process;
+ rte_cryptodev_pmd_create;
+ rte_cryptodev_pmd_create_dev_name;
+ rte_cryptodev_pmd_destroy;
+ rte_cryptodev_pmd_get_dev;
+ rte_cryptodev_pmd_get_named_dev;
+ rte_cryptodev_pmd_is_valid_dev;
+ rte_cryptodev_pmd_parse_input_args;
rte_cryptodev_pmd_release_device;
- rte_cryptodev_sym_session_create;
- rte_cryptodev_sym_session_free;
+ rte_cryptodev_queue_pair_count;
+ rte_cryptodev_queue_pair_setup;
rte_cryptodev_socket_id;
rte_cryptodev_start;
rte_cryptodev_stats_get;
rte_cryptodev_stats_reset;
rte_cryptodev_stop;
- rte_cryptodev_queue_pair_count;
- rte_cryptodev_queue_pair_setup;
- rte_crypto_op_pool_create;
-
- local: *;
-};
-
-DPDK_17.02 {
- global:
-
- rte_cryptodev_devices_get;
- rte_cryptodev_pmd_create_dev_name;
- rte_cryptodev_pmd_get_dev;
- rte_cryptodev_pmd_get_named_dev;
- rte_cryptodev_pmd_is_valid_dev;
+ rte_cryptodev_sym_capability_check_aead;
rte_cryptodev_sym_capability_check_auth;
rte_cryptodev_sym_capability_check_cipher;
rte_cryptodev_sym_capability_get;
- rte_crypto_auth_algorithm_strings;
- rte_crypto_auth_operation_strings;
- rte_crypto_cipher_algorithm_strings;
- rte_crypto_cipher_operation_strings;
-
-} DPDK_16.04;
-
-DPDK_17.05 {
- global:
-
- rte_cryptodev_get_auth_algo_enum;
- rte_cryptodev_get_cipher_algo_enum;
-
-} DPDK_17.02;
-
-DPDK_17.08 {
- global:
-
- rte_cryptodev_allocate_driver;
- rte_cryptodev_device_count_by_driver;
- rte_cryptodev_driver_id_get;
- rte_cryptodev_driver_name_get;
- rte_cryptodev_get_aead_algo_enum;
- rte_cryptodev_sym_capability_check_aead;
- rte_cryptodev_sym_session_init;
- rte_cryptodev_sym_session_clear;
- rte_crypto_aead_algorithm_strings;
- rte_crypto_aead_operation_strings;
-
-} DPDK_17.05;
-
-DPDK_17.11 {
- global:
-
- rte_cryptodev_get_sec_ctx;
- rte_cryptodev_name_get;
- rte_cryptodev_pmd_create;
- rte_cryptodev_pmd_destroy;
- rte_cryptodev_pmd_parse_input_args;
-
-} DPDK_17.08;
-
-DPDK_18.05 {
- global:
-
rte_cryptodev_sym_get_header_session_size;
rte_cryptodev_sym_get_private_session_size;
+ rte_cryptodev_sym_session_clear;
+ rte_cryptodev_sym_session_create;
+ rte_cryptodev_sym_session_free;
+ rte_cryptodev_sym_session_init;
+ rte_cryptodevs;
-} DPDK_17.11;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_distributor/rte_distributor_version.map b/lib/librte_distributor/rte_distributor_version.map
index 00e26b4804..1b7c643005 100644
--- a/lib/librte_distributor/rte_distributor_version.map
+++ b/lib/librte_distributor/rte_distributor_version.map
@@ -1,4 +1,4 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
rte_distributor_clear_returns;
@@ -10,4 +10,6 @@ DPDK_17.05 {
rte_distributor_request_pkt;
rte_distributor_return_pkt;
rte_distributor_returned_pkts;
+
+ local: *;
};
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index f1982f2f73..8663517df3 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
__rte_panic;
@@ -6,44 +6,113 @@ DPDK_2.0 {
eal_timer_source;
per_lcore__lcore_id;
per_lcore__rte_errno;
+ rte_bus_dump;
+ rte_bus_find;
+ rte_bus_find_by_device;
+ rte_bus_find_by_name;
+ rte_bus_get_iommu_class;
+ rte_bus_probe;
+ rte_bus_register;
+ rte_bus_scan;
+ rte_bus_unregister;
rte_calloc;
rte_calloc_socket;
rte_cpu_get_flag_enabled;
+ rte_cpu_get_flag_name;
+ rte_cpu_is_supported;
+ rte_ctrl_thread_create;
rte_cycles_vmware_tsc_map;
rte_delay_us;
+ rte_delay_us_block;
+ rte_delay_us_callback_register;
+ rte_dev_is_probed;
+ rte_dev_probe;
+ rte_dev_remove;
+ rte_devargs_add;
+ rte_devargs_dump;
+ rte_devargs_insert;
+ rte_devargs_next;
+ rte_devargs_parse;
+ rte_devargs_parsef;
+ rte_devargs_remove;
+ rte_devargs_type_count;
rte_dump_physmem_layout;
rte_dump_registers;
rte_dump_stack;
rte_dump_tailq;
rte_eal_alarm_cancel;
rte_eal_alarm_set;
+ rte_eal_cleanup;
+ rte_eal_create_uio_dev;
rte_eal_get_lcore_state;
rte_eal_get_physmem_size;
+ rte_eal_get_runtime_dir;
rte_eal_has_hugepages;
+ rte_eal_has_pci;
+ rte_eal_hotplug_add;
+ rte_eal_hotplug_remove;
rte_eal_hpet_init;
rte_eal_init;
rte_eal_iopl_init;
+ rte_eal_iova_mode;
rte_eal_lcore_role;
+ rte_eal_mbuf_user_pool_ops;
rte_eal_mp_remote_launch;
rte_eal_mp_wait_lcore;
+ rte_eal_primary_proc_alive;
rte_eal_process_type;
rte_eal_remote_launch;
rte_eal_tailq_lookup;
rte_eal_tailq_register;
+ rte_eal_using_phys_addrs;
+ rte_eal_vfio_intr_mode;
rte_eal_wait_lcore;
+ rte_epoll_ctl;
+ rte_epoll_wait;
rte_exit;
rte_free;
rte_get_hpet_cycles;
rte_get_hpet_hz;
+ rte_get_master_lcore;
+ rte_get_next_lcore;
rte_get_tsc_hz;
rte_hexdump;
+ rte_hypervisor_get;
+ rte_hypervisor_get_name;
+ rte_intr_allow_others;
rte_intr_callback_register;
rte_intr_callback_unregister;
+ rte_intr_cap_multiple;
rte_intr_disable;
+ rte_intr_dp_is_en;
+ rte_intr_efd_disable;
+ rte_intr_efd_enable;
rte_intr_enable;
+ rte_intr_free_epoll_fd;
+ rte_intr_rx_ctl;
+ rte_intr_tls_epfd;
+ rte_keepalive_create;
+ rte_keepalive_dispatch_pings;
+ rte_keepalive_mark_alive;
+ rte_keepalive_mark_sleep;
+ rte_keepalive_register_core;
+ rte_keepalive_register_relay_callback;
+ rte_lcore_count;
+ rte_lcore_has_role;
+ rte_lcore_index;
+ rte_lcore_is_enabled;
+ rte_lcore_to_socket_id;
rte_log;
rte_log_cur_msg_loglevel;
rte_log_cur_msg_logtype;
+ rte_log_dump;
+ rte_log_get_global_level;
+ rte_log_get_level;
+ rte_log_register;
+ rte_log_set_global_level;
+ rte_log_set_level;
+ rte_log_set_level_pattern;
+ rte_log_set_level_regexp;
rte_logs;
rte_malloc;
rte_malloc_dump_stats;
@@ -51,155 +120,38 @@ DPDK_2.0 {
rte_malloc_set_limit;
rte_malloc_socket;
rte_malloc_validate;
+ rte_malloc_virt2iova;
+ rte_mcfg_mem_read_lock;
+ rte_mcfg_mem_read_unlock;
+ rte_mcfg_mem_write_lock;
+ rte_mcfg_mem_write_unlock;
+ rte_mcfg_mempool_read_lock;
+ rte_mcfg_mempool_read_unlock;
+ rte_mcfg_mempool_write_lock;
+ rte_mcfg_mempool_write_unlock;
+ rte_mcfg_tailq_read_lock;
+ rte_mcfg_tailq_read_unlock;
+ rte_mcfg_tailq_write_lock;
+ rte_mcfg_tailq_write_unlock;
rte_mem_lock_page;
+ rte_mem_virt2iova;
rte_mem_virt2phy;
rte_memdump;
rte_memory_get_nchannel;
rte_memory_get_nrank;
rte_memzone_dump;
+ rte_memzone_free;
rte_memzone_lookup;
rte_memzone_reserve;
rte_memzone_reserve_aligned;
rte_memzone_reserve_bounded;
rte_memzone_walk;
rte_openlog_stream;
+ rte_rand;
rte_realloc;
- rte_set_application_usage_hook;
- rte_socket_id;
- rte_strerror;
- rte_strsplit;
- rte_sys_gettid;
- rte_thread_get_affinity;
- rte_thread_set_affinity;
- rte_vlog;
- rte_zmalloc;
- rte_zmalloc_socket;
-
- local: *;
-};
-
-DPDK_2.1 {
- global:
-
- rte_epoll_ctl;
- rte_epoll_wait;
- rte_intr_allow_others;
- rte_intr_dp_is_en;
- rte_intr_efd_disable;
- rte_intr_efd_enable;
- rte_intr_rx_ctl;
- rte_intr_tls_epfd;
- rte_memzone_free;
-
-} DPDK_2.0;
-
-DPDK_2.2 {
- global:
-
- rte_intr_cap_multiple;
- rte_keepalive_create;
- rte_keepalive_dispatch_pings;
- rte_keepalive_mark_alive;
- rte_keepalive_register_core;
-
-} DPDK_2.1;
-
-DPDK_16.04 {
- global:
-
- rte_cpu_get_flag_name;
- rte_eal_primary_proc_alive;
-
-} DPDK_2.2;
-
-DPDK_16.07 {
- global:
-
- rte_keepalive_mark_sleep;
- rte_keepalive_register_relay_callback;
- rte_rtm_supported;
- rte_thread_setname;
-
-} DPDK_16.04;
-
-DPDK_16.11 {
- global:
-
- rte_delay_us_block;
- rte_delay_us_callback_register;
-
-} DPDK_16.07;
-
-DPDK_17.02 {
- global:
-
- rte_bus_dump;
- rte_bus_probe;
- rte_bus_register;
- rte_bus_scan;
- rte_bus_unregister;
-
-} DPDK_16.11;
-
-DPDK_17.05 {
- global:
-
- rte_cpu_is_supported;
- rte_intr_free_epoll_fd;
- rte_log_dump;
- rte_log_get_global_level;
- rte_log_register;
- rte_log_set_global_level;
- rte_log_set_level;
- rte_log_set_level_regexp;
-
-} DPDK_17.02;
-
-DPDK_17.08 {
- global:
-
- rte_bus_find;
- rte_bus_find_by_device;
- rte_bus_find_by_name;
- rte_log_get_level;
-
-} DPDK_17.05;
-
-DPDK_17.11 {
- global:
-
- rte_eal_create_uio_dev;
- rte_bus_get_iommu_class;
- rte_eal_has_pci;
- rte_eal_iova_mode;
- rte_eal_using_phys_addrs;
- rte_eal_vfio_intr_mode;
- rte_lcore_has_role;
- rte_malloc_virt2iova;
- rte_mem_virt2iova;
- rte_vfio_enable;
- rte_vfio_is_enabled;
- rte_vfio_noiommu_is_enabled;
- rte_vfio_release_device;
- rte_vfio_setup_device;
-
-} DPDK_17.08;
-
-DPDK_18.02 {
- global:
-
- rte_hypervisor_get;
- rte_hypervisor_get_name;
- rte_vfio_clear_group;
rte_reciprocal_value;
rte_reciprocal_value_u64;
-
-} DPDK_17.11;
-
-DPDK_18.05 {
- global:
-
- rte_log_set_level_pattern;
+ rte_rtm_supported;
rte_service_attr_get;
rte_service_attr_reset_all;
rte_service_component_register;
@@ -212,6 +164,8 @@ DPDK_18.05 {
rte_service_get_count;
rte_service_get_name;
rte_service_lcore_add;
+ rte_service_lcore_attr_get;
+ rte_service_lcore_attr_reset_all;
rte_service_lcore_count;
rte_service_lcore_count_services;
rte_service_lcore_del;
@@ -221,6 +175,7 @@ DPDK_18.05 {
rte_service_lcore_stop;
rte_service_map_lcore_get;
rte_service_map_lcore_set;
+ rte_service_may_be_active;
rte_service_probe_capability;
rte_service_run_iter_on_app_lcore;
rte_service_runstate_get;
@@ -228,94 +183,43 @@ DPDK_18.05 {
rte_service_set_runstate_mapped_check;
rte_service_set_stats_enable;
rte_service_start_with_defaults;
-
-} DPDK_18.02;
-
-DPDK_18.08 {
- global:
-
- rte_eal_mbuf_user_pool_ops;
+ rte_set_application_usage_hook;
+ rte_socket_count;
+ rte_socket_id;
+ rte_socket_id_by_idx;
+ rte_srand;
+ rte_strerror;
+ rte_strscpy;
+ rte_strsplit;
+ rte_sys_gettid;
+ rte_thread_get_affinity;
+ rte_thread_set_affinity;
+ rte_thread_setname;
rte_uuid_compare;
rte_uuid_is_null;
rte_uuid_parse;
rte_uuid_unparse;
+ rte_vfio_clear_group;
rte_vfio_container_create;
rte_vfio_container_destroy;
rte_vfio_container_dma_map;
rte_vfio_container_dma_unmap;
rte_vfio_container_group_bind;
rte_vfio_container_group_unbind;
+ rte_vfio_enable;
rte_vfio_get_container_fd;
rte_vfio_get_group_fd;
rte_vfio_get_group_num;
-
-} DPDK_18.05;
-
-DPDK_18.11 {
- global:
-
- rte_dev_probe;
- rte_dev_remove;
- rte_eal_get_runtime_dir;
- rte_eal_hotplug_add;
- rte_eal_hotplug_remove;
- rte_strscpy;
-
-} DPDK_18.08;
-
-DPDK_19.05 {
- global:
-
- rte_ctrl_thread_create;
- rte_dev_is_probed;
- rte_devargs_add;
- rte_devargs_dump;
- rte_devargs_insert;
- rte_devargs_next;
- rte_devargs_parse;
- rte_devargs_parsef;
- rte_devargs_remove;
- rte_devargs_type_count;
- rte_eal_cleanup;
- rte_socket_count;
- rte_socket_id_by_idx;
-
-} DPDK_18.11;
-
-DPDK_19.08 {
- global:
-
- rte_lcore_index;
- rte_lcore_to_socket_id;
- rte_mcfg_mem_read_lock;
- rte_mcfg_mem_read_unlock;
- rte_mcfg_mem_write_lock;
- rte_mcfg_mem_write_unlock;
- rte_mcfg_mempool_read_lock;
- rte_mcfg_mempool_read_unlock;
- rte_mcfg_mempool_write_lock;
- rte_mcfg_mempool_write_unlock;
- rte_mcfg_tailq_read_lock;
- rte_mcfg_tailq_read_unlock;
- rte_mcfg_tailq_write_lock;
- rte_mcfg_tailq_write_unlock;
- rte_rand;
- rte_service_lcore_attr_get;
- rte_service_lcore_attr_reset_all;
- rte_service_may_be_active;
- rte_srand;
-
-} DPDK_19.05;
-
-DPDK_19.11 {
- global:
-
- rte_get_master_lcore;
- rte_get_next_lcore;
- rte_lcore_count;
- rte_lcore_is_enabled;
-
-} DPDK_19.08;
+ rte_vfio_is_enabled;
+ rte_vfio_noiommu_is_enabled;
+ rte_vfio_release_device;
+ rte_vfio_setup_device;
+ rte_vlog;
+ rte_zmalloc;
+ rte_zmalloc_socket;
+
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_efd/rte_efd_version.map b/lib/librte_efd/rte_efd_version.map
index ae60a64178..e010eecfe4 100644
--- a/lib/librte_efd/rte_efd_version.map
+++ b/lib/librte_efd/rte_efd_version.map
@@ -1,4 +1,4 @@
-DPDK_17.02 {
+DPDK_20.0 {
global:
rte_efd_create;
diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
index e59d51648f..28819c1bb7 100644
--- a/lib/librte_ethdev/rte_ethdev_version.map
+++ b/lib/librte_ethdev/rte_ethdev_version.map
@@ -1,35 +1,53 @@
-DPDK_2.2 {
+DPDK_20.0 {
global:
+ _rte_eth_dev_callback_process;
+ _rte_eth_dev_reset;
+ rte_eth_add_first_rx_callback;
rte_eth_add_rx_callback;
rte_eth_add_tx_callback;
rte_eth_allmulticast_disable;
rte_eth_allmulticast_enable;
rte_eth_allmulticast_get;
+ rte_eth_dev_adjust_nb_rx_tx_desc;
rte_eth_dev_allocate;
rte_eth_dev_allocated;
+ rte_eth_dev_attach_secondary;
rte_eth_dev_callback_register;
rte_eth_dev_callback_unregister;
rte_eth_dev_close;
rte_eth_dev_configure;
rte_eth_dev_count;
+ rte_eth_dev_count_avail;
+ rte_eth_dev_count_total;
rte_eth_dev_default_mac_addr_set;
+ rte_eth_dev_filter_ctrl;
rte_eth_dev_filter_supported;
rte_eth_dev_flow_ctrl_get;
rte_eth_dev_flow_ctrl_set;
+ rte_eth_dev_fw_version_get;
rte_eth_dev_get_dcb_info;
rte_eth_dev_get_eeprom;
rte_eth_dev_get_eeprom_length;
rte_eth_dev_get_mtu;
+ rte_eth_dev_get_name_by_port;
+ rte_eth_dev_get_port_by_name;
rte_eth_dev_get_reg_info;
+ rte_eth_dev_get_sec_ctx;
+ rte_eth_dev_get_supported_ptypes;
rte_eth_dev_get_vlan_offload;
- rte_eth_devices;
rte_eth_dev_info_get;
rte_eth_dev_is_valid_port;
+ rte_eth_dev_l2_tunnel_eth_type_conf;
+ rte_eth_dev_l2_tunnel_offload_set;
+ rte_eth_dev_logtype;
rte_eth_dev_mac_addr_add;
rte_eth_dev_mac_addr_remove;
+ rte_eth_dev_pool_ops_supported;
rte_eth_dev_priority_flow_ctrl_set;
+ rte_eth_dev_probing_finish;
rte_eth_dev_release_port;
+ rte_eth_dev_reset;
rte_eth_dev_rss_hash_conf_get;
rte_eth_dev_rss_hash_update;
rte_eth_dev_rss_reta_query;
@@ -38,6 +56,7 @@ DPDK_2.2 {
rte_eth_dev_rx_intr_ctl_q;
rte_eth_dev_rx_intr_disable;
rte_eth_dev_rx_intr_enable;
+ rte_eth_dev_rx_offload_name;
rte_eth_dev_rx_queue_start;
rte_eth_dev_rx_queue_stop;
rte_eth_dev_set_eeprom;
@@ -47,18 +66,28 @@ DPDK_2.2 {
rte_eth_dev_set_mtu;
rte_eth_dev_set_rx_queue_stats_mapping;
rte_eth_dev_set_tx_queue_stats_mapping;
+ rte_eth_dev_set_vlan_ether_type;
rte_eth_dev_set_vlan_offload;
rte_eth_dev_set_vlan_pvid;
rte_eth_dev_set_vlan_strip_on_queue;
rte_eth_dev_socket_id;
rte_eth_dev_start;
rte_eth_dev_stop;
+ rte_eth_dev_tx_offload_name;
rte_eth_dev_tx_queue_start;
rte_eth_dev_tx_queue_stop;
rte_eth_dev_uc_all_hash_table_set;
rte_eth_dev_uc_hash_table_set;
+ rte_eth_dev_udp_tunnel_port_add;
+ rte_eth_dev_udp_tunnel_port_delete;
rte_eth_dev_vlan_filter;
+ rte_eth_devices;
rte_eth_dma_zone_reserve;
+ rte_eth_find_next;
+ rte_eth_find_next_owned_by;
+ rte_eth_iterator_cleanup;
+ rte_eth_iterator_init;
+ rte_eth_iterator_next;
rte_eth_led_off;
rte_eth_led_on;
rte_eth_link;
@@ -75,6 +104,7 @@ DPDK_2.2 {
rte_eth_rx_queue_info_get;
rte_eth_rx_queue_setup;
rte_eth_set_queue_rate_limit;
+ rte_eth_speed_bitflag;
rte_eth_stats;
rte_eth_stats_get;
rte_eth_stats_reset;
@@ -85,66 +115,27 @@ DPDK_2.2 {
rte_eth_timesync_read_time;
rte_eth_timesync_read_tx_timestamp;
rte_eth_timesync_write_time;
- rte_eth_tx_queue_info_get;
- rte_eth_tx_queue_setup;
- rte_eth_xstats_get;
- rte_eth_xstats_reset;
-
- local: *;
-};
-
-DPDK_16.04 {
- global:
-
- rte_eth_dev_get_supported_ptypes;
- rte_eth_dev_l2_tunnel_eth_type_conf;
- rte_eth_dev_l2_tunnel_offload_set;
- rte_eth_dev_set_vlan_ether_type;
- rte_eth_dev_udp_tunnel_port_add;
- rte_eth_dev_udp_tunnel_port_delete;
- rte_eth_speed_bitflag;
rte_eth_tx_buffer_count_callback;
rte_eth_tx_buffer_drop_callback;
rte_eth_tx_buffer_init;
rte_eth_tx_buffer_set_err_callback;
-
-} DPDK_2.2;
-
-DPDK_16.07 {
- global:
-
- rte_eth_add_first_rx_callback;
- rte_eth_dev_get_name_by_port;
- rte_eth_dev_get_port_by_name;
- rte_eth_xstats_get_names;
-
-} DPDK_16.04;
-
-DPDK_17.02 {
- global:
-
- _rte_eth_dev_reset;
- rte_eth_dev_fw_version_get;
-
-} DPDK_16.07;
-
-DPDK_17.05 {
- global:
-
- rte_eth_dev_attach_secondary;
- rte_eth_find_next;
rte_eth_tx_done_cleanup;
+ rte_eth_tx_queue_info_get;
+ rte_eth_tx_queue_setup;
+ rte_eth_xstats_get;
rte_eth_xstats_get_by_id;
rte_eth_xstats_get_id_by_name;
+ rte_eth_xstats_get_names;
rte_eth_xstats_get_names_by_id;
-
-} DPDK_17.02;
-
-DPDK_17.08 {
- global:
-
- _rte_eth_dev_callback_process;
- rte_eth_dev_adjust_nb_rx_tx_desc;
+ rte_eth_xstats_reset;
+ rte_flow_copy;
+ rte_flow_create;
+ rte_flow_destroy;
+ rte_flow_error_set;
+ rte_flow_flush;
+ rte_flow_isolate;
+ rte_flow_query;
+ rte_flow_validate;
rte_tm_capabilities_get;
rte_tm_get_number_of_leaf_nodes;
rte_tm_hierarchy_commit;
@@ -176,65 +167,8 @@ DPDK_17.08 {
rte_tm_wred_profile_add;
rte_tm_wred_profile_delete;
-} DPDK_17.05;
-
-DPDK_17.11 {
- global:
-
- rte_eth_dev_get_sec_ctx;
- rte_eth_dev_pool_ops_supported;
- rte_eth_dev_reset;
-
-} DPDK_17.08;
-
-DPDK_18.02 {
- global:
-
- rte_eth_dev_filter_ctrl;
-
-} DPDK_17.11;
-
-DPDK_18.05 {
- global:
-
- rte_eth_dev_count_avail;
- rte_eth_dev_probing_finish;
- rte_eth_find_next_owned_by;
- rte_flow_copy;
- rte_flow_create;
- rte_flow_destroy;
- rte_flow_error_set;
- rte_flow_flush;
- rte_flow_isolate;
- rte_flow_query;
- rte_flow_validate;
-
-} DPDK_18.02;
-
-DPDK_18.08 {
- global:
-
- rte_eth_dev_logtype;
-
-} DPDK_18.05;
-
-DPDK_18.11 {
- global:
-
- rte_eth_dev_rx_offload_name;
- rte_eth_dev_tx_offload_name;
- rte_eth_iterator_cleanup;
- rte_eth_iterator_init;
- rte_eth_iterator_next;
-
-} DPDK_18.08;
-
-DPDK_19.05 {
- global:
-
- rte_eth_dev_count_total;
-
-} DPDK_18.11;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_eventdev/rte_eventdev_version.map b/lib/librte_eventdev/rte_eventdev_version.map
index 76b3021d3a..edfc15282d 100644
--- a/lib/librte_eventdev/rte_eventdev_version.map
+++ b/lib/librte_eventdev/rte_eventdev_version.map
@@ -1,61 +1,38 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
- rte_eventdevs;
-
+ rte_event_crypto_adapter_caps_get;
+ rte_event_crypto_adapter_create;
+ rte_event_crypto_adapter_create_ext;
+ rte_event_crypto_adapter_event_port_get;
+ rte_event_crypto_adapter_free;
+ rte_event_crypto_adapter_queue_pair_add;
+ rte_event_crypto_adapter_queue_pair_del;
+ rte_event_crypto_adapter_service_id_get;
+ rte_event_crypto_adapter_start;
+ rte_event_crypto_adapter_stats_get;
+ rte_event_crypto_adapter_stats_reset;
+ rte_event_crypto_adapter_stop;
+ rte_event_dequeue_timeout_ticks;
+ rte_event_dev_attr_get;
+ rte_event_dev_close;
+ rte_event_dev_configure;
rte_event_dev_count;
+ rte_event_dev_dump;
rte_event_dev_get_dev_id;
- rte_event_dev_socket_id;
rte_event_dev_info_get;
- rte_event_dev_configure;
+ rte_event_dev_selftest;
+ rte_event_dev_service_id_get;
+ rte_event_dev_socket_id;
rte_event_dev_start;
rte_event_dev_stop;
- rte_event_dev_close;
- rte_event_dev_dump;
+ rte_event_dev_stop_flush_callback_register;
rte_event_dev_xstats_by_name_get;
rte_event_dev_xstats_get;
rte_event_dev_xstats_names_get;
rte_event_dev_xstats_reset;
-
- rte_event_port_default_conf_get;
- rte_event_port_setup;
- rte_event_port_link;
- rte_event_port_unlink;
- rte_event_port_links_get;
-
- rte_event_queue_default_conf_get;
- rte_event_queue_setup;
-
- rte_event_dequeue_timeout_ticks;
-
- rte_event_pmd_allocate;
- rte_event_pmd_release;
- rte_event_pmd_vdev_init;
- rte_event_pmd_vdev_uninit;
- rte_event_pmd_pci_probe;
- rte_event_pmd_pci_remove;
-
- local: *;
-};
-
-DPDK_17.08 {
- global:
-
- rte_event_ring_create;
- rte_event_ring_free;
- rte_event_ring_init;
- rte_event_ring_lookup;
-} DPDK_17.05;
-
-DPDK_17.11 {
- global:
-
- rte_event_dev_attr_get;
- rte_event_dev_service_id_get;
- rte_event_port_attr_get;
- rte_event_queue_attr_get;
-
rte_event_eth_rx_adapter_caps_get;
+ rte_event_eth_rx_adapter_cb_register;
rte_event_eth_rx_adapter_create;
rte_event_eth_rx_adapter_create_ext;
rte_event_eth_rx_adapter_free;
@@ -63,38 +40,9 @@ DPDK_17.11 {
rte_event_eth_rx_adapter_queue_del;
rte_event_eth_rx_adapter_service_id_get;
rte_event_eth_rx_adapter_start;
+ rte_event_eth_rx_adapter_stats_get;
rte_event_eth_rx_adapter_stats_reset;
rte_event_eth_rx_adapter_stop;
-} DPDK_17.08;
-
-DPDK_18.02 {
- global:
-
- rte_event_dev_selftest;
-} DPDK_17.11;
-
-DPDK_18.05 {
- global:
-
- rte_event_dev_stop_flush_callback_register;
-} DPDK_18.02;
-
-DPDK_19.05 {
- global:
-
- rte_event_crypto_adapter_caps_get;
- rte_event_crypto_adapter_create;
- rte_event_crypto_adapter_create_ext;
- rte_event_crypto_adapter_event_port_get;
- rte_event_crypto_adapter_free;
- rte_event_crypto_adapter_queue_pair_add;
- rte_event_crypto_adapter_queue_pair_del;
- rte_event_crypto_adapter_service_id_get;
- rte_event_crypto_adapter_start;
- rte_event_crypto_adapter_stats_get;
- rte_event_crypto_adapter_stats_reset;
- rte_event_crypto_adapter_stop;
- rte_event_port_unlinks_in_progress;
rte_event_eth_tx_adapter_caps_get;
rte_event_eth_tx_adapter_create;
rte_event_eth_tx_adapter_create_ext;
@@ -107,6 +55,26 @@ DPDK_19.05 {
rte_event_eth_tx_adapter_stats_get;
rte_event_eth_tx_adapter_stats_reset;
rte_event_eth_tx_adapter_stop;
+ rte_event_pmd_allocate;
+ rte_event_pmd_pci_probe;
+ rte_event_pmd_pci_remove;
+ rte_event_pmd_release;
+ rte_event_pmd_vdev_init;
+ rte_event_pmd_vdev_uninit;
+ rte_event_port_attr_get;
+ rte_event_port_default_conf_get;
+ rte_event_port_link;
+ rte_event_port_links_get;
+ rte_event_port_setup;
+ rte_event_port_unlink;
+ rte_event_port_unlinks_in_progress;
+ rte_event_queue_attr_get;
+ rte_event_queue_default_conf_get;
+ rte_event_queue_setup;
+ rte_event_ring_create;
+ rte_event_ring_free;
+ rte_event_ring_init;
+ rte_event_ring_lookup;
rte_event_timer_adapter_caps_get;
rte_event_timer_adapter_create;
rte_event_timer_adapter_create_ext;
@@ -121,11 +89,7 @@ DPDK_19.05 {
rte_event_timer_arm_burst;
rte_event_timer_arm_tmo_tick_burst;
rte_event_timer_cancel_burst;
-} DPDK_18.05;
+ rte_eventdevs;
-DPDK_19.08 {
- global:
-
- rte_event_eth_rx_adapter_cb_register;
- rte_event_eth_rx_adapter_stats_get;
-} DPDK_19.05;
+ local: *;
+};
diff --git a/lib/librte_gro/rte_gro_version.map b/lib/librte_gro/rte_gro_version.map
index 1606b6dc72..9f6fe79e57 100644
--- a/lib/librte_gro/rte_gro_version.map
+++ b/lib/librte_gro/rte_gro_version.map
@@ -1,4 +1,4 @@
-DPDK_17.08 {
+DPDK_20.0 {
global:
rte_gro_ctx_create;
diff --git a/lib/librte_gso/rte_gso_version.map b/lib/librte_gso/rte_gso_version.map
index e1fd453edb..8505a59c27 100644
--- a/lib/librte_gso/rte_gso_version.map
+++ b/lib/librte_gso/rte_gso_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
rte_gso_segment;
diff --git a/lib/librte_hash/rte_hash_version.map b/lib/librte_hash/rte_hash_version.map
index 734ae28b04..138c130c1b 100644
--- a/lib/librte_hash/rte_hash_version.map
+++ b/lib/librte_hash/rte_hash_version.map
@@ -1,58 +1,33 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_fbk_hash_create;
rte_fbk_hash_find_existing;
rte_fbk_hash_free;
rte_hash_add_key;
+ rte_hash_add_key_data;
rte_hash_add_key_with_hash;
+ rte_hash_add_key_with_hash_data;
+ rte_hash_count;
rte_hash_create;
rte_hash_del_key;
rte_hash_del_key_with_hash;
rte_hash_find_existing;
rte_hash_free;
+ rte_hash_get_key_with_position;
rte_hash_hash;
+ rte_hash_iterate;
rte_hash_lookup;
rte_hash_lookup_bulk;
- rte_hash_lookup_with_hash;
-
- local: *;
-};
-
-DPDK_2.1 {
- global:
-
- rte_hash_add_key_data;
- rte_hash_add_key_with_hash_data;
- rte_hash_iterate;
rte_hash_lookup_bulk_data;
rte_hash_lookup_data;
+ rte_hash_lookup_with_hash;
rte_hash_lookup_with_hash_data;
rte_hash_reset;
-
-} DPDK_2.0;
-
-DPDK_2.2 {
- global:
-
rte_hash_set_cmp_func;
-} DPDK_2.1;
-
-DPDK_16.07 {
- global:
-
- rte_hash_get_key_with_position;
-
-} DPDK_2.2;
-
-
-DPDK_18.08 {
- global:
-
- rte_hash_count;
-
-} DPDK_16.07;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_ip_frag/rte_ip_frag_version.map b/lib/librte_ip_frag/rte_ip_frag_version.map
index a193007c61..5dd34f828c 100644
--- a/lib/librte_ip_frag/rte_ip_frag_version.map
+++ b/lib/librte_ip_frag/rte_ip_frag_version.map
@@ -1,8 +1,9 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_ip_frag_free_death_row;
rte_ip_frag_table_create;
+ rte_ip_frag_table_destroy;
rte_ip_frag_table_statistics_dump;
rte_ipv4_frag_reassemble_packet;
rte_ipv4_fragment_packet;
@@ -12,13 +13,6 @@ DPDK_2.0 {
local: *;
};
-DPDK_17.08 {
- global:
-
- rte_ip_frag_table_destroy;
-
-} DPDK_2.0;
-
EXPERIMENTAL {
global:
diff --git a/lib/librte_jobstats/rte_jobstats_version.map b/lib/librte_jobstats/rte_jobstats_version.map
index f89441438e..dbd2664ae2 100644
--- a/lib/librte_jobstats/rte_jobstats_version.map
+++ b/lib/librte_jobstats/rte_jobstats_version.map
@@ -1,6 +1,7 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
+ rte_jobstats_abort;
rte_jobstats_context_finish;
rte_jobstats_context_init;
rte_jobstats_context_reset;
@@ -17,10 +18,3 @@ DPDK_2.0 {
local: *;
};
-
-DPDK_16.04 {
- global:
-
- rte_jobstats_abort;
-
-} DPDK_2.0;
diff --git a/lib/librte_kni/rte_kni_version.map b/lib/librte_kni/rte_kni_version.map
index c877dc6aaa..9cd3cedc54 100644
--- a/lib/librte_kni/rte_kni_version.map
+++ b/lib/librte_kni/rte_kni_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_kni_alloc;
diff --git a/lib/librte_kvargs/rte_kvargs_version.map b/lib/librte_kvargs/rte_kvargs_version.map
index 8f4b4e3f8f..3ba0f4b59c 100644
--- a/lib/librte_kvargs/rte_kvargs_version.map
+++ b/lib/librte_kvargs/rte_kvargs_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_kvargs_count;
@@ -15,4 +15,4 @@ EXPERIMENTAL {
rte_kvargs_parse_delim;
rte_kvargs_strcmp;
-} DPDK_2.0;
+};
diff --git a/lib/librte_latencystats/rte_latencystats_version.map b/lib/librte_latencystats/rte_latencystats_version.map
index ac8403e821..e04e63463f 100644
--- a/lib/librte_latencystats/rte_latencystats_version.map
+++ b/lib/librte_latencystats/rte_latencystats_version.map
@@ -1,4 +1,4 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
rte_latencystats_get;
diff --git a/lib/librte_lpm/rte_lpm_version.map b/lib/librte_lpm/rte_lpm_version.map
index 90beac853d..500f58b806 100644
--- a/lib/librte_lpm/rte_lpm_version.map
+++ b/lib/librte_lpm/rte_lpm_version.map
@@ -1,13 +1,6 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
- rte_lpm_add;
- rte_lpm_create;
- rte_lpm_delete;
- rte_lpm_delete_all;
- rte_lpm_find_existing;
- rte_lpm_free;
- rte_lpm_is_rule_present;
rte_lpm6_add;
rte_lpm6_create;
rte_lpm6_delete;
@@ -18,29 +11,13 @@ DPDK_2.0 {
rte_lpm6_is_rule_present;
rte_lpm6_lookup;
rte_lpm6_lookup_bulk_func;
+ rte_lpm_add;
+ rte_lpm_create;
+ rte_lpm_delete;
+ rte_lpm_delete_all;
+ rte_lpm_find_existing;
+ rte_lpm_free;
+ rte_lpm_is_rule_present;
local: *;
};
-
-DPDK_16.04 {
- global:
-
- rte_lpm_add;
- rte_lpm_find_existing;
- rte_lpm_create;
- rte_lpm_free;
- rte_lpm_is_rule_present;
- rte_lpm_delete;
- rte_lpm_delete_all;
-
-} DPDK_2.0;
-
-DPDK_17.05 {
- global:
-
- rte_lpm6_add;
- rte_lpm6_is_rule_present;
- rte_lpm6_lookup;
- rte_lpm6_lookup_bulk_func;
-
-} DPDK_16.04;
diff --git a/lib/librte_mbuf/rte_mbuf_version.map b/lib/librte_mbuf/rte_mbuf_version.map
index 263dc0a21e..3bbb476975 100644
--- a/lib/librte_mbuf/rte_mbuf_version.map
+++ b/lib/librte_mbuf/rte_mbuf_version.map
@@ -1,26 +1,7 @@
-DPDK_2.0 {
- global:
-
- rte_get_rx_ol_flag_name;
- rte_get_tx_ol_flag_name;
- rte_mbuf_sanity_check;
- rte_pktmbuf_dump;
- rte_pktmbuf_init;
- rte_pktmbuf_pool_init;
-
- local: *;
-};
-
-DPDK_2.1 {
- global:
-
- rte_pktmbuf_pool_create;
-
-} DPDK_2.0;
-
-DPDK_16.11 {
+DPDK_20.0 {
global:
+ __rte_pktmbuf_linearize;
__rte_pktmbuf_read;
rte_get_ptype_inner_l2_name;
rte_get_ptype_inner_l3_name;
@@ -31,28 +12,24 @@ DPDK_16.11 {
rte_get_ptype_name;
rte_get_ptype_tunnel_name;
rte_get_rx_ol_flag_list;
+ rte_get_rx_ol_flag_name;
rte_get_tx_ol_flag_list;
-
-} DPDK_2.1;
-
-DPDK_18.08 {
- global:
-
+ rte_get_tx_ol_flag_name;
rte_mbuf_best_mempool_ops;
rte_mbuf_platform_mempool_ops;
+ rte_mbuf_sanity_check;
rte_mbuf_set_platform_mempool_ops;
rte_mbuf_set_user_mempool_ops;
rte_mbuf_user_mempool_ops;
- rte_pktmbuf_pool_create_by_ops;
-} DPDK_16.11;
-
-DPDK_19.11 {
- global:
-
- __rte_pktmbuf_linearize;
rte_pktmbuf_clone;
+ rte_pktmbuf_dump;
+ rte_pktmbuf_init;
+ rte_pktmbuf_pool_create;
+ rte_pktmbuf_pool_create_by_ops;
+ rte_pktmbuf_pool_init;
-} DPDK_18.08;
+ local: *;
+};
EXPERIMENTAL {
global:
@@ -68,4 +45,4 @@ EXPERIMENTAL {
rte_pktmbuf_copy;
rte_pktmbuf_free_bulk;
-} DPDK_18.08;
+};
diff --git a/lib/librte_member/rte_member_version.map b/lib/librte_member/rte_member_version.map
index 019e4cd962..87780ae611 100644
--- a/lib/librte_member/rte_member_version.map
+++ b/lib/librte_member/rte_member_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
rte_member_add;
diff --git a/lib/librte_mempool/rte_mempool_version.map b/lib/librte_mempool/rte_mempool_version.map
index ce9e791e78..d002dfc46f 100644
--- a/lib/librte_mempool/rte_mempool_version.map
+++ b/lib/librte_mempool/rte_mempool_version.map
@@ -1,57 +1,39 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_mempool_audit;
- rte_mempool_calc_obj_size;
- rte_mempool_create;
- rte_mempool_dump;
- rte_mempool_list_dump;
- rte_mempool_lookup;
- rte_mempool_walk;
-
- local: *;
-};
-
-DPDK_16.07 {
- global:
-
rte_mempool_avail_count;
rte_mempool_cache_create;
rte_mempool_cache_flush;
rte_mempool_cache_free;
+ rte_mempool_calc_obj_size;
rte_mempool_check_cookies;
+ rte_mempool_contig_blocks_check_cookies;
+ rte_mempool_create;
rte_mempool_create_empty;
rte_mempool_default_cache;
+ rte_mempool_dump;
rte_mempool_free;
rte_mempool_generic_get;
rte_mempool_generic_put;
rte_mempool_in_use_count;
+ rte_mempool_list_dump;
+ rte_mempool_lookup;
rte_mempool_mem_iter;
rte_mempool_obj_iter;
+ rte_mempool_op_calc_mem_size_default;
+ rte_mempool_op_populate_default;
rte_mempool_ops_table;
rte_mempool_populate_anon;
rte_mempool_populate_default;
+ rte_mempool_populate_iova;
rte_mempool_populate_virt;
rte_mempool_register_ops;
rte_mempool_set_ops_byname;
+ rte_mempool_walk;
-} DPDK_2.0;
-
-DPDK_17.11 {
- global:
-
- rte_mempool_populate_iova;
-
-} DPDK_16.07;
-
-DPDK_18.05 {
- global:
-
- rte_mempool_contig_blocks_check_cookies;
- rte_mempool_op_calc_mem_size_default;
- rte_mempool_op_populate_default;
-
-} DPDK_17.11;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_meter/rte_meter_version.map b/lib/librte_meter/rte_meter_version.map
index 4b460d5803..46410b0369 100644
--- a/lib/librte_meter/rte_meter_version.map
+++ b/lib/librte_meter/rte_meter_version.map
@@ -1,21 +1,16 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_meter_srtcm_color_aware_check;
rte_meter_srtcm_color_blind_check;
rte_meter_srtcm_config;
+ rte_meter_srtcm_profile_config;
rte_meter_trtcm_color_aware_check;
rte_meter_trtcm_color_blind_check;
rte_meter_trtcm_config;
-
- local: *;
-};
-
-DPDK_18.08 {
- global:
-
- rte_meter_srtcm_profile_config;
rte_meter_trtcm_profile_config;
+
+ local: *;
};
EXPERIMENTAL {
diff --git a/lib/librte_metrics/rte_metrics_version.map b/lib/librte_metrics/rte_metrics_version.map
index 6ac99a44a1..85663f356e 100644
--- a/lib/librte_metrics/rte_metrics_version.map
+++ b/lib/librte_metrics/rte_metrics_version.map
@@ -1,4 +1,4 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
rte_metrics_get_names;
diff --git a/lib/librte_net/rte_net_version.map b/lib/librte_net/rte_net_version.map
index fffc4a3723..8a4e75a3a0 100644
--- a/lib/librte_net/rte_net_version.map
+++ b/lib/librte_net/rte_net_version.map
@@ -1,25 +1,14 @@
-DPDK_16.11 {
- global:
- rte_net_get_ptype;
-
- local: *;
-};
-
-DPDK_17.05 {
- global:
-
- rte_net_crc_calc;
- rte_net_crc_set_alg;
-
-} DPDK_16.11;
-
-DPDK_19.08 {
+DPDK_20.0 {
global:
rte_eth_random_addr;
rte_ether_format_addr;
+ rte_net_crc_calc;
+ rte_net_crc_set_alg;
+ rte_net_get_ptype;
-} DPDK_17.05;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_pci/rte_pci_version.map b/lib/librte_pci/rte_pci_version.map
index 03790cb0f0..67eb845796 100644
--- a/lib/librte_pci/rte_pci_version.map
+++ b/lib/librte_pci/rte_pci_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
pci_map_resource;
diff --git a/lib/librte_pdump/rte_pdump_version.map b/lib/librte_pdump/rte_pdump_version.map
index 3e744f3012..6d02ccce6d 100644
--- a/lib/librte_pdump/rte_pdump_version.map
+++ b/lib/librte_pdump/rte_pdump_version.map
@@ -1,4 +1,4 @@
-DPDK_16.07 {
+DPDK_20.0 {
global:
rte_pdump_disable;
diff --git a/lib/librte_pipeline/rte_pipeline_version.map b/lib/librte_pipeline/rte_pipeline_version.map
index 420f065d6e..64d38afecd 100644
--- a/lib/librte_pipeline/rte_pipeline_version.map
+++ b/lib/librte_pipeline/rte_pipeline_version.map
@@ -1,6 +1,8 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
+ rte_pipeline_ah_packet_drop;
+ rte_pipeline_ah_packet_hijack;
rte_pipeline_check;
rte_pipeline_create;
rte_pipeline_flush;
@@ -9,42 +11,22 @@ DPDK_2.0 {
rte_pipeline_port_in_create;
rte_pipeline_port_in_disable;
rte_pipeline_port_in_enable;
+ rte_pipeline_port_in_stats_read;
rte_pipeline_port_out_create;
rte_pipeline_port_out_packet_insert;
+ rte_pipeline_port_out_stats_read;
rte_pipeline_run;
rte_pipeline_table_create;
rte_pipeline_table_default_entry_add;
rte_pipeline_table_default_entry_delete;
rte_pipeline_table_entry_add;
- rte_pipeline_table_entry_delete;
-
- local: *;
-};
-
-DPDK_2.1 {
- global:
-
- rte_pipeline_port_in_stats_read;
- rte_pipeline_port_out_stats_read;
- rte_pipeline_table_stats_read;
-
-} DPDK_2.0;
-
-DPDK_2.2 {
- global:
-
rte_pipeline_table_entry_add_bulk;
+ rte_pipeline_table_entry_delete;
rte_pipeline_table_entry_delete_bulk;
+ rte_pipeline_table_stats_read;
-} DPDK_2.1;
-
-DPDK_16.04 {
- global:
-
- rte_pipeline_ah_packet_hijack;
- rte_pipeline_ah_packet_drop;
-
-} DPDK_2.2;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_port/rte_port_version.map b/lib/librte_port/rte_port_version.map
index d5989721d7..18c6154672 100644
--- a/lib/librte_port/rte_port_version.map
+++ b/lib/librte_port/rte_port_version.map
@@ -1,65 +1,35 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_port_ethdev_reader_ops;
+ rte_port_ethdev_writer_nodrop_ops;
rte_port_ethdev_writer_ops;
+ rte_port_fd_reader_ops;
+ rte_port_fd_writer_nodrop_ops;
+ rte_port_fd_writer_ops;
+ rte_port_kni_reader_ops;
+ rte_port_kni_writer_nodrop_ops;
+ rte_port_kni_writer_ops;
+ rte_port_ring_multi_reader_ops;
+ rte_port_ring_multi_writer_nodrop_ops;
+ rte_port_ring_multi_writer_ops;
rte_port_ring_reader_ipv4_frag_ops;
+ rte_port_ring_reader_ipv6_frag_ops;
rte_port_ring_reader_ops;
rte_port_ring_writer_ipv4_ras_ops;
+ rte_port_ring_writer_ipv6_ras_ops;
+ rte_port_ring_writer_nodrop_ops;
rte_port_ring_writer_ops;
rte_port_sched_reader_ops;
rte_port_sched_writer_ops;
rte_port_sink_ops;
rte_port_source_ops;
-
- local: *;
-};
-
-DPDK_2.1 {
- global:
-
- rte_port_ethdev_writer_nodrop_ops;
- rte_port_ring_reader_ipv6_frag_ops;
- rte_port_ring_writer_ipv6_ras_ops;
- rte_port_ring_writer_nodrop_ops;
-
-} DPDK_2.0;
-
-DPDK_2.2 {
- global:
-
- rte_port_ring_multi_reader_ops;
- rte_port_ring_multi_writer_ops;
- rte_port_ring_multi_writer_nodrop_ops;
-
-} DPDK_2.1;
-
-DPDK_16.07 {
- global:
-
- rte_port_kni_reader_ops;
- rte_port_kni_writer_ops;
- rte_port_kni_writer_nodrop_ops;
-
-} DPDK_2.2;
-
-DPDK_16.11 {
- global:
-
- rte_port_fd_reader_ops;
- rte_port_fd_writer_ops;
- rte_port_fd_writer_nodrop_ops;
-
-} DPDK_16.07;
-
-DPDK_18.11 {
- global:
-
rte_port_sym_crypto_reader_ops;
- rte_port_sym_crypto_writer_ops;
rte_port_sym_crypto_writer_nodrop_ops;
+ rte_port_sym_crypto_writer_ops;
-} DPDK_16.11;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_power/rte_power_version.map b/lib/librte_power/rte_power_version.map
index 7729838137..55a168f56e 100644
--- a/lib/librte_power/rte_power_version.map
+++ b/lib/librte_power/rte_power_version.map
@@ -1,39 +1,27 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_power_exit;
+ rte_power_freq_disable_turbo;
rte_power_freq_down;
+ rte_power_freq_enable_turbo;
rte_power_freq_max;
rte_power_freq_min;
rte_power_freq_up;
rte_power_freqs;
+ rte_power_get_capabilities;
rte_power_get_env;
rte_power_get_freq;
+ rte_power_guest_channel_send_msg;
rte_power_init;
rte_power_set_env;
rte_power_set_freq;
+ rte_power_turbo_status;
rte_power_unset_env;
local: *;
};
-DPDK_17.11 {
- global:
-
- rte_power_guest_channel_send_msg;
- rte_power_freq_disable_turbo;
- rte_power_freq_enable_turbo;
- rte_power_turbo_status;
-
-} DPDK_2.0;
-
-DPDK_18.08 {
- global:
-
- rte_power_get_capabilities;
-
-} DPDK_17.11;
-
EXPERIMENTAL {
global:
diff --git a/lib/librte_rawdev/rte_rawdev_version.map b/lib/librte_rawdev/rte_rawdev_version.map
index b61dbff11c..d847c9e0d3 100644
--- a/lib/librte_rawdev/rte_rawdev_version.map
+++ b/lib/librte_rawdev/rte_rawdev_version.map
@@ -1,4 +1,4 @@
-DPDK_18.08 {
+DPDK_20.0 {
global:
rte_rawdev_close;
@@ -17,8 +17,8 @@ DPDK_18.08 {
rte_rawdev_pmd_release;
rte_rawdev_queue_conf_get;
rte_rawdev_queue_count;
- rte_rawdev_queue_setup;
rte_rawdev_queue_release;
+ rte_rawdev_queue_setup;
rte_rawdev_reset;
rte_rawdev_selftest;
rte_rawdev_set_attr;
diff --git a/lib/librte_reorder/rte_reorder_version.map b/lib/librte_reorder/rte_reorder_version.map
index 0a8a54de83..cf444062df 100644
--- a/lib/librte_reorder/rte_reorder_version.map
+++ b/lib/librte_reorder/rte_reorder_version.map
@@ -1,13 +1,13 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_reorder_create;
- rte_reorder_init;
+ rte_reorder_drain;
rte_reorder_find_existing;
- rte_reorder_reset;
rte_reorder_free;
+ rte_reorder_init;
rte_reorder_insert;
- rte_reorder_drain;
+ rte_reorder_reset;
local: *;
};
diff --git a/lib/librte_ring/rte_ring_version.map b/lib/librte_ring/rte_ring_version.map
index 510c1386e0..89d84bcf48 100644
--- a/lib/librte_ring/rte_ring_version.map
+++ b/lib/librte_ring/rte_ring_version.map
@@ -1,8 +1,9 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_ring_create;
rte_ring_dump;
+ rte_ring_free;
rte_ring_get_memsize;
rte_ring_init;
rte_ring_list_dump;
@@ -11,13 +12,6 @@ DPDK_2.0 {
local: *;
};
-DPDK_2.2 {
- global:
-
- rte_ring_free;
-
-} DPDK_2.0;
-
EXPERIMENTAL {
global:
diff --git a/lib/librte_sched/rte_sched_version.map b/lib/librte_sched/rte_sched_version.map
index f33761e63e..cefd990367 100644
--- a/lib/librte_sched/rte_sched_version.map
+++ b/lib/librte_sched/rte_sched_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_approx;
@@ -14,6 +14,9 @@ DPDK_2.0 {
rte_sched_port_enqueue;
rte_sched_port_free;
rte_sched_port_get_memory_footprint;
+ rte_sched_port_pkt_read_color;
+ rte_sched_port_pkt_read_tree_path;
+ rte_sched_port_pkt_write;
rte_sched_queue_read_stats;
rte_sched_subport_config;
rte_sched_subport_read_stats;
@@ -21,15 +24,6 @@ DPDK_2.0 {
local: *;
};
-DPDK_2.1 {
- global:
-
- rte_sched_port_pkt_write;
- rte_sched_port_pkt_read_tree_path;
- rte_sched_port_pkt_read_color;
-
-} DPDK_2.0;
-
EXPERIMENTAL {
global:
diff --git a/lib/librte_security/rte_security_version.map b/lib/librte_security/rte_security_version.map
index 53267bf3cc..b07314bbf4 100644
--- a/lib/librte_security/rte_security_version.map
+++ b/lib/librte_security/rte_security_version.map
@@ -1,4 +1,4 @@
-DPDK_18.11 {
+DPDK_20.0 {
global:
rte_security_attach_session;
diff --git a/lib/librte_table/rte_table_version.map b/lib/librte_table/rte_table_version.map
index 6237252bec..40f72b1fe8 100644
--- a/lib/librte_table/rte_table_version.map
+++ b/lib/librte_table/rte_table_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
rte_table_acl_ops;
diff --git a/lib/librte_timer/rte_timer_version.map b/lib/librte_timer/rte_timer_version.map
index 72f75c8181..2a59d3f081 100644
--- a/lib/librte_timer/rte_timer_version.map
+++ b/lib/librte_timer/rte_timer_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_timer_dump_stats;
@@ -14,16 +14,6 @@ DPDK_2.0 {
local: *;
};
-DPDK_19.05 {
- global:
-
- rte_timer_dump_stats;
- rte_timer_manage;
- rte_timer_reset;
- rte_timer_stop;
- rte_timer_subsystem_init;
-} DPDK_2.0;
-
EXPERIMENTAL {
global:
diff --git a/lib/librte_vhost/rte_vhost_version.map b/lib/librte_vhost/rte_vhost_version.map
index ce517b1271..c512377fe6 100644
--- a/lib/librte_vhost/rte_vhost_version.map
+++ b/lib/librte_vhost/rte_vhost_version.map
@@ -1,64 +1,34 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
+ rte_vhost_avail_entries;
rte_vhost_dequeue_burst;
rte_vhost_driver_callback_register;
- rte_vhost_driver_register;
- rte_vhost_enable_guest_notification;
- rte_vhost_enqueue_burst;
-
- local: *;
-};
-
-DPDK_2.1 {
- global:
-
- rte_vhost_driver_unregister;
-
-} DPDK_2.0;
-
-DPDK_16.07 {
- global:
-
- rte_vhost_avail_entries;
- rte_vhost_get_ifname;
- rte_vhost_get_numa_node;
- rte_vhost_get_queue_num;
-
-} DPDK_2.1;
-
-DPDK_17.05 {
- global:
-
rte_vhost_driver_disable_features;
rte_vhost_driver_enable_features;
rte_vhost_driver_get_features;
+ rte_vhost_driver_register;
rte_vhost_driver_set_features;
rte_vhost_driver_start;
+ rte_vhost_driver_unregister;
+ rte_vhost_enable_guest_notification;
+ rte_vhost_enqueue_burst;
+ rte_vhost_get_ifname;
rte_vhost_get_mem_table;
rte_vhost_get_mtu;
rte_vhost_get_negotiated_features;
+ rte_vhost_get_numa_node;
+ rte_vhost_get_queue_num;
rte_vhost_get_vhost_vring;
rte_vhost_get_vring_num;
rte_vhost_gpa_to_vva;
rte_vhost_log_used_vring;
rte_vhost_log_write;
-
-} DPDK_16.07;
-
-DPDK_17.08 {
- global:
-
rte_vhost_rx_queue_count;
-
-} DPDK_17.05;
-
-DPDK_18.02 {
- global:
-
rte_vhost_vring_call;
-} DPDK_17.08;
+ local: *;
+};
EXPERIMENTAL {
global:
--
2.17.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v9 2/4] doc: changes to abi policy introducing major abi versions
2019-11-08 17:12 5% ` Ray Kinsella
@ 2019-11-08 17:38 5% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-11-08 17:38 UTC (permalink / raw)
To: Ray Kinsella
Cc: dev, stephen, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
08/11/2019 18:12, Ray Kinsella:
> On 08/11/2019 17:11, Thomas Monjalon wrote:
> > 08/11/2019 13:46, Ray Kinsella:
> >> +#. The ABI version is managed at a project level in DPDK, with the ABI version
> >> + reflected in all library's soname.
> >
> > It is not specifying the experimental lib exception.
> > But I can live without it.
>
> I will fix in a follow up on Monday.
If you send a new version, please rebase as there was a change in master
with LTO series. Thanks
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v9 4/4] doc: add maintainer for abi policy
2019-11-08 12:46 13% ` [dpdk-dev] [PATCH v9 4/4] doc: add maintainer for abi policy Ray Kinsella
@ 2019-11-08 17:18 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-11-08 17:18 UTC (permalink / raw)
To: Ray Kinsella
Cc: dev, stephen, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
08/11/2019 13:46, Ray Kinsella:
> Add an entry to the maintainer file for the abi policy.
>
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
> Acked-by: John Mcnamara <john.mcnamara@intel.com>
> ---
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> +ABI Policy
> +M: Ray Kinsella <mdr@ashroe.eu>
> +F: doc/guides/contributing/abi_*.rst
If you are doing a new version, this patch can be squashed in the first one.
If you are doing a new version, please use --in-reply-to.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v9 2/4] doc: changes to abi policy introducing major abi versions
2019-11-08 17:11 5% ` Thomas Monjalon
@ 2019-11-08 17:12 5% ` Ray Kinsella
2019-11-08 17:38 5% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-11-08 17:12 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, stephen, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
On 08/11/2019 17:11, Thomas Monjalon wrote:
> 08/11/2019 13:46, Ray Kinsella:
>> This policy change introduces major ABI versions, these are
>> declared every year, typically aligned with the LTS release
>> and are supported by subsequent releases in the following year.
>> This change is intended to improve ABI stabilty for those projects
>> consuming DPDK.
>>
>> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
>> Acked-by: John Mcnamara <john.mcnamara@intel.com>
>> Acked-by: Stephen Hemminger <stephen@networkplumber.org>
>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
>
>> ---
>> +#. Major ABI versions are declared no more frequently than yearly. Compatibility
>> + with the major ABI version is mandatory in subsequent releases until a new
>> + major ABI version is declared.
>> +#. Major ABI version are usually but not always declared aligned with a
>> + :ref:`LTS release <stable_lts_releases>`.
>
> OK thanks
>
>> +#. The ABI version is managed at a project level in DPDK, with the ABI version
>> + reflected in all library's soname.
>
> It is not specifying the experimental lib exception.
> But I can live without it.
I will fix in a follow up on Monday.
>
>> +A new major ABI version is declared no more frequently than yearly, with
>> +declarations usually aligning with a LTS release, e.g. ABI 20 for DPDK 19.11.
>> +Compatibility with the major ABI version is then mandatory in subsequent
>> +releases until the next major ABI version is declared, e.g. ABI 21 for DPDK
>> +20.11.
>
> OK thanks
>
>> + Note that, this policy details the method by which the ABI may be changed,
>> + with due regard to preserving compatibility and observing deprecation
>> + notices. This process however should not be undertaken lightly, as a general
>> + rule ABI stability is extremely important for downstream consumers of DPDK.
>> + The API should only be changed for significant reasons, such as performance
>> + enhancements. API breakages due to changes such as reorganizing public
>> + structure fields for aesthetic or readability purposes should be avoided.
>
> OK thanks
>
>> +Libraries marked as ``experimental`` are entirely not considered part of an ABI
>> +version, and may change without warning at any time. Experimental libraries
>> +always have a major version of ``0`` to indicate they exist outside of
>> +ABI Versioning, with the minor version incremented with each ABI change
>> +to library.
>
> OK
>
>
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v9 2/4] doc: changes to abi policy introducing major abi versions
2019-11-08 12:46 23% ` [dpdk-dev] [PATCH v9 2/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
@ 2019-11-08 17:11 5% ` Thomas Monjalon
2019-11-08 17:12 5% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-11-08 17:11 UTC (permalink / raw)
To: Ray Kinsella
Cc: dev, stephen, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
08/11/2019 13:46, Ray Kinsella:
> This policy change introduces major ABI versions, these are
> declared every year, typically aligned with the LTS release
> and are supported by subsequent releases in the following year.
> This change is intended to improve ABI stabilty for those projects
> consuming DPDK.
>
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
> Acked-by: John Mcnamara <john.mcnamara@intel.com>
> Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> +#. Major ABI versions are declared no more frequently than yearly. Compatibility
> + with the major ABI version is mandatory in subsequent releases until a new
> + major ABI version is declared.
> +#. Major ABI version are usually but not always declared aligned with a
> + :ref:`LTS release <stable_lts_releases>`.
OK thanks
> +#. The ABI version is managed at a project level in DPDK, with the ABI version
> + reflected in all library's soname.
It is not specifying the experimental lib exception.
But I can live without it.
> +A new major ABI version is declared no more frequently than yearly, with
> +declarations usually aligning with a LTS release, e.g. ABI 20 for DPDK 19.11.
> +Compatibility with the major ABI version is then mandatory in subsequent
> +releases until the next major ABI version is declared, e.g. ABI 21 for DPDK
> +20.11.
OK thanks
> + Note that, this policy details the method by which the ABI may be changed,
> + with due regard to preserving compatibility and observing deprecation
> + notices. This process however should not be undertaken lightly, as a general
> + rule ABI stability is extremely important for downstream consumers of DPDK.
> + The API should only be changed for significant reasons, such as performance
> + enhancements. API breakages due to changes such as reorganizing public
> + structure fields for aesthetic or readability purposes should be avoided.
OK thanks
> +Libraries marked as ``experimental`` are entirely not considered part of an ABI
> +version, and may change without warning at any time. Experimental libraries
> +always have a major version of ``0`` to indicate they exist outside of
> +ABI Versioning, with the minor version incremented with each ABI change
> +to library.
OK
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH] eventdev: reserve space in main structs for extension
@ 2019-11-08 16:56 4% jerinj
0 siblings, 0 replies; 200+ results
From: jerinj @ 2019-11-08 16:56 UTC (permalink / raw)
To: dev, Jerin Jacob; +Cc: thomas
From: Jerin Jacob <jerinj@marvell.com>
The struct rte_eventdev and rte_eventdev_data are supposed
to be used internally only, but there is a chance that
increasing their size would break ABI for some applications.
In order to allow smooth addition of features without breaking
ABI compatibility, some space is reserved.
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
lib/librte_eventdev/rte_eventdev.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h
index ced6f29d9..bc8952576 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -1282,6 +1282,8 @@ struct rte_eventdev_data {
char name[RTE_EVENTDEV_NAME_MAX_LEN];
/**< Unique identifier name */
+ uint64_t reserved_64s[4]; /**< Reserved for future fields */
+ void *reserved_ptrs[4]; /**< Reserved for future fields */
} __rte_cache_aligned;
/** @internal The data structure associated with each event device. */
@@ -1314,6 +1316,9 @@ struct rte_eventdev {
RTE_STD_C11
uint8_t attached : 1;
/**< Flag indicating the device is attached */
+
+ uint64_t reserved_64s[4]; /**< Reserved for future fields */
+ void *reserved_ptrs[4]; /**< Reserved for future fields */
} __rte_cache_aligned;
extern struct rte_eventdev *rte_eventdevs;
--
2.23.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
2019-11-08 16:11 0% ` Dekel Peled
@ 2019-11-08 16:53 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-11-08 16:53 UTC (permalink / raw)
To: Dekel Peled, Matan Azrad, john.mcnamara, marko.kovacevic,
nhorman, ajit.khaparde, somnath.kotur, anatoly.burakov,
xuanziyang2, cloud.wangxiaoyun, zhouguoyang, wenzhuo.lu,
konstantin.ananyev, Shahaf Shuler, Slava Ovsiienko, rmody,
shshaikh, maxime.coquelin, tiwei.bie, zhihong.wang, yongwang,
Thomas Monjalon, arybchenko, jingjing.wu, bernard.iremonger
Cc: dev
On 11/8/2019 4:11 PM, Dekel Peled wrote:
> Thanks, PSB.
>
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> Sent: Friday, November 8, 2019 2:52 PM
>> To: Matan Azrad <matan@mellanox.com>; Dekel Peled
>> <dekelp@mellanox.com>; john.mcnamara@intel.com;
>> marko.kovacevic@intel.com; nhorman@tuxdriver.com;
>> ajit.khaparde@broadcom.com; somnath.kotur@broadcom.com;
>> anatoly.burakov@intel.com; xuanziyang2@huawei.com;
>> cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com;
>> wenzhuo.lu@intel.com; konstantin.ananyev@intel.com; Shahaf Shuler
>> <shahafs@mellanox.com>; Slava Ovsiienko <viacheslavo@mellanox.com>;
>> rmody@marvell.com; shshaikh@marvell.com;
>> maxime.coquelin@redhat.com; tiwei.bie@intel.com;
>> zhihong.wang@intel.com; yongwang@vmware.com; Thomas Monjalon
>> <thomas@monjalon.net>; arybchenko@solarflare.com;
>> jingjing.wu@intel.com; bernard.iremonger@intel.com
>> Cc: dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO
>> packet size
>>
>> On 11/8/2019 11:56 AM, Matan Azrad wrote:
>>>
>>>
>>> From: Ferruh Yigit
>>>> On 11/8/2019 10:10 AM, Matan Azrad wrote:
>>>>>
>>>>>
>>>>> From: Ferruh Yigit
>>>>>> On 11/8/2019 6:54 AM, Matan Azrad wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> From: Ferruh Yigit
>>>>>>>> On 11/7/2019 12:35 PM, Dekel Peled wrote:
>>>>>>>>> @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
>>>>>>>>>
>>>>>>>> RTE_ETHER_MAX_LEN;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> + /*
>>>>>>>>> + * If LRO is enabled, check that the maximum aggregated
>>>> packet
>>>>>>>>> + * size is supported by the configured device.
>>>>>>>>> + */
>>>>>>>>> + if (dev_conf->rxmode.offloads &
>>>> DEV_RX_OFFLOAD_TCP_LRO) {
>>>>>>>>> + ret = check_lro_pkt_size(
>>>>>>>>> + port_id, dev_conf-
>>>>>>>>> rxmode.max_lro_pkt_size,
>>>>>>>>> + dev_info.max_lro_pkt_size);
>>>>>>>>> + if (ret != 0)
>>>>>>>>> + goto rollback;
>>>>>>>>> + }
>>>>>>>>> +
>>>>>>>>
>>>>>>>> This check forces applications that enable LRO to provide
>>>>>> 'max_lro_pkt_size'
>>>>>>>> config value.
>>>>>>>
>>>>>>> Yes.(we can break an API, we noticed it)
>>>>>>
>>>>>> I am not talking about API/ABI breakage, that part is OK.
>>>>>> With this check, if the application requested LRO offload but not
>>>>>> provided 'max_lro_pkt_size' value, device configuration will fail.
>>>>>>
>>>>> Yes
>>>>>> Can there be a case application is good with whatever the PMD can
>>>>>> support as max?
>>>>> Yes can be - you know, we can do everything we want but it is better
>>>>> to be
>>>> consistent:
>>>>> Due to the fact of Max rx pkt len field is mandatory for JUMBO
>>>>> offload, max
>>>> lro pkt len should be mandatory for LRO offload.
>>>>>
>>>>> So your question is actually why both, non-lro packets and LRO
>>>>> packets max
>>>> size are mandatory...
>>>>>
>>>>>
>>>>> I think it should be important values for net applications management.
>>>>> Also good for mbuf size managements.
>>>>>
>>>>>>>
>>>>>>>> - Why it is mandatory now, how it was working before if it is
>>>>>>>> mandatory value?
>>>>>>>
>>>>>>> It is the same as max_rx_pkt_len which is mandatory for jumbo
>>>>>>> frame
>>>>>> offload.
>>>>>>> So now, when the user configures a LRO offload he must to set max
>>>>>>> lro pkt
>>>>>> len.
>>>>>>> We don't want to confuse the user here with the max rx pkt len
>>>>>> configurations and behaviors, they should be with same logic.
>>>>>>>
>>>>>>> This parameter defines well the LRO behavior.
>>>>>>> Before this, each PMD took its own interpretation to what should
>>>>>>> be the
>>>>>> maximum size for LRO aggregated packets.
>>>>>>> Now, the user must say what is his intension, and the ethdev can
>>>>>>> limit it
>>>>>> according to the device capability.
>>>>>>> By this way, also, the PMD can organize\optimize its data-path more.
>>>>>>> Also, the application can create different mempools for LRO queues
>>>>>>> to
>>>>>> allow bigger packet receiving for LRO traffic.
>>>>>>>
>>>>>>>> - What happens if PMD doesn't provide 'max_lro_pkt_size', so it is
>> '0'?
>>>>>>> Yes, you can see the feature description Dekel added.
>>>>>>> This patch also updates all the PMDs support an LRO for non-0 value.
>>>>>>
>>>>>> Of course I can see the updates Matan, my point is "What happens if
>>>>>> PMD doesn't provide 'max_lro_pkt_size'",
>>>>>> 1) There is no check for it right, so it is acceptable?
>>>>>
>>>>> There is check.
>>>>> If the capability is 0, any non-zero configuration will fail.
>>>>>
>>>>>> 2) Are we making this filed mandatory to provide for PMDs, it is
>>>>>> easy to make new fields mandatory for PMDs but is this really
>> necessary?
>>>>>
>>>>> Yes, for consistence.
>>>>>
>>>>>>>
>>>>>>> as same as max rx pkt len, no?
>>>>>>>
>>>>>>>> - What do you think setting 'max_lro_pkt_size' config value to
>>>>>>>> what PMD provided if application doesn't provide it?
>>>>>>> Same answers as above.
>>>>>>>
>>>>>>
>>>>>> If application doesn't care the value, as it has been till now, and
>>>>>> not provided explicit 'max_lro_pkt_size', why not ethdev level use
>>>>>> the value provided by PMD instead of failing?
>>>>>
>>>>> Again, same question we can ask on max rx pkt len.
>>>>>
>>>>> Looks like the packet size is very important value which should be
>>>>> set by
>>>> the application.
>>>>>
>>>>> Previous applications have no option to configure it, so they
>>>>> haven't
>>>> configure it, (probably cover it somehow) I think it is our miss to
>>>> supply this info.
>>>>>
>>>>> Let's do it in same way as we do max rx pkt len (as this patch main idea).
>>>>> Later, we can change both to other meaning.
>>>>>
>>>>
>>>> I think it is not a good reason to introduce a new mandatory config
>>>> option for application because of 'max_rx_pkt_len' does it.
>>>
>>> It is mandatory only if LRO offload is configured.
>>>
>>>> Will it work, if:
>>>> - If application doesn't provide this value, use the PMD max
>>>
>>> May cause a problem if the mbuf size is not enough for the PMD maximum.
>>
>> OK, this is what I was missing, for this case I was thinking max_rx_pkt_len will
>> be used but you already explained that application may want to use different
>> mempools for LRO queues.
>>
>> For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into
>> account and program the device accordingly (of course in LRO enabled case)
>> ?
>> This part seems missing and should be highlighted to other PMD maintainers.
>>
>
> All relevant PMDs were modified and maintainers are copied on this patch series.
>
What modified is PMD announcing a 'dev_info->max_lro_pkt_size' value, which is good.
But PMDs are not using user provided 'rxmode.max_lro_pkt_size' value, I assume
they are still using 'max_rx_pkt_len' to configure the device.
+1 to cc'ing maintainers, but everyone not able to follow all patches and not
sure if every maintainer read the patch and recognized they should update their
driver. I think better to highlight this things in cover letter / emails etc.
I hope it is more clear now.
Not for this patch, but generally;
As a process, previously I proposed a keeping a todo list under documentation
for PMDs for these kind of things, that each PMD maintainer can go there to
figure out what kind of changes required because of others changes, but that
didn't go in.
Other option is whoever updating library update all PMDs fully, but based on
feature it can be very hard to update others PMDs.
Overall these gaps are causing inconsistencies between PMDs and we need a proper
solution.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 1/3] ethdev: support API to set max LRO packet size
@ 2019-11-08 16:42 4% ` Dekel Peled
0 siblings, 0 replies; 200+ results
From: Dekel Peled @ 2019-11-08 16:42 UTC (permalink / raw)
To: john.mcnamara, marko.kovacevic, nhorman, ajit.khaparde,
somnath.kotur, anatoly.burakov, xuanziyang2, cloud.wangxiaoyun,
zhouguoyang, wenzhuo.lu, konstantin.ananyev, matan, shahafs,
viacheslavo, rmody, shshaikh, maxime.coquelin, tiwei.bie,
zhihong.wang, yongwang, thomas, ferruh.yigit, arybchenko,
jingjing.wu, bernard.iremonger
Cc: dev
This patch implements [1], to support API for configuration and
validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11
are updated accordingly.
Various PMDs using LRO offload are updated, the new data members are
initialized to ensure they don't fail validation.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/
Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Matan Azrad <matan@mellanox.com>
---
doc/guides/nics/features.rst | 2 ++
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_19_11.rst | 8 +++++++
drivers/net/bnxt/bnxt_ethdev.c | 1 +
drivers/net/hinic/hinic_pmd_ethdev.c | 1 +
drivers/net/ixgbe/ixgbe_ethdev.c | 1 +
drivers/net/mlx5/mlx5.h | 3 +++
drivers/net/mlx5/mlx5_ethdev.c | 1 +
drivers/net/mlx5/mlx5_rxq.c | 1 -
drivers/net/qede/qede_ethdev.c | 1 +
drivers/net/virtio/virtio_ethdev.c | 1 +
drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 +
lib/librte_ethdev/rte_ethdev.c | 44 ++++++++++++++++++++++++++++++++++
lib/librte_ethdev/rte_ethdev.h | 4 ++++
14 files changed, 68 insertions(+), 5 deletions(-)
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 7a31cf7..2138ce3 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -193,10 +193,12 @@ LRO
Supports Large Receive Offload.
* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_TCP_LRO``.
+ ``dev_conf.rxmode.max_lro_pkt_size``.
* **[implements] datapath**: ``LRO functionality``.
* **[implements] rte_eth_dev_data**: ``lro``.
* **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``.
* **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``.
+* **[provides] rte_eth_dev_info**: ``max_lro_pkt_size``.
.. _nic_features_tso:
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index c10dc30..fdec33d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -87,10 +87,6 @@ Deprecation Notices
This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and
thereby improve Rx performance if application wishes do so.
-* ethdev: New 32-bit fields may be added for maximum LRO session size, in
- struct ``rte_eth_dev_info`` for the port capability and in struct
- ``rte_eth_rxmode`` for the port configuration.
-
* cryptodev: support for using IV with all sizes is added, J0 still can
be used but only when IV length in following structs ``rte_crypto_auth_xform``,
``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index 87b7bd0..a3fc023 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -418,6 +418,14 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
+* ethdev: Added 32-bit fields for maximum LRO aggregated packet size, in
+ struct ``rte_eth_dev_info`` for the port capability and in struct
+ ``rte_eth_rxmode`` for the port configuration.
+ Application should use the new field in struct ``rte_eth_rxmode`` to configure
+ the requested size.
+ PMD should use the new field in struct ``rte_eth_dev_info`` to report the
+ supported port capability.
+
Shared Library Versions
-----------------------
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index b9b055e..741b897 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -519,6 +519,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,
/* Fast path specifics */
dev_info->min_rx_bufsize = 1;
dev_info->max_rx_pktlen = BNXT_MAX_PKT_LEN;
+ dev_info->max_lro_pkt_size = BNXT_MAX_PKT_LEN;
dev_info->rx_offload_capa = BNXT_DEV_RX_OFFLOAD_SUPPORT;
if (bp->flags & BNXT_FLAG_PTP_SUPPORTED)
diff --git a/drivers/net/hinic/hinic_pmd_ethdev.c b/drivers/net/hinic/hinic_pmd_ethdev.c
index 9f37a40..b33b2cf 100644
--- a/drivers/net/hinic/hinic_pmd_ethdev.c
+++ b/drivers/net/hinic/hinic_pmd_ethdev.c
@@ -727,6 +727,7 @@ static void hinic_get_speed_capa(struct rte_eth_dev *dev, uint32_t *speed_capa)
info->max_tx_queues = nic_dev->nic_cap.max_sqs;
info->min_rx_bufsize = HINIC_MIN_RX_BUF_SIZE;
info->max_rx_pktlen = HINIC_MAX_JUMBO_FRAME_SIZE;
+ info->max_lro_pkt_size = HINIC_MAX_JUMBO_FRAME_SIZE;
info->max_mac_addrs = HINIC_MAX_UC_MAC_ADDRS;
info->min_mtu = HINIC_MIN_MTU_SIZE;
info->max_mtu = HINIC_MAX_MTU_SIZE;
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 30c0379..5719552 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3814,6 +3814,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
}
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL register */
dev_info->max_rx_pktlen = 15872; /* includes CRC, cf MAXFRS register */
+ dev_info->max_lro_pkt_size = RTE_IPV4_MAX_PKT_LEN;
dev_info->max_mac_addrs = hw->mac.num_rar_entries;
dev_info->max_hash_mac_addrs = IXGBE_VMDQ_NUM_UC_MAC;
dev_info->max_vfs = pci_dev->max_vfs;
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index fab58c9..4783b5c 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -206,6 +206,9 @@ struct mlx5_hca_attr {
#define MLX5_LRO_SUPPORTED(dev) \
(((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported)
+/* Maximal size of aggregated LRO packet. */
+#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)
+
/* LRO configurations structure. */
struct mlx5_lro_config {
uint32_t supported:1; /* Whether LRO is supported. */
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 2b7c867..3adc824 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -606,6 +606,7 @@ struct ethtool_link_settings {
/* FIXME: we should ask the device for these values. */
info->min_rx_bufsize = 32;
info->max_rx_pktlen = 65536;
+ info->max_lro_pkt_size = MLX5_MAX_LRO_SIZE;
/*
* Since we need one CQ per QP, the limit is the minimum number
* between the two values.
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index 24d0eaa..9423e7b 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -1701,7 +1701,6 @@ struct mlx5_rxq_obj *
return 0;
}
-#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)
#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \
sizeof(struct rte_vlan_hdr) * 2 + \
sizeof(struct rte_ipv6_hdr)))
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 575982f..ccbb8a4 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev)
dev_info->min_rx_bufsize = (uint32_t)QEDE_MIN_RX_BUFF_SIZE;
dev_info->max_rx_pktlen = (uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
+ dev_info->max_lro_pkt_size = (uint32_t)0x7FFF;
dev_info->rx_desc_lim = qede_rx_desc_lim;
dev_info->tx_desc_lim = qede_tx_desc_lim;
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 044eb10..22ce5a2 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -2435,6 +2435,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)
RTE_MIN(hw->max_queue_pairs, VIRTIO_MAX_TX_QUEUES);
dev_info->min_rx_bufsize = VIRTIO_MIN_RX_BUFSIZE;
dev_info->max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN;
+ dev_info->max_lro_pkt_size = VIRTIO_MAX_RX_PKTLEN;
dev_info->max_mac_addrs = VIRTIO_MAX_MAC_ADDRS;
host_features = VTPCI_OPS(hw)->get_features(hw);
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index d1faeaa..d18e8bc 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -1161,6 +1161,7 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device *pci_dev)
dev_info->max_tx_queues = VMXNET3_MAX_TX_QUEUES;
dev_info->min_rx_bufsize = 1518 + RTE_PKTMBUF_HEADROOM;
dev_info->max_rx_pktlen = 16384; /* includes CRC, cf MAXFRS register */
+ dev_info->max_lro_pkt_size = 16384;
dev_info->speed_capa = ETH_LINK_SPEED_10G;
dev_info->max_mac_addrs = VMXNET3_MAX_MAC_ADDRS;
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 652c369..c642ba5 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -1136,6 +1136,26 @@ struct rte_eth_dev *
return name;
}
+static inline int
+check_lro_pkt_size(uint16_t port_id, uint32_t config_size,
+ uint32_t dev_info_size)
+{
+ int ret = 0;
+
+ if (config_size > dev_info_size) {
+ RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d max_lro_pkt_size %u "
+ "> max allowed value %u\n", port_id, config_size,
+ dev_info_size);
+ ret = -EINVAL;
+ } else if (config_size < RTE_ETHER_MIN_LEN) {
+ RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d max_lro_pkt_size %u "
+ "< min allowed value %u\n", port_id, config_size,
+ (unsigned int)RTE_ETHER_MIN_LEN);
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
int
rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
const struct rte_eth_conf *dev_conf)
@@ -1266,6 +1286,18 @@ struct rte_eth_dev *
RTE_ETHER_MAX_LEN;
}
+ /*
+ * If LRO is enabled, check that the maximum aggregated packet
+ * size is supported by the configured device.
+ */
+ if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
+ ret = check_lro_pkt_size(
+ port_id, dev_conf->rxmode.max_lro_pkt_size,
+ dev_info.max_lro_pkt_size);
+ if (ret != 0)
+ goto rollback;
+ }
+
/* Any requested offloading must be within its device capabilities */
if ((dev_conf->rxmode.offloads & dev_info.rx_offload_capa) !=
dev_conf->rxmode.offloads) {
@@ -1770,6 +1802,18 @@ struct rte_eth_dev *
return -EINVAL;
}
+ /*
+ * If LRO is enabled, check that the maximum aggregated packet
+ * size is supported by the configured device.
+ */
+ if (local_conf.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
+ int ret = check_lro_pkt_size(port_id,
+ dev->data->dev_conf.rxmode.max_lro_pkt_size,
+ dev_info.max_lro_pkt_size);
+ if (ret != 0)
+ return ret;
+ }
+
ret = (*dev->dev_ops->rx_queue_setup)(dev, rx_queue_id, nb_rx_desc,
socket_id, &local_conf, mp);
if (!ret) {
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 44d77b3..1b76df5 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -395,6 +395,8 @@ struct rte_eth_rxmode {
/** The multi-queue packet distribution mode to be used, e.g. RSS. */
enum rte_eth_rx_mq_mode mq_mode;
uint32_t max_rx_pkt_len; /**< Only used if JUMBO_FRAME enabled. */
+ /** Maximum allowed size of LRO aggregated packet. */
+ uint32_t max_lro_pkt_size;
uint16_t split_hdr_size; /**< hdr buf size (header_split enabled).*/
/**
* Per-port Rx offloads to be set using DEV_RX_OFFLOAD_* flags.
@@ -1218,6 +1220,8 @@ struct rte_eth_dev_info {
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
+ /** Maximum configurable size of LRO aggregated packet. */
+ uint32_t max_lro_pkt_size;
uint16_t max_rx_queues; /**< Maximum number of RX queues. */
uint16_t max_tx_queues; /**< Maximum number of TX queues. */
uint32_t max_mac_addrs; /**< Maximum number of MAC addresses. */
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
2019-11-08 16:08 0% ` Dekel Peled
@ 2019-11-08 16:28 0% ` Ananyev, Konstantin
0 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2019-11-08 16:28 UTC (permalink / raw)
To: Dekel Peled, Matan Azrad, Yigit, Ferruh, Mcnamara, John,
Kovacevic, Marko, nhorman, ajit.khaparde, somnath.kotur, Burakov,
Anatoly, xuanziyang2, cloud.wangxiaoyun, zhouguoyang, Lu,
Wenzhuo, Shahaf Shuler, Slava Ovsiienko, rmody, shshaikh,
maxime.coquelin, Bie, Tiwei, Wang, Zhihong, yongwang,
Thomas Monjalon, arybchenko, Wu, Jingjing, Iremonger, Bernard
Cc: dev
> >
> >
> > > > > > >>>> On 11/7/2019 12:35 PM, Dekel Peled wrote:
> > > > > > >>>>> @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
> > > > > > >>>>>
> > > > > > >>>> RTE_ETHER_MAX_LEN;
> > > > > > >>>>> }
> > > > > > >>>>>
> > > > > > >>>>> + /*
> > > > > > >>>>> + * If LRO is enabled, check that the maximum
> > aggregated
> > > > > > packet
> > > > > > >>>>> + * size is supported by the configured device.
> > > > > > >>>>> + */
> > > > > > >>>>> + if (dev_conf->rxmode.offloads &
> > > > > > DEV_RX_OFFLOAD_TCP_LRO) {
> > > > > > >>>>> + ret = check_lro_pkt_size(
> > > > > > >>>>> + port_id, dev_conf-
> > > > > > >>>>> rxmode.max_lro_pkt_size,
> > > > > > >>>>> + dev_info.max_lro_pkt_size);
> > > > > > >>>>> + if (ret != 0)
> > > > > > >>>>> + goto rollback;
> > > > > > >>>>> + }
> > > > > > >>>>> +
> > > > > > >>>>
> > > > > > >>>> This check forces applications that enable LRO to provide
> > > > > > >> 'max_lro_pkt_size'
> > > > > > >>>> config value.
> > > > > > >>>
> > > > > > >>> Yes.(we can break an API, we noticed it)
> > > > > > >>
> > > > > > >> I am not talking about API/ABI breakage, that part is OK.
> > > > > > >> With this check, if the application requested LRO offload but
> > > > > > >> not provided 'max_lro_pkt_size' value, device configuration will
> > fail.
> > > > > > >>
> > > > > > > Yes
> > > > > > >> Can there be a case application is good with whatever the PMD
> > > > > > >> can support as max?
> > > > > > > Yes can be - you know, we can do everything we want but it is
> > > > > > > better to be
> > > > > > consistent:
> > > > > > > Due to the fact of Max rx pkt len field is mandatory for JUMBO
> > > > > > > offload, max
> > > > > > lro pkt len should be mandatory for LRO offload.
> > > > > > >
> > > > > > > So your question is actually why both, non-lro packets and LRO
> > > > > > > packets max
> > > > > > size are mandatory...
> > > > > > >
> > > > > > >
> > > > > > > I think it should be important values for net applications
> > management.
> > > > > > > Also good for mbuf size managements.
> > > > > > >
> > > > > > >>>
> > > > > > >>>> - Why it is mandatory now, how it was working before if it
> > > > > > >>>> is mandatory value?
> > > > > > >>>
> > > > > > >>> It is the same as max_rx_pkt_len which is mandatory for
> > > > > > >>> jumbo frame
> > > > > > >> offload.
> > > > > > >>> So now, when the user configures a LRO offload he must to
> > > > > > >>> set max lro pkt
> > > > > > >> len.
> > > > > > >>> We don't want to confuse the user here with the max rx pkt
> > > > > > >>> len
> > > > > > >> configurations and behaviors, they should be with same logic.
> > > > > > >>>
> > > > > > >>> This parameter defines well the LRO behavior.
> > > > > > >>> Before this, each PMD took its own interpretation to what
> > > > > > >>> should be the
> > > > > > >> maximum size for LRO aggregated packets.
> > > > > > >>> Now, the user must say what is his intension, and the ethdev
> > > > > > >>> can limit it
> > > > > > >> according to the device capability.
> > > > > > >>> By this way, also, the PMD can organize\optimize its data-path
> > more.
> > > > > > >>> Also, the application can create different mempools for LRO
> > > > > > >>> queues to
> > > > > > >> allow bigger packet receiving for LRO traffic.
> > > > > > >>>
> > > > > > >>>> - What happens if PMD doesn't provide 'max_lro_pkt_size',
> > > > > > >>>> so it is
> > > > '0'?
> > > > > > >>> Yes, you can see the feature description Dekel added.
> > > > > > >>> This patch also updates all the PMDs support an LRO for non-0
> > value.
> > > > > > >>
> > > > > > >> Of course I can see the updates Matan, my point is "What
> > > > > > >> happens if PMD doesn't provide 'max_lro_pkt_size'",
> > > > > > >> 1) There is no check for it right, so it is acceptable?
> > > > > > >
> > > > > > > There is check.
> > > > > > > If the capability is 0, any non-zero configuration will fail.
> > > > > > >
> > > > > > >> 2) Are we making this filed mandatory to provide for PMDs, it
> > > > > > >> is easy to make new fields mandatory for PMDs but is this
> > > > > > >> really
> > > > necessary?
> > > > > > >
> > > > > > > Yes, for consistence.
> > > > > > >
> > > > > > >>>
> > > > > > >>> as same as max rx pkt len, no?
> > > > > > >>>
> > > > > > >>>> - What do you think setting 'max_lro_pkt_size' config value
> > > > > > >>>> to what PMD provided if application doesn't provide it?
> > > > > > >>> Same answers as above.
> > > > > > >>>
> > > > > > >>
> > > > > > >> If application doesn't care the value, as it has been till
> > > > > > >> now, and not provided explicit 'max_lro_pkt_size', why not
> > > > > > >> ethdev level use the value provided by PMD instead of failing?
> > > > > > >
> > > > > > > Again, same question we can ask on max rx pkt len.
> > > > > > >
> > > > > > > Looks like the packet size is very important value which
> > > > > > > should be set by
> > > > > > the application.
> > > > > > >
> > > > > > > Previous applications have no option to configure it, so they
> > > > > > > haven't
> > > > > > configure it, (probably cover it somehow) I think it is our miss
> > > > > > to supply this info.
> > > > > > >
> > > > > > > Let's do it in same way as we do max rx pkt len (as this patch main
> > idea).
> > > > > > > Later, we can change both to other meaning.
> > > > > > >
> > > > > >
> > > > > > I think it is not a good reason to introduce a new mandatory
> > > > > > config option for application because of 'max_rx_pkt_len' does it.
> > > > >
> > > > > It is mandatory only if LRO offload is configured.
> > > >
> > > > So max_rx_pkt_len will remain max size of one packet, while
> > > > max_lro_len will be max accumulate size for each LRO session?
> > > >
> > >
> > > Yes.
> > >
> > > > BTW, I think that for ixgbe max lro is RTE_IPV4_MAX_PKT_LEN.
> > >
> > > Please see my change in drivers/net/ixgbe/ixgbe_ethdev.c.
> > > Change to RTE_IPV4_MAX_PKT_LEN?
> > >
> > > > ixgbe_vf, as I remember, doesn’t support LRO at all.
> > >
> > > Please see my change in drivers/net/ixgbe/ixgbe_vf_representor.c
> > > Remove it?
> >
> > Yes, please for both.
>
> Will change in v5.
>
> >
> > >
> > > >
> > > > >
> > > > > > Will it work, if:
> > > > > > - If application doesn't provide this value, use the PMD max
> > > > >
> > > > > May cause a problem if the mbuf size is not enough for the PMD
> > maximum.
> > > >
> > > > Another question, what will happen if PMD will ignore that value and
> > > > will generate packets bigger then requested?
> > >
> > > PMD should use this value and not ignore it.
> >
> > Hmm, ok but this patch updates mxl driver only...
> > I suppose you expect other PMD maintainers to do the job for their PMDs,
> > right?
> > If so, are they aware (and agree) for this new hard requirement and changes
> > required?
> > Again what PMD should do if it can't support exact value?
> > Let say user asked max_lro_size=20KB but PMD can do only 16KB or 24KB?
> > Should it fail, or round to smallest, or ...?
> >
> > Actually I wonder, should it really be a hard requirement or more like a
> > guidance to PMD?
> > Why app needs and *exact* value for LRO size?
>
> The exact value should be configured to HW as LRO session limit.
But if the HW can't support this exact value, see the example above?
In fact, shouldn't we allow PMD to forbid user to configure max LRO size?
Let say if in dev_info max_lro_size==0, then PMD doesn't support LRO size
configuration at all.
That way PMDs who do support LRO, but don't want to (can't to)
support configurable LRO size will stay untouched.
>
> >
> >
> > > >
> > > > >
> > > > > > - If both application and PMD doesn't provide this value, fail
> > > > > > on
> > > > configure()?
> > > > >
> > > > > It will work.
> > > > > In my opinion - not ideal.
> > > > >
> > > > > Matan
> > > > >
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v7 10/10] buildtools: add ABI versioning check script
2019-11-06 16:54 8% ` [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
` (9 preceding siblings ...)
2019-11-08 16:25 2% ` [dpdk-dev] [PATCH v7 09/10] build: change ABI version to 20.0 Anatoly Burakov
@ 2019-11-08 16:25 23% ` Anatoly Burakov
10 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-08 16:25 UTC (permalink / raw)
To: dev
Cc: Marcin Baran, john.mcnamara, ray.kinsella, bruce.richardson,
thomas, david.marchand, Pawel Modrak
From: Marcin Baran <marcinx.baran@intel.com>
Add a shell script that checks whether built libraries are
versioned with expected ABI (current ABI, current ABI + 1,
or EXPERIMENTAL).
The following command was used to verify current source tree
(assuming build directory is in ./build):
find ./build/lib ./build/drivers -name \*.so \
-exec ./buildtools/check-abi-version.sh {} \; -print
Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
Signed-off-by: Pawel Modrak <pawelx.modrak@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
Notes:
v2:
- Moved this to the end of the patchset
- Fixed bug when ABI symbols were not found because the .so
did not declare any public symbols
buildtools/check-abi-version.sh | 54 +++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100755 buildtools/check-abi-version.sh
diff --git a/buildtools/check-abi-version.sh b/buildtools/check-abi-version.sh
new file mode 100755
index 0000000000..29aea97735
--- /dev/null
+++ b/buildtools/check-abi-version.sh
@@ -0,0 +1,54 @@
+#!/bin/sh
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+
+# Check whether library symbols have correct
+# version (provided ABI number or provided ABI
+# number + 1 or EXPERIMENTAL).
+# Args:
+# $1: path of the library .so file
+# $2: ABI major version number to check
+# (defaults to ABI_VERSION file value)
+
+if [ -z "$1" ]; then
+ echo "Script checks whether library symbols have"
+ echo "correct version (ABI_VER/ABI_VER+1/EXPERIMENTAL)"
+ echo "Usage:"
+ echo " $0 SO_FILE_PATH [ABI_VER]"
+ exit 1
+fi
+
+LIB="$1"
+DEFAULT_ABI=$(cat "$(dirname \
+ $(readlink -f $0))/../config/ABI_VERSION" | \
+ cut -d'.' -f 1)
+ABIVER="DPDK_${2-$DEFAULT_ABI}"
+NEXT_ABIVER="DPDK_$((${2-$DEFAULT_ABI}+1))"
+
+ret=0
+
+# get output of objdump
+OBJ_DUMP_OUTPUT=`objdump -TC --section=.text ${LIB} 2>&1 | grep ".text"`
+
+# there may not be any .text sections in the .so file, in which case exit early
+echo "${OBJ_DUMP_OUTPUT}" | grep "not found in any input file" -q
+if [ "$?" -eq 0 ]; then
+ exit 0
+fi
+
+# we have symbols, so let's see if the versions are correct
+for SYM in `echo "${OBJ_DUMP_OUTPUT}" | awk '{print $(NF-1) "-" $NF}'`
+do
+ version=$(echo $SYM | cut -d'-' -f 1)
+ symbol=$(echo $SYM | cut -d'-' -f 2)
+ case $version in (*"$ABIVER"*|*"$NEXT_ABIVER"*|"EXPERIMENTAL")
+ ;;
+ (*)
+ echo "Warning: symbol $symbol ($version) should be annotated " \
+ "as ABI version $ABIVER / $NEXT_ABIVER, or EXPERIMENTAL."
+ ret=1
+ ;;
+ esac
+done
+
+exit $ret
--
2.17.1
^ permalink raw reply [relevance 23%]
* [dpdk-dev] [PATCH v7 08/10] drivers/octeontx: add missing public symbol
2019-11-06 16:54 8% ` [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
` (7 preceding siblings ...)
2019-11-08 16:25 6% ` [dpdk-dev] [PATCH v7 07/10] distributor: rename v2.0 ABI to _single suffix Anatoly Burakov
@ 2019-11-08 16:25 3% ` Anatoly Burakov
2019-11-08 16:25 2% ` [dpdk-dev] [PATCH v7 09/10] build: change ABI version to 20.0 Anatoly Burakov
2019-11-08 16:25 23% ` [dpdk-dev] [PATCH v7 10/10] buildtools: add ABI versioning check script Anatoly Burakov
10 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-08 16:25 UTC (permalink / raw)
To: dev
Cc: Jerin Jacob, john.mcnamara, ray.kinsella, bruce.richardson,
thomas, david.marchand, pbhagavatula, stable
The logtype symbol was missing from the .map file. Add it.
Fixes: d8dd31652cf4 ("common/octeontx: move mbox to common folder")
Cc: pbhagavatula@caviumnetworks.com
Cc: stable@dpdk.org
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
Notes:
v2:
- add this patch to avoid compile breakage when bumping ABI
drivers/common/octeontx/rte_common_octeontx_version.map | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/common/octeontx/rte_common_octeontx_version.map b/drivers/common/octeontx/rte_common_octeontx_version.map
index f04b3b7f8a..a9b3cff9bc 100644
--- a/drivers/common/octeontx/rte_common_octeontx_version.map
+++ b/drivers/common/octeontx/rte_common_octeontx_version.map
@@ -1,6 +1,7 @@
DPDK_18.05 {
global:
+ octeontx_logtype_mbox;
octeontx_mbox_set_ram_mbox_base;
octeontx_mbox_set_reg;
octeontx_mbox_send;
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v7 07/10] distributor: rename v2.0 ABI to _single suffix
2019-11-06 16:54 8% ` [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
` (6 preceding siblings ...)
2019-11-08 16:25 4% ` [dpdk-dev] [PATCH v7 06/10] distributor: " Anatoly Burakov
@ 2019-11-08 16:25 6% ` Anatoly Burakov
2019-11-08 16:25 3% ` [dpdk-dev] [PATCH v7 08/10] drivers/octeontx: add missing public symbol Anatoly Burakov
` (2 subsequent siblings)
10 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-08 16:25 UTC (permalink / raw)
To: dev
Cc: Marcin Baran, David Hunt, john.mcnamara, ray.kinsella,
bruce.richardson, thomas, david.marchand
From: Marcin Baran <marcinx.baran@intel.com>
The original ABI versioning was slightly misleading in that the
DPDK 2.0 ABI was really a single mode for the distributor, and is
used as such throughout the distributor code.
Fix this by renaming all _v20 API's to _single API's, and remove
symbol versioning.
Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: David Hunt <david.hunt@intel.com>
---
Notes:
v4:
- Changed it back to how it was with v2
- Removed remaining v2.0 symbols
v3:
- Removed single mode from distributor as per Dave's comments
v2:
- Moved this to before ABI version bump to avoid compile breakage
lib/librte_distributor/Makefile | 2 +-
lib/librte_distributor/distributor_private.h | 10 +--
lib/librte_distributor/meson.build | 2 +-
lib/librte_distributor/rte_distributor.c | 24 +++----
...ributor_v20.c => rte_distributor_single.c} | 64 +++++++++----------
...ributor_v20.h => rte_distributor_single.h} | 26 ++++----
.../rte_distributor_version.map | 18 +-----
7 files changed, 66 insertions(+), 80 deletions(-)
rename lib/librte_distributor/{rte_distributor_v20.c => rte_distributor_single.c} (87%)
rename lib/librte_distributor/{rte_distributor_v20.h => rte_distributor_single.h} (89%)
diff --git a/lib/librte_distributor/Makefile b/lib/librte_distributor/Makefile
index 0ef80dcff4..d9d0089166 100644
--- a/lib/librte_distributor/Makefile
+++ b/lib/librte_distributor/Makefile
@@ -15,7 +15,7 @@ EXPORT_MAP := rte_distributor_version.map
LIBABIVER := 1
# all source are stored in SRCS-y
-SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) := rte_distributor_v20.c
+SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) := rte_distributor_single.c
SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += rte_distributor.c
ifeq ($(CONFIG_RTE_ARCH_X86),y)
SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += rte_distributor_match_sse.c
diff --git a/lib/librte_distributor/distributor_private.h b/lib/librte_distributor/distributor_private.h
index c89371123e..489aef2acb 100644
--- a/lib/librte_distributor/distributor_private.h
+++ b/lib/librte_distributor/distributor_private.h
@@ -55,7 +55,7 @@ extern "C" {
* the next cache line to worker 0, we pad this out to three cache lines.
* Only 64-bits of the memory is actually used though.
*/
-union rte_distributor_buffer_v20 {
+union rte_distributor_buffer_single {
volatile int64_t bufptr64;
char pad[RTE_CACHE_LINE_SIZE*3];
} __rte_cache_aligned;
@@ -80,8 +80,8 @@ struct rte_distributor_returned_pkts {
struct rte_mbuf *mbufs[RTE_DISTRIB_MAX_RETURNS];
};
-struct rte_distributor_v20 {
- TAILQ_ENTRY(rte_distributor_v20) next; /**< Next in list. */
+struct rte_distributor_single {
+ TAILQ_ENTRY(rte_distributor_single) next; /**< Next in list. */
char name[RTE_DISTRIBUTOR_NAMESIZE]; /**< Name of the ring. */
unsigned int num_workers; /**< Number of workers polling */
@@ -96,7 +96,7 @@ struct rte_distributor_v20 {
struct rte_distributor_backlog backlog[RTE_DISTRIB_MAX_WORKERS];
- union rte_distributor_buffer_v20 bufs[RTE_DISTRIB_MAX_WORKERS];
+ union rte_distributor_buffer_single bufs[RTE_DISTRIB_MAX_WORKERS];
struct rte_distributor_returned_pkts returns;
};
@@ -154,7 +154,7 @@ struct rte_distributor {
enum rte_distributor_match_function dist_match_fn;
- struct rte_distributor_v20 *d_v20;
+ struct rte_distributor_single *d_single;
};
void
diff --git a/lib/librte_distributor/meson.build b/lib/librte_distributor/meson.build
index c9617d7b14..50b91887b5 100644
--- a/lib/librte_distributor/meson.build
+++ b/lib/librte_distributor/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-sources = files('rte_distributor.c', 'rte_distributor_v20.c')
+sources = files('rte_distributor.c', 'rte_distributor_single.c')
if arch_subdir == 'x86'
sources += files('rte_distributor_match_sse.c')
else
diff --git a/lib/librte_distributor/rte_distributor.c b/lib/librte_distributor/rte_distributor.c
index a4c8ff6a96..6c5b0c86e8 100644
--- a/lib/librte_distributor/rte_distributor.c
+++ b/lib/librte_distributor/rte_distributor.c
@@ -17,7 +17,7 @@
#include <rte_tailq.h>
#include "rte_distributor.h"
-#include "rte_distributor_v20.h"
+#include "rte_distributor_single.h"
#include "distributor_private.h"
TAILQ_HEAD(rte_dist_burst_list, rte_distributor);
@@ -42,7 +42,7 @@ rte_distributor_request_pkt(struct rte_distributor *d,
volatile int64_t *retptr64;
if (unlikely(d->alg_type == RTE_DIST_ALG_SINGLE)) {
- rte_distributor_request_pkt_v20(d->d_v20,
+ rte_distributor_request_pkt_single(d->d_single,
worker_id, oldpkt[0]);
return;
}
@@ -93,7 +93,8 @@ rte_distributor_poll_pkt(struct rte_distributor *d,
unsigned int i;
if (unlikely(d->alg_type == RTE_DIST_ALG_SINGLE)) {
- pkts[0] = rte_distributor_poll_pkt_v20(d->d_v20, worker_id);
+ pkts[0] = rte_distributor_poll_pkt_single(d->d_single,
+ worker_id);
return (pkts[0]) ? 1 : 0;
}
@@ -133,7 +134,7 @@ rte_distributor_get_pkt(struct rte_distributor *d,
if (unlikely(d->alg_type == RTE_DIST_ALG_SINGLE)) {
if (return_count <= 1) {
- pkts[0] = rte_distributor_get_pkt_v20(d->d_v20,
+ pkts[0] = rte_distributor_get_pkt_single(d->d_single,
worker_id, oldpkt[0]);
return (pkts[0]) ? 1 : 0;
} else
@@ -163,7 +164,7 @@ rte_distributor_return_pkt(struct rte_distributor *d,
if (unlikely(d->alg_type == RTE_DIST_ALG_SINGLE)) {
if (num == 1)
- return rte_distributor_return_pkt_v20(d->d_v20,
+ return rte_distributor_return_pkt_single(d->d_single,
worker_id, oldpkt[0]);
else
return -EINVAL;
@@ -354,7 +355,8 @@ rte_distributor_process(struct rte_distributor *d,
if (d->alg_type == RTE_DIST_ALG_SINGLE) {
/* Call the old API */
- return rte_distributor_process_v20(d->d_v20, mbufs, num_mbufs);
+ return rte_distributor_process_single(d->d_single,
+ mbufs, num_mbufs);
}
if (unlikely(num_mbufs == 0)) {
@@ -494,7 +496,7 @@ rte_distributor_returned_pkts(struct rte_distributor *d,
if (d->alg_type == RTE_DIST_ALG_SINGLE) {
/* Call the old API */
- return rte_distributor_returned_pkts_v20(d->d_v20,
+ return rte_distributor_returned_pkts_single(d->d_single,
mbufs, max_mbufs);
}
@@ -537,7 +539,7 @@ rte_distributor_flush(struct rte_distributor *d)
if (d->alg_type == RTE_DIST_ALG_SINGLE) {
/* Call the old API */
- return rte_distributor_flush_v20(d->d_v20);
+ return rte_distributor_flush_single(d->d_single);
}
flushed = total_outstanding(d);
@@ -568,7 +570,7 @@ rte_distributor_clear_returns(struct rte_distributor *d)
if (d->alg_type == RTE_DIST_ALG_SINGLE) {
/* Call the old API */
- rte_distributor_clear_returns_v20(d->d_v20);
+ rte_distributor_clear_returns_single(d->d_single);
return;
}
@@ -610,9 +612,9 @@ rte_distributor_create(const char *name,
rte_errno = ENOMEM;
return NULL;
}
- d->d_v20 = rte_distributor_create_v20(name,
+ d->d_single = rte_distributor_create_single(name,
socket_id, num_workers);
- if (d->d_v20 == NULL) {
+ if (d->d_single == NULL) {
free(d);
/* rte_errno will have been set */
return NULL;
diff --git a/lib/librte_distributor/rte_distributor_v20.c b/lib/librte_distributor/rte_distributor_single.c
similarity index 87%
rename from lib/librte_distributor/rte_distributor_v20.c
rename to lib/librte_distributor/rte_distributor_single.c
index 655944bdb3..91d8824c64 100644
--- a/lib/librte_distributor/rte_distributor_v20.c
+++ b/lib/librte_distributor/rte_distributor_single.c
@@ -15,10 +15,10 @@
#include <rte_pause.h>
#include <rte_tailq.h>
-#include "rte_distributor_v20.h"
+#include "rte_distributor_single.h"
#include "distributor_private.h"
-TAILQ_HEAD(rte_distributor_list, rte_distributor_v20);
+TAILQ_HEAD(rte_distributor_list, rte_distributor_single);
static struct rte_tailq_elem rte_distributor_tailq = {
.name = "RTE_DISTRIBUTOR",
@@ -27,11 +27,11 @@ EAL_REGISTER_TAILQ(rte_distributor_tailq)
/**** APIs called by workers ****/
-void __vsym
-rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
+void
+rte_distributor_request_pkt_single(struct rte_distributor_single *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
- union rte_distributor_buffer_v20 *buf = &d->bufs[worker_id];
+ union rte_distributor_buffer_single *buf = &d->bufs[worker_id];
int64_t req = (((int64_t)(uintptr_t)oldpkt) << RTE_DISTRIB_FLAG_BITS)
| RTE_DISTRIB_GET_BUF;
while (unlikely(__atomic_load_n(&buf->bufptr64, __ATOMIC_RELAXED)
@@ -42,11 +42,11 @@ rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
__atomic_store_n(&(buf->bufptr64), req, __ATOMIC_RELEASE);
}
-struct rte_mbuf * __vsym
-rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
+struct rte_mbuf *
+rte_distributor_poll_pkt_single(struct rte_distributor_single *d,
unsigned worker_id)
{
- union rte_distributor_buffer_v20 *buf = &d->bufs[worker_id];
+ union rte_distributor_buffer_single *buf = &d->bufs[worker_id];
/* Sync with distributor. Acquire bufptr64. */
if (__atomic_load_n(&buf->bufptr64, __ATOMIC_ACQUIRE)
& RTE_DISTRIB_GET_BUF)
@@ -57,22 +57,22 @@ rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
return (struct rte_mbuf *)((uintptr_t)ret);
}
-struct rte_mbuf * __vsym
-rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
+struct rte_mbuf *
+rte_distributor_get_pkt_single(struct rte_distributor_single *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
struct rte_mbuf *ret;
- rte_distributor_request_pkt_v20(d, worker_id, oldpkt);
- while ((ret = rte_distributor_poll_pkt_v20(d, worker_id)) == NULL)
+ rte_distributor_request_pkt_single(d, worker_id, oldpkt);
+ while ((ret = rte_distributor_poll_pkt_single(d, worker_id)) == NULL)
rte_pause();
return ret;
}
-int __vsym
-rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
+int
+rte_distributor_return_pkt_single(struct rte_distributor_single *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
- union rte_distributor_buffer_v20 *buf = &d->bufs[worker_id];
+ union rte_distributor_buffer_single *buf = &d->bufs[worker_id];
uint64_t req = (((int64_t)(uintptr_t)oldpkt) << RTE_DISTRIB_FLAG_BITS)
| RTE_DISTRIB_RETURN_BUF;
/* Sync with distributor on RETURN_BUF flag. */
@@ -104,7 +104,7 @@ backlog_pop(struct rte_distributor_backlog *bl)
/* stores a packet returned from a worker inside the returns array */
static inline void
-store_return(uintptr_t oldbuf, struct rte_distributor_v20 *d,
+store_return(uintptr_t oldbuf, struct rte_distributor_single *d,
unsigned *ret_start, unsigned *ret_count)
{
/* store returns in a circular buffer - code is branch-free */
@@ -115,7 +115,7 @@ store_return(uintptr_t oldbuf, struct rte_distributor_v20 *d,
}
static inline void
-handle_worker_shutdown(struct rte_distributor_v20 *d, unsigned int wkr)
+handle_worker_shutdown(struct rte_distributor_single *d, unsigned int wkr)
{
d->in_flight_tags[wkr] = 0;
d->in_flight_bitmask &= ~(1UL << wkr);
@@ -146,7 +146,7 @@ handle_worker_shutdown(struct rte_distributor_v20 *d, unsigned int wkr)
* Note that the tags were set before first level call
* to rte_distributor_process.
*/
- rte_distributor_process_v20(d, pkts, i);
+ rte_distributor_process_single(d, pkts, i);
bl->count = bl->start = 0;
}
}
@@ -156,7 +156,7 @@ handle_worker_shutdown(struct rte_distributor_v20 *d, unsigned int wkr)
* to do a partial flush.
*/
static int
-process_returns(struct rte_distributor_v20 *d)
+process_returns(struct rte_distributor_single *d)
{
unsigned wkr;
unsigned flushed = 0;
@@ -200,8 +200,8 @@ process_returns(struct rte_distributor_v20 *d)
}
/* process a set of packets to distribute them to workers */
-int __vsym
-rte_distributor_process_v20(struct rte_distributor_v20 *d,
+int
+rte_distributor_process_single(struct rte_distributor_single *d,
struct rte_mbuf **mbufs, unsigned num_mbufs)
{
unsigned next_idx = 0;
@@ -316,8 +316,8 @@ rte_distributor_process_v20(struct rte_distributor_v20 *d,
}
/* return to the caller, packets returned from workers */
-int __vsym
-rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
+int
+rte_distributor_returned_pkts_single(struct rte_distributor_single *d,
struct rte_mbuf **mbufs, unsigned max_mbufs)
{
struct rte_distributor_returned_pkts *returns = &d->returns;
@@ -339,7 +339,7 @@ rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
* being worked on or queued up in a backlog.
*/
static inline unsigned
-total_outstanding(const struct rte_distributor_v20 *d)
+total_outstanding(const struct rte_distributor_single *d)
{
unsigned wkr, total_outstanding;
@@ -353,20 +353,20 @@ total_outstanding(const struct rte_distributor_v20 *d)
/* flush the distributor, so that there are no outstanding packets in flight or
* queued up. */
-int __vsym
-rte_distributor_flush_v20(struct rte_distributor_v20 *d)
+int
+rte_distributor_flush_single(struct rte_distributor_single *d)
{
const unsigned flushed = total_outstanding(d);
while (total_outstanding(d) > 0)
- rte_distributor_process_v20(d, NULL, 0);
+ rte_distributor_process_single(d, NULL, 0);
return flushed;
}
/* clears the internal returns array in the distributor */
-void __vsym
-rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
+void
+rte_distributor_clear_returns_single(struct rte_distributor_single *d)
{
d->returns.start = d->returns.count = 0;
#ifndef __OPTIMIZE__
@@ -375,12 +375,12 @@ rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
}
/* creates a distributor instance */
-struct rte_distributor_v20 * __vsym
-rte_distributor_create_v20(const char *name,
+struct rte_distributor_single *
+rte_distributor_create_single(const char *name,
unsigned socket_id,
unsigned num_workers)
{
- struct rte_distributor_v20 *d;
+ struct rte_distributor_single *d;
struct rte_distributor_list *distributor_list;
char mz_name[RTE_MEMZONE_NAMESIZE];
const struct rte_memzone *mz;
diff --git a/lib/librte_distributor/rte_distributor_v20.h b/lib/librte_distributor/rte_distributor_single.h
similarity index 89%
rename from lib/librte_distributor/rte_distributor_v20.h
rename to lib/librte_distributor/rte_distributor_single.h
index 12865658ba..2f80aa43d1 100644
--- a/lib/librte_distributor/rte_distributor_v20.h
+++ b/lib/librte_distributor/rte_distributor_single.h
@@ -2,8 +2,8 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#ifndef _RTE_DISTRIB_V20_H_
-#define _RTE_DISTRIB_V20_H_
+#ifndef _RTE_DISTRIB_SINGLE_H_
+#define _RTE_DISTRIB_SINGLE_H_
/**
* @file
@@ -19,7 +19,7 @@ extern "C" {
#define RTE_DISTRIBUTOR_NAMESIZE 32 /**< Length of name for instance */
-struct rte_distributor_v20;
+struct rte_distributor_single;
struct rte_mbuf;
/**
@@ -38,8 +38,8 @@ struct rte_mbuf;
* @return
* The newly created distributor instance
*/
-struct rte_distributor_v20 *
-rte_distributor_create_v20(const char *name, unsigned int socket_id,
+struct rte_distributor_single *
+rte_distributor_create_single(const char *name, unsigned int socket_id,
unsigned int num_workers);
/* *** APIS to be called on the distributor lcore *** */
@@ -74,7 +74,7 @@ rte_distributor_create_v20(const char *name, unsigned int socket_id,
* The number of mbufs processed.
*/
int
-rte_distributor_process_v20(struct rte_distributor_v20 *d,
+rte_distributor_process_single(struct rte_distributor_single *d,
struct rte_mbuf **mbufs, unsigned int num_mbufs);
/**
@@ -92,7 +92,7 @@ rte_distributor_process_v20(struct rte_distributor_v20 *d,
* The number of mbufs returned in the mbufs array.
*/
int
-rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
+rte_distributor_returned_pkts_single(struct rte_distributor_single *d,
struct rte_mbuf **mbufs, unsigned int max_mbufs);
/**
@@ -107,7 +107,7 @@ rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
* The number of queued/in-flight packets that were completed by this call.
*/
int
-rte_distributor_flush_v20(struct rte_distributor_v20 *d);
+rte_distributor_flush_single(struct rte_distributor_single *d);
/**
* Clears the array of returned packets used as the source for the
@@ -119,7 +119,7 @@ rte_distributor_flush_v20(struct rte_distributor_v20 *d);
* The distributor instance to be used
*/
void
-rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d);
+rte_distributor_clear_returns_single(struct rte_distributor_single *d);
/* *** APIS to be called on the worker lcores *** */
/*
@@ -148,7 +148,7 @@ rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d);
* A new packet to be processed by the worker thread.
*/
struct rte_mbuf *
-rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
+rte_distributor_get_pkt_single(struct rte_distributor_single *d,
unsigned int worker_id, struct rte_mbuf *oldpkt);
/**
@@ -164,7 +164,7 @@ rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
* The previous packet being processed by the worker
*/
int
-rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
+rte_distributor_return_pkt_single(struct rte_distributor_single *d,
unsigned int worker_id, struct rte_mbuf *mbuf);
/**
@@ -188,7 +188,7 @@ rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
* The previous packet, if any, being processed by the worker
*/
void
-rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
+rte_distributor_request_pkt_single(struct rte_distributor_single *d,
unsigned int worker_id, struct rte_mbuf *oldpkt);
/**
@@ -208,7 +208,7 @@ rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
* packet is yet available.
*/
struct rte_mbuf *
-rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
+rte_distributor_poll_pkt_single(struct rte_distributor_single *d,
unsigned int worker_id);
#ifdef __cplusplus
diff --git a/lib/librte_distributor/rte_distributor_version.map b/lib/librte_distributor/rte_distributor_version.map
index 3a285b394e..00e26b4804 100644
--- a/lib/librte_distributor/rte_distributor_version.map
+++ b/lib/librte_distributor/rte_distributor_version.map
@@ -1,19 +1,3 @@
-DPDK_2.0 {
- global:
-
- rte_distributor_clear_returns;
- rte_distributor_create;
- rte_distributor_flush;
- rte_distributor_get_pkt;
- rte_distributor_poll_pkt;
- rte_distributor_process;
- rte_distributor_request_pkt;
- rte_distributor_return_pkt;
- rte_distributor_returned_pkts;
-
- local: *;
-};
-
DPDK_17.05 {
global:
@@ -26,4 +10,4 @@ DPDK_17.05 {
rte_distributor_request_pkt;
rte_distributor_return_pkt;
rte_distributor_returned_pkts;
-} DPDK_2.0;
+};
--
2.17.1
^ permalink raw reply [relevance 6%]
* [dpdk-dev] [PATCH v7 06/10] distributor: remove deprecated code
2019-11-06 16:54 8% ` [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
` (5 preceding siblings ...)
2019-11-08 16:25 2% ` [dpdk-dev] [PATCH v7 05/10] lpm: " Anatoly Burakov
@ 2019-11-08 16:25 4% ` Anatoly Burakov
2019-11-08 16:25 6% ` [dpdk-dev] [PATCH v7 07/10] distributor: rename v2.0 ABI to _single suffix Anatoly Burakov
` (3 subsequent siblings)
10 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-08 16:25 UTC (permalink / raw)
To: dev
Cc: Marcin Baran, David Hunt, john.mcnamara, ray.kinsella,
bruce.richardson, thomas, david.marchand
From: Marcin Baran <marcinx.baran@intel.com>
Remove code for old ABI versions ahead of ABI version bump.
Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: David Hunt <david.hunt@intel.com>
---
Notes:
v5:
- Fixed shared library linking error due to versioning still enabled
v2:
- Moved this to before ABI version bump to avoid compile breakage
v2:
- Moved this to before ABI version bump to avoid compile breakage
lib/librte_distributor/rte_distributor.c | 74 +++++--------------
.../rte_distributor_v1705.h | 61 ---------------
lib/librte_distributor/rte_distributor_v20.c | 9 ---
3 files changed, 18 insertions(+), 126 deletions(-)
delete mode 100644 lib/librte_distributor/rte_distributor_v1705.h
diff --git a/lib/librte_distributor/rte_distributor.c b/lib/librte_distributor/rte_distributor.c
index 2cc32ddba2..a4c8ff6a96 100644
--- a/lib/librte_distributor/rte_distributor.c
+++ b/lib/librte_distributor/rte_distributor.c
@@ -18,7 +18,6 @@
#include "rte_distributor.h"
#include "rte_distributor_v20.h"
-#include "rte_distributor_v1705.h"
#include "distributor_private.h"
TAILQ_HEAD(rte_dist_burst_list, rte_distributor);
@@ -32,8 +31,8 @@ EAL_REGISTER_TAILQ(rte_dist_burst_tailq)
/**** Burst Packet APIs called by workers ****/
-void __vsym
-rte_distributor_request_pkt_v1705(struct rte_distributor *d,
+void
+rte_distributor_request_pkt(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **oldpkt,
unsigned int count)
{
@@ -83,14 +82,9 @@ rte_distributor_request_pkt_v1705(struct rte_distributor *d,
__atomic_store_n(retptr64, *retptr64 | RTE_DISTRIB_GET_BUF,
__ATOMIC_RELEASE);
}
-BIND_DEFAULT_SYMBOL(rte_distributor_request_pkt, _v1705, 17.05);
-MAP_STATIC_SYMBOL(void rte_distributor_request_pkt(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **oldpkt,
- unsigned int count),
- rte_distributor_request_pkt_v1705);
-int __vsym
-rte_distributor_poll_pkt_v1705(struct rte_distributor *d,
+int
+rte_distributor_poll_pkt(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **pkts)
{
struct rte_distributor_buffer *buf = &d->bufs[worker_id];
@@ -129,13 +123,9 @@ rte_distributor_poll_pkt_v1705(struct rte_distributor *d,
return count;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_poll_pkt, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_distributor_poll_pkt(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **pkts),
- rte_distributor_poll_pkt_v1705);
-int __vsym
-rte_distributor_get_pkt_v1705(struct rte_distributor *d,
+int
+rte_distributor_get_pkt(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **pkts,
struct rte_mbuf **oldpkt, unsigned int return_count)
{
@@ -163,14 +153,9 @@ rte_distributor_get_pkt_v1705(struct rte_distributor *d,
}
return count;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_get_pkt, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_distributor_get_pkt(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **pkts,
- struct rte_mbuf **oldpkt, unsigned int return_count),
- rte_distributor_get_pkt_v1705);
-int __vsym
-rte_distributor_return_pkt_v1705(struct rte_distributor *d,
+int
+rte_distributor_return_pkt(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **oldpkt, int num)
{
struct rte_distributor_buffer *buf = &d->bufs[worker_id];
@@ -202,10 +187,6 @@ rte_distributor_return_pkt_v1705(struct rte_distributor *d,
return 0;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_return_pkt, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_distributor_return_pkt(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **oldpkt, int num),
- rte_distributor_return_pkt_v1705);
/**** APIs called on distributor core ***/
@@ -359,8 +340,8 @@ release(struct rte_distributor *d, unsigned int wkr)
/* process a set of packets to distribute them to workers */
-int __vsym
-rte_distributor_process_v1705(struct rte_distributor *d,
+int
+rte_distributor_process(struct rte_distributor *d,
struct rte_mbuf **mbufs, unsigned int num_mbufs)
{
unsigned int next_idx = 0;
@@ -500,14 +481,10 @@ rte_distributor_process_v1705(struct rte_distributor *d,
return num_mbufs;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_process, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_distributor_process(struct rte_distributor *d,
- struct rte_mbuf **mbufs, unsigned int num_mbufs),
- rte_distributor_process_v1705);
/* return to the caller, packets returned from workers */
-int __vsym
-rte_distributor_returned_pkts_v1705(struct rte_distributor *d,
+int
+rte_distributor_returned_pkts(struct rte_distributor *d,
struct rte_mbuf **mbufs, unsigned int max_mbufs)
{
struct rte_distributor_returned_pkts *returns = &d->returns;
@@ -532,10 +509,6 @@ rte_distributor_returned_pkts_v1705(struct rte_distributor *d,
return retval;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_returned_pkts, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_distributor_returned_pkts(struct rte_distributor *d,
- struct rte_mbuf **mbufs, unsigned int max_mbufs),
- rte_distributor_returned_pkts_v1705);
/*
* Return the number of packets in-flight in a distributor, i.e. packets
@@ -556,8 +529,8 @@ total_outstanding(const struct rte_distributor *d)
* Flush the distributor, so that there are no outstanding packets in flight or
* queued up.
*/
-int __vsym
-rte_distributor_flush_v1705(struct rte_distributor *d)
+int
+rte_distributor_flush(struct rte_distributor *d)
{
unsigned int flushed;
unsigned int wkr;
@@ -586,13 +559,10 @@ rte_distributor_flush_v1705(struct rte_distributor *d)
return flushed;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_flush, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_distributor_flush(struct rte_distributor *d),
- rte_distributor_flush_v1705);
/* clears the internal returns array in the distributor */
-void __vsym
-rte_distributor_clear_returns_v1705(struct rte_distributor *d)
+void
+rte_distributor_clear_returns(struct rte_distributor *d)
{
unsigned int wkr;
@@ -608,13 +578,10 @@ rte_distributor_clear_returns_v1705(struct rte_distributor *d)
__atomic_store_n(&(d->bufs[wkr].retptr64[0]), 0,
__ATOMIC_RELEASE);
}
-BIND_DEFAULT_SYMBOL(rte_distributor_clear_returns, _v1705, 17.05);
-MAP_STATIC_SYMBOL(void rte_distributor_clear_returns(struct rte_distributor *d),
- rte_distributor_clear_returns_v1705);
/* creates a distributor instance */
-struct rte_distributor * __vsym
-rte_distributor_create_v1705(const char *name,
+struct rte_distributor *
+rte_distributor_create(const char *name,
unsigned int socket_id,
unsigned int num_workers,
unsigned int alg_type)
@@ -688,8 +655,3 @@ rte_distributor_create_v1705(const char *name,
return d;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_create, _v1705, 17.05);
-MAP_STATIC_SYMBOL(struct rte_distributor *rte_distributor_create(
- const char *name, unsigned int socket_id,
- unsigned int num_workers, unsigned int alg_type),
- rte_distributor_create_v1705);
diff --git a/lib/librte_distributor/rte_distributor_v1705.h b/lib/librte_distributor/rte_distributor_v1705.h
deleted file mode 100644
index df4d9e8150..0000000000
--- a/lib/librte_distributor/rte_distributor_v1705.h
+++ /dev/null
@@ -1,61 +0,0 @@
-/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2017 Intel Corporation
- */
-
-#ifndef _RTE_DISTRIB_V1705_H_
-#define _RTE_DISTRIB_V1705_H_
-
-/**
- * @file
- * RTE distributor
- *
- * The distributor is a component which is designed to pass packets
- * one-at-a-time to workers, with dynamic load balancing.
- */
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-struct rte_distributor *
-rte_distributor_create_v1705(const char *name, unsigned int socket_id,
- unsigned int num_workers,
- unsigned int alg_type);
-
-int
-rte_distributor_process_v1705(struct rte_distributor *d,
- struct rte_mbuf **mbufs, unsigned int num_mbufs);
-
-int
-rte_distributor_returned_pkts_v1705(struct rte_distributor *d,
- struct rte_mbuf **mbufs, unsigned int max_mbufs);
-
-int
-rte_distributor_flush_v1705(struct rte_distributor *d);
-
-void
-rte_distributor_clear_returns_v1705(struct rte_distributor *d);
-
-int
-rte_distributor_get_pkt_v1705(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **pkts,
- struct rte_mbuf **oldpkt, unsigned int retcount);
-
-int
-rte_distributor_return_pkt_v1705(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **oldpkt, int num);
-
-void
-rte_distributor_request_pkt_v1705(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **oldpkt,
- unsigned int count);
-
-int
-rte_distributor_poll_pkt_v1705(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **mbufs);
-
-#ifdef __cplusplus
-}
-#endif
-
-#endif
diff --git a/lib/librte_distributor/rte_distributor_v20.c b/lib/librte_distributor/rte_distributor_v20.c
index 7a6fddf556..655944bdb3 100644
--- a/lib/librte_distributor/rte_distributor_v20.c
+++ b/lib/librte_distributor/rte_distributor_v20.c
@@ -41,7 +41,6 @@ rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
/* Sync with distributor on GET_BUF flag. */
__atomic_store_n(&(buf->bufptr64), req, __ATOMIC_RELEASE);
}
-VERSION_SYMBOL(rte_distributor_request_pkt, _v20, 2.0);
struct rte_mbuf * __vsym
rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
@@ -57,7 +56,6 @@ rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
int64_t ret = buf->bufptr64 >> RTE_DISTRIB_FLAG_BITS;
return (struct rte_mbuf *)((uintptr_t)ret);
}
-VERSION_SYMBOL(rte_distributor_poll_pkt, _v20, 2.0);
struct rte_mbuf * __vsym
rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
@@ -69,7 +67,6 @@ rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
rte_pause();
return ret;
}
-VERSION_SYMBOL(rte_distributor_get_pkt, _v20, 2.0);
int __vsym
rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
@@ -82,7 +79,6 @@ rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
__atomic_store_n(&(buf->bufptr64), req, __ATOMIC_RELEASE);
return 0;
}
-VERSION_SYMBOL(rte_distributor_return_pkt, _v20, 2.0);
/**** APIs called on distributor core ***/
@@ -318,7 +314,6 @@ rte_distributor_process_v20(struct rte_distributor_v20 *d,
d->returns.count = ret_count;
return num_mbufs;
}
-VERSION_SYMBOL(rte_distributor_process, _v20, 2.0);
/* return to the caller, packets returned from workers */
int __vsym
@@ -339,7 +334,6 @@ rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
return retval;
}
-VERSION_SYMBOL(rte_distributor_returned_pkts, _v20, 2.0);
/* return the number of packets in-flight in a distributor, i.e. packets
* being worked on or queued up in a backlog.
@@ -369,7 +363,6 @@ rte_distributor_flush_v20(struct rte_distributor_v20 *d)
return flushed;
}
-VERSION_SYMBOL(rte_distributor_flush, _v20, 2.0);
/* clears the internal returns array in the distributor */
void __vsym
@@ -380,7 +373,6 @@ rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
memset(d->returns.mbufs, 0, sizeof(d->returns.mbufs));
#endif
}
-VERSION_SYMBOL(rte_distributor_clear_returns, _v20, 2.0);
/* creates a distributor instance */
struct rte_distributor_v20 * __vsym
@@ -424,4 +416,3 @@ rte_distributor_create_v20(const char *name,
return d;
}
-VERSION_SYMBOL(rte_distributor_create, _v20, 2.0);
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v7 05/10] lpm: remove deprecated code
2019-11-06 16:54 8% ` [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
` (4 preceding siblings ...)
2019-11-08 16:25 4% ` [dpdk-dev] [PATCH v7 04/10] timer: remove deprecated code Anatoly Burakov
@ 2019-11-08 16:25 2% ` Anatoly Burakov
2019-11-08 16:25 4% ` [dpdk-dev] [PATCH v7 06/10] distributor: " Anatoly Burakov
` (4 subsequent siblings)
10 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-08 16:25 UTC (permalink / raw)
To: dev
Cc: Marcin Baran, Bruce Richardson, Vladimir Medvedkin,
john.mcnamara, ray.kinsella, thomas, david.marchand
From: Marcin Baran <marcinx.baran@intel.com>
Remove code for old ABI versions ahead of ABI version bump.
Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
Notes:
v2:
- Moved this to before ABI version bump to avoid compile breakage
lib/librte_lpm/rte_lpm.c | 1010 ++-----------------------------------
lib/librte_lpm/rte_lpm.h | 88 ----
lib/librte_lpm/rte_lpm6.c | 140 +----
lib/librte_lpm/rte_lpm6.h | 25 -
4 files changed, 59 insertions(+), 1204 deletions(-)
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index 106916dc82..b78c487447 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -90,34 +90,8 @@ depth_to_range(uint8_t depth)
/*
* Find an existing lpm table and return a pointer to it.
*/
-struct rte_lpm_v20 * __vsym
-rte_lpm_find_existing_v20(const char *name)
-{
- struct rte_lpm_v20 *l = NULL;
- struct rte_tailq_entry *te;
- struct rte_lpm_list *lpm_list;
-
- lpm_list = RTE_TAILQ_CAST(rte_lpm_tailq.head, rte_lpm_list);
-
- rte_mcfg_tailq_read_lock();
- TAILQ_FOREACH(te, lpm_list, next) {
- l = te->data;
- if (strncmp(name, l->name, RTE_LPM_NAMESIZE) == 0)
- break;
- }
- rte_mcfg_tailq_read_unlock();
-
- if (te == NULL) {
- rte_errno = ENOENT;
- return NULL;
- }
-
- return l;
-}
-VERSION_SYMBOL(rte_lpm_find_existing, _v20, 2.0);
-
-struct rte_lpm * __vsym
-rte_lpm_find_existing_v1604(const char *name)
+struct rte_lpm *
+rte_lpm_find_existing(const char *name)
{
struct rte_lpm *l = NULL;
struct rte_tailq_entry *te;
@@ -140,88 +114,12 @@ rte_lpm_find_existing_v1604(const char *name)
return l;
}
-BIND_DEFAULT_SYMBOL(rte_lpm_find_existing, _v1604, 16.04);
-MAP_STATIC_SYMBOL(struct rte_lpm *rte_lpm_find_existing(const char *name),
- rte_lpm_find_existing_v1604);
/*
* Allocates memory for LPM object
*/
-struct rte_lpm_v20 * __vsym
-rte_lpm_create_v20(const char *name, int socket_id, int max_rules,
- __rte_unused int flags)
-{
- char mem_name[RTE_LPM_NAMESIZE];
- struct rte_lpm_v20 *lpm = NULL;
- struct rte_tailq_entry *te;
- uint32_t mem_size;
- struct rte_lpm_list *lpm_list;
-
- lpm_list = RTE_TAILQ_CAST(rte_lpm_tailq.head, rte_lpm_list);
-
- RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl_entry_v20) != 2);
-
- /* Check user arguments. */
- if ((name == NULL) || (socket_id < -1) || (max_rules == 0)) {
- rte_errno = EINVAL;
- return NULL;
- }
-
- snprintf(mem_name, sizeof(mem_name), "LPM_%s", name);
-
- /* Determine the amount of memory to allocate. */
- mem_size = sizeof(*lpm) + (sizeof(lpm->rules_tbl[0]) * max_rules);
-
- rte_mcfg_tailq_write_lock();
-
- /* guarantee there's no existing */
- TAILQ_FOREACH(te, lpm_list, next) {
- lpm = te->data;
- if (strncmp(name, lpm->name, RTE_LPM_NAMESIZE) == 0)
- break;
- }
-
- if (te != NULL) {
- lpm = NULL;
- rte_errno = EEXIST;
- goto exit;
- }
-
- /* allocate tailq entry */
- te = rte_zmalloc("LPM_TAILQ_ENTRY", sizeof(*te), 0);
- if (te == NULL) {
- RTE_LOG(ERR, LPM, "Failed to allocate tailq entry\n");
- rte_errno = ENOMEM;
- goto exit;
- }
-
- /* Allocate memory to store the LPM data structures. */
- lpm = rte_zmalloc_socket(mem_name, mem_size,
- RTE_CACHE_LINE_SIZE, socket_id);
- if (lpm == NULL) {
- RTE_LOG(ERR, LPM, "LPM memory allocation failed\n");
- rte_free(te);
- rte_errno = ENOMEM;
- goto exit;
- }
-
- /* Save user arguments. */
- lpm->max_rules = max_rules;
- strlcpy(lpm->name, name, sizeof(lpm->name));
-
- te->data = lpm;
-
- TAILQ_INSERT_TAIL(lpm_list, te, next);
-
-exit:
- rte_mcfg_tailq_write_unlock();
-
- return lpm;
-}
-VERSION_SYMBOL(rte_lpm_create, _v20, 2.0);
-
-struct rte_lpm * __vsym
-rte_lpm_create_v1604(const char *name, int socket_id,
+struct rte_lpm *
+rte_lpm_create(const char *name, int socket_id,
const struct rte_lpm_config *config)
{
char mem_name[RTE_LPM_NAMESIZE];
@@ -321,45 +219,12 @@ rte_lpm_create_v1604(const char *name, int socket_id,
return lpm;
}
-BIND_DEFAULT_SYMBOL(rte_lpm_create, _v1604, 16.04);
-MAP_STATIC_SYMBOL(
- struct rte_lpm *rte_lpm_create(const char *name, int socket_id,
- const struct rte_lpm_config *config), rte_lpm_create_v1604);
/*
* Deallocates memory for given LPM table.
*/
-void __vsym
-rte_lpm_free_v20(struct rte_lpm_v20 *lpm)
-{
- struct rte_lpm_list *lpm_list;
- struct rte_tailq_entry *te;
-
- /* Check user arguments. */
- if (lpm == NULL)
- return;
-
- lpm_list = RTE_TAILQ_CAST(rte_lpm_tailq.head, rte_lpm_list);
-
- rte_mcfg_tailq_write_lock();
-
- /* find our tailq entry */
- TAILQ_FOREACH(te, lpm_list, next) {
- if (te->data == (void *) lpm)
- break;
- }
- if (te != NULL)
- TAILQ_REMOVE(lpm_list, te, next);
-
- rte_mcfg_tailq_write_unlock();
-
- rte_free(lpm);
- rte_free(te);
-}
-VERSION_SYMBOL(rte_lpm_free, _v20, 2.0);
-
-void __vsym
-rte_lpm_free_v1604(struct rte_lpm *lpm)
+void
+rte_lpm_free(struct rte_lpm *lpm)
{
struct rte_lpm_list *lpm_list;
struct rte_tailq_entry *te;
@@ -387,9 +252,6 @@ rte_lpm_free_v1604(struct rte_lpm *lpm)
rte_free(lpm);
rte_free(te);
}
-BIND_DEFAULT_SYMBOL(rte_lpm_free, _v1604, 16.04);
-MAP_STATIC_SYMBOL(void rte_lpm_free(struct rte_lpm *lpm),
- rte_lpm_free_v1604);
/*
* Adds a rule to the rule table.
@@ -402,79 +264,7 @@ MAP_STATIC_SYMBOL(void rte_lpm_free(struct rte_lpm *lpm),
* NOTE: Valid range for depth parameter is 1 .. 32 inclusive.
*/
static int32_t
-rule_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip_masked, uint8_t depth,
- uint8_t next_hop)
-{
- uint32_t rule_gindex, rule_index, last_rule;
- int i;
-
- VERIFY_DEPTH(depth);
-
- /* Scan through rule group to see if rule already exists. */
- if (lpm->rule_info[depth - 1].used_rules > 0) {
-
- /* rule_gindex stands for rule group index. */
- rule_gindex = lpm->rule_info[depth - 1].first_rule;
- /* Initialise rule_index to point to start of rule group. */
- rule_index = rule_gindex;
- /* Last rule = Last used rule in this rule group. */
- last_rule = rule_gindex + lpm->rule_info[depth - 1].used_rules;
-
- for (; rule_index < last_rule; rule_index++) {
-
- /* If rule already exists update its next_hop and return. */
- if (lpm->rules_tbl[rule_index].ip == ip_masked) {
- lpm->rules_tbl[rule_index].next_hop = next_hop;
-
- return rule_index;
- }
- }
-
- if (rule_index == lpm->max_rules)
- return -ENOSPC;
- } else {
- /* Calculate the position in which the rule will be stored. */
- rule_index = 0;
-
- for (i = depth - 1; i > 0; i--) {
- if (lpm->rule_info[i - 1].used_rules > 0) {
- rule_index = lpm->rule_info[i - 1].first_rule
- + lpm->rule_info[i - 1].used_rules;
- break;
- }
- }
- if (rule_index == lpm->max_rules)
- return -ENOSPC;
-
- lpm->rule_info[depth - 1].first_rule = rule_index;
- }
-
- /* Make room for the new rule in the array. */
- for (i = RTE_LPM_MAX_DEPTH; i > depth; i--) {
- if (lpm->rule_info[i - 1].first_rule
- + lpm->rule_info[i - 1].used_rules == lpm->max_rules)
- return -ENOSPC;
-
- if (lpm->rule_info[i - 1].used_rules > 0) {
- lpm->rules_tbl[lpm->rule_info[i - 1].first_rule
- + lpm->rule_info[i - 1].used_rules]
- = lpm->rules_tbl[lpm->rule_info[i - 1].first_rule];
- lpm->rule_info[i - 1].first_rule++;
- }
- }
-
- /* Add the new rule. */
- lpm->rules_tbl[rule_index].ip = ip_masked;
- lpm->rules_tbl[rule_index].next_hop = next_hop;
-
- /* Increment the used rules counter for this rule group. */
- lpm->rule_info[depth - 1].used_rules++;
-
- return rule_index;
-}
-
-static int32_t
-rule_add_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
+rule_add(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
uint32_t next_hop)
{
uint32_t rule_gindex, rule_index, last_rule;
@@ -550,30 +340,7 @@ rule_add_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
* NOTE: Valid range for depth parameter is 1 .. 32 inclusive.
*/
static void
-rule_delete_v20(struct rte_lpm_v20 *lpm, int32_t rule_index, uint8_t depth)
-{
- int i;
-
- VERIFY_DEPTH(depth);
-
- lpm->rules_tbl[rule_index] =
- lpm->rules_tbl[lpm->rule_info[depth - 1].first_rule
- + lpm->rule_info[depth - 1].used_rules - 1];
-
- for (i = depth; i < RTE_LPM_MAX_DEPTH; i++) {
- if (lpm->rule_info[i].used_rules > 0) {
- lpm->rules_tbl[lpm->rule_info[i].first_rule - 1] =
- lpm->rules_tbl[lpm->rule_info[i].first_rule
- + lpm->rule_info[i].used_rules - 1];
- lpm->rule_info[i].first_rule--;
- }
- }
-
- lpm->rule_info[depth - 1].used_rules--;
-}
-
-static void
-rule_delete_v1604(struct rte_lpm *lpm, int32_t rule_index, uint8_t depth)
+rule_delete(struct rte_lpm *lpm, int32_t rule_index, uint8_t depth)
{
int i;
@@ -600,28 +367,7 @@ rule_delete_v1604(struct rte_lpm *lpm, int32_t rule_index, uint8_t depth)
* NOTE: Valid range for depth parameter is 1 .. 32 inclusive.
*/
static int32_t
-rule_find_v20(struct rte_lpm_v20 *lpm, uint32_t ip_masked, uint8_t depth)
-{
- uint32_t rule_gindex, last_rule, rule_index;
-
- VERIFY_DEPTH(depth);
-
- rule_gindex = lpm->rule_info[depth - 1].first_rule;
- last_rule = rule_gindex + lpm->rule_info[depth - 1].used_rules;
-
- /* Scan used rules at given depth to find rule. */
- for (rule_index = rule_gindex; rule_index < last_rule; rule_index++) {
- /* If rule is found return the rule index. */
- if (lpm->rules_tbl[rule_index].ip == ip_masked)
- return rule_index;
- }
-
- /* If rule is not found return -EINVAL. */
- return -EINVAL;
-}
-
-static int32_t
-rule_find_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth)
+rule_find(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth)
{
uint32_t rule_gindex, last_rule, rule_index;
@@ -645,42 +391,7 @@ rule_find_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth)
* Find, clean and allocate a tbl8.
*/
static int32_t
-tbl8_alloc_v20(struct rte_lpm_tbl_entry_v20 *tbl8)
-{
- uint32_t group_idx; /* tbl8 group index. */
- struct rte_lpm_tbl_entry_v20 *tbl8_entry;
-
- /* Scan through tbl8 to find a free (i.e. INVALID) tbl8 group. */
- for (group_idx = 0; group_idx < RTE_LPM_TBL8_NUM_GROUPS;
- group_idx++) {
- tbl8_entry = &tbl8[group_idx * RTE_LPM_TBL8_GROUP_NUM_ENTRIES];
- /* If a free tbl8 group is found clean it and set as VALID. */
- if (!tbl8_entry->valid_group) {
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = INVALID,
- .depth = 0,
- .valid_group = VALID,
- };
- new_tbl8_entry.next_hop = 0;
-
- memset(&tbl8_entry[0], 0,
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES *
- sizeof(tbl8_entry[0]));
-
- __atomic_store(tbl8_entry, &new_tbl8_entry,
- __ATOMIC_RELAXED);
-
- /* Return group index for allocated tbl8 group. */
- return group_idx;
- }
- }
-
- /* If there are no tbl8 groups free then return error. */
- return -ENOSPC;
-}
-
-static int32_t
-tbl8_alloc_v1604(struct rte_lpm_tbl_entry *tbl8, uint32_t number_tbl8s)
+tbl8_alloc(struct rte_lpm_tbl_entry *tbl8, uint32_t number_tbl8s)
{
uint32_t group_idx; /* tbl8 group index. */
struct rte_lpm_tbl_entry *tbl8_entry;
@@ -714,22 +425,7 @@ tbl8_alloc_v1604(struct rte_lpm_tbl_entry *tbl8, uint32_t number_tbl8s)
}
static void
-tbl8_free_v20(struct rte_lpm_tbl_entry_v20 *tbl8, uint32_t tbl8_group_start)
-{
- /* Set tbl8 group invalid*/
- struct rte_lpm_tbl_entry_v20 zero_tbl8_entry = {
- .valid = INVALID,
- .depth = 0,
- .valid_group = INVALID,
- };
- zero_tbl8_entry.next_hop = 0;
-
- __atomic_store(&tbl8[tbl8_group_start], &zero_tbl8_entry,
- __ATOMIC_RELAXED);
-}
-
-static void
-tbl8_free_v1604(struct rte_lpm_tbl_entry *tbl8, uint32_t tbl8_group_start)
+tbl8_free(struct rte_lpm_tbl_entry *tbl8, uint32_t tbl8_group_start)
{
/* Set tbl8 group invalid*/
struct rte_lpm_tbl_entry zero_tbl8_entry = {0};
@@ -739,78 +435,7 @@ tbl8_free_v1604(struct rte_lpm_tbl_entry *tbl8, uint32_t tbl8_group_start)
}
static __rte_noinline int32_t
-add_depth_small_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
- uint8_t next_hop)
-{
- uint32_t tbl24_index, tbl24_range, tbl8_index, tbl8_group_end, i, j;
-
- /* Calculate the index into Table24. */
- tbl24_index = ip >> 8;
- tbl24_range = depth_to_range(depth);
-
- for (i = tbl24_index; i < (tbl24_index + tbl24_range); i++) {
- /*
- * For invalid OR valid and non-extended tbl 24 entries set
- * entry.
- */
- if (!lpm->tbl24[i].valid || (lpm->tbl24[i].valid_group == 0 &&
- lpm->tbl24[i].depth <= depth)) {
-
- struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- .valid = VALID,
- .valid_group = 0,
- .depth = depth,
- };
- new_tbl24_entry.next_hop = next_hop;
-
- /* Setting tbl24 entry in one go to avoid race
- * conditions
- */
- __atomic_store(&lpm->tbl24[i], &new_tbl24_entry,
- __ATOMIC_RELEASE);
-
- continue;
- }
-
- if (lpm->tbl24[i].valid_group == 1) {
- /* If tbl24 entry is valid and extended calculate the
- * index into tbl8.
- */
- tbl8_index = lpm->tbl24[i].group_idx *
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
- tbl8_group_end = tbl8_index +
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
-
- for (j = tbl8_index; j < tbl8_group_end; j++) {
- if (!lpm->tbl8[j].valid ||
- lpm->tbl8[j].depth <= depth) {
- struct rte_lpm_tbl_entry_v20
- new_tbl8_entry = {
- .valid = VALID,
- .valid_group = VALID,
- .depth = depth,
- };
- new_tbl8_entry.next_hop = next_hop;
-
- /*
- * Setting tbl8 entry in one go to avoid
- * race conditions
- */
- __atomic_store(&lpm->tbl8[j],
- &new_tbl8_entry,
- __ATOMIC_RELAXED);
-
- continue;
- }
- }
- }
- }
-
- return 0;
-}
-
-static __rte_noinline int32_t
-add_depth_small_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
+add_depth_small(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t next_hop)
{
#define group_idx next_hop
@@ -882,150 +507,7 @@ add_depth_small_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
}
static __rte_noinline int32_t
-add_depth_big_v20(struct rte_lpm_v20 *lpm, uint32_t ip_masked, uint8_t depth,
- uint8_t next_hop)
-{
- uint32_t tbl24_index;
- int32_t tbl8_group_index, tbl8_group_start, tbl8_group_end, tbl8_index,
- tbl8_range, i;
-
- tbl24_index = (ip_masked >> 8);
- tbl8_range = depth_to_range(depth);
-
- if (!lpm->tbl24[tbl24_index].valid) {
- /* Search for a free tbl8 group. */
- tbl8_group_index = tbl8_alloc_v20(lpm->tbl8);
-
- /* Check tbl8 allocation was successful. */
- if (tbl8_group_index < 0) {
- return tbl8_group_index;
- }
-
- /* Find index into tbl8 and range. */
- tbl8_index = (tbl8_group_index *
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES) +
- (ip_masked & 0xFF);
-
- /* Set tbl8 entry. */
- for (i = tbl8_index; i < (tbl8_index + tbl8_range); i++) {
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = VALID,
- .depth = depth,
- .valid_group = lpm->tbl8[i].valid_group,
- };
- new_tbl8_entry.next_hop = next_hop;
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
- __ATOMIC_RELAXED);
- }
-
- /*
- * Update tbl24 entry to point to new tbl8 entry. Note: The
- * ext_flag and tbl8_index need to be updated simultaneously,
- * so assign whole structure in one go
- */
-
- struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- .group_idx = (uint8_t)tbl8_group_index,
- .valid = VALID,
- .valid_group = 1,
- .depth = 0,
- };
-
- __atomic_store(&lpm->tbl24[tbl24_index], &new_tbl24_entry,
- __ATOMIC_RELEASE);
-
- } /* If valid entry but not extended calculate the index into Table8. */
- else if (lpm->tbl24[tbl24_index].valid_group == 0) {
- /* Search for free tbl8 group. */
- tbl8_group_index = tbl8_alloc_v20(lpm->tbl8);
-
- if (tbl8_group_index < 0) {
- return tbl8_group_index;
- }
-
- tbl8_group_start = tbl8_group_index *
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
- tbl8_group_end = tbl8_group_start +
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
-
- /* Populate new tbl8 with tbl24 value. */
- for (i = tbl8_group_start; i < tbl8_group_end; i++) {
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = VALID,
- .depth = lpm->tbl24[tbl24_index].depth,
- .valid_group = lpm->tbl8[i].valid_group,
- };
- new_tbl8_entry.next_hop =
- lpm->tbl24[tbl24_index].next_hop;
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
- __ATOMIC_RELAXED);
- }
-
- tbl8_index = tbl8_group_start + (ip_masked & 0xFF);
-
- /* Insert new rule into the tbl8 entry. */
- for (i = tbl8_index; i < tbl8_index + tbl8_range; i++) {
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = VALID,
- .depth = depth,
- .valid_group = lpm->tbl8[i].valid_group,
- };
- new_tbl8_entry.next_hop = next_hop;
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
- __ATOMIC_RELAXED);
- }
-
- /*
- * Update tbl24 entry to point to new tbl8 entry. Note: The
- * ext_flag and tbl8_index need to be updated simultaneously,
- * so assign whole structure in one go.
- */
-
- struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- .group_idx = (uint8_t)tbl8_group_index,
- .valid = VALID,
- .valid_group = 1,
- .depth = 0,
- };
-
- __atomic_store(&lpm->tbl24[tbl24_index], &new_tbl24_entry,
- __ATOMIC_RELEASE);
-
- } else { /*
- * If it is valid, extended entry calculate the index into tbl8.
- */
- tbl8_group_index = lpm->tbl24[tbl24_index].group_idx;
- tbl8_group_start = tbl8_group_index *
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
- tbl8_index = tbl8_group_start + (ip_masked & 0xFF);
-
- for (i = tbl8_index; i < (tbl8_index + tbl8_range); i++) {
-
- if (!lpm->tbl8[i].valid ||
- lpm->tbl8[i].depth <= depth) {
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = VALID,
- .depth = depth,
- .valid_group = lpm->tbl8[i].valid_group,
- };
- new_tbl8_entry.next_hop = next_hop;
- /*
- * Setting tbl8 entry in one go to avoid race
- * condition
- */
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
- __ATOMIC_RELAXED);
-
- continue;
- }
- }
- }
-
- return 0;
-}
-
-static __rte_noinline int32_t
-add_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
+add_depth_big(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
uint32_t next_hop)
{
#define group_idx next_hop
@@ -1038,7 +520,7 @@ add_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
if (!lpm->tbl24[tbl24_index].valid) {
/* Search for a free tbl8 group. */
- tbl8_group_index = tbl8_alloc_v1604(lpm->tbl8, lpm->number_tbl8s);
+ tbl8_group_index = tbl8_alloc(lpm->tbl8, lpm->number_tbl8s);
/* Check tbl8 allocation was successful. */
if (tbl8_group_index < 0) {
@@ -1084,7 +566,7 @@ add_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
} /* If valid entry but not extended calculate the index into Table8. */
else if (lpm->tbl24[tbl24_index].valid_group == 0) {
/* Search for free tbl8 group. */
- tbl8_group_index = tbl8_alloc_v1604(lpm->tbl8, lpm->number_tbl8s);
+ tbl8_group_index = tbl8_alloc(lpm->tbl8, lpm->number_tbl8s);
if (tbl8_group_index < 0) {
return tbl8_group_index;
@@ -1177,49 +659,8 @@ add_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
/*
* Add a route
*/
-int __vsym
-rte_lpm_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
- uint8_t next_hop)
-{
- int32_t rule_index, status = 0;
- uint32_t ip_masked;
-
- /* Check user arguments. */
- if ((lpm == NULL) || (depth < 1) || (depth > RTE_LPM_MAX_DEPTH))
- return -EINVAL;
-
- ip_masked = ip & depth_to_mask(depth);
-
- /* Add the rule to the rule table. */
- rule_index = rule_add_v20(lpm, ip_masked, depth, next_hop);
-
- /* If the is no space available for new rule return error. */
- if (rule_index < 0) {
- return rule_index;
- }
-
- if (depth <= MAX_DEPTH_TBL24) {
- status = add_depth_small_v20(lpm, ip_masked, depth, next_hop);
- } else { /* If depth > RTE_LPM_MAX_DEPTH_TBL24 */
- status = add_depth_big_v20(lpm, ip_masked, depth, next_hop);
-
- /*
- * If add fails due to exhaustion of tbl8 extensions delete
- * rule that was added to rule table.
- */
- if (status < 0) {
- rule_delete_v20(lpm, rule_index, depth);
-
- return status;
- }
- }
-
- return 0;
-}
-VERSION_SYMBOL(rte_lpm_add, _v20, 2.0);
-
-int __vsym
-rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
+int
+rte_lpm_add(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t next_hop)
{
int32_t rule_index, status = 0;
@@ -1232,7 +673,7 @@ rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
ip_masked = ip & depth_to_mask(depth);
/* Add the rule to the rule table. */
- rule_index = rule_add_v1604(lpm, ip_masked, depth, next_hop);
+ rule_index = rule_add(lpm, ip_masked, depth, next_hop);
/* If the is no space available for new rule return error. */
if (rule_index < 0) {
@@ -1240,16 +681,16 @@ rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
}
if (depth <= MAX_DEPTH_TBL24) {
- status = add_depth_small_v1604(lpm, ip_masked, depth, next_hop);
+ status = add_depth_small(lpm, ip_masked, depth, next_hop);
} else { /* If depth > RTE_LPM_MAX_DEPTH_TBL24 */
- status = add_depth_big_v1604(lpm, ip_masked, depth, next_hop);
+ status = add_depth_big(lpm, ip_masked, depth, next_hop);
/*
* If add fails due to exhaustion of tbl8 extensions delete
* rule that was added to rule table.
*/
if (status < 0) {
- rule_delete_v1604(lpm, rule_index, depth);
+ rule_delete(lpm, rule_index, depth);
return status;
}
@@ -1257,42 +698,12 @@ rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
return 0;
}
-BIND_DEFAULT_SYMBOL(rte_lpm_add, _v1604, 16.04);
-MAP_STATIC_SYMBOL(int rte_lpm_add(struct rte_lpm *lpm, uint32_t ip,
- uint8_t depth, uint32_t next_hop), rte_lpm_add_v1604);
/*
* Look for a rule in the high-level rules table
*/
-int __vsym
-rte_lpm_is_rule_present_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
-uint8_t *next_hop)
-{
- uint32_t ip_masked;
- int32_t rule_index;
-
- /* Check user arguments. */
- if ((lpm == NULL) ||
- (next_hop == NULL) ||
- (depth < 1) || (depth > RTE_LPM_MAX_DEPTH))
- return -EINVAL;
-
- /* Look for the rule using rule_find. */
- ip_masked = ip & depth_to_mask(depth);
- rule_index = rule_find_v20(lpm, ip_masked, depth);
-
- if (rule_index >= 0) {
- *next_hop = lpm->rules_tbl[rule_index].next_hop;
- return 1;
- }
-
- /* If rule is not found return 0. */
- return 0;
-}
-VERSION_SYMBOL(rte_lpm_is_rule_present, _v20, 2.0);
-
-int __vsym
-rte_lpm_is_rule_present_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
+int
+rte_lpm_is_rule_present(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t *next_hop)
{
uint32_t ip_masked;
@@ -1306,7 +717,7 @@ uint32_t *next_hop)
/* Look for the rule using rule_find. */
ip_masked = ip & depth_to_mask(depth);
- rule_index = rule_find_v1604(lpm, ip_masked, depth);
+ rule_index = rule_find(lpm, ip_masked, depth);
if (rule_index >= 0) {
*next_hop = lpm->rules_tbl[rule_index].next_hop;
@@ -1316,12 +727,9 @@ uint32_t *next_hop)
/* If rule is not found return 0. */
return 0;
}
-BIND_DEFAULT_SYMBOL(rte_lpm_is_rule_present, _v1604, 16.04);
-MAP_STATIC_SYMBOL(int rte_lpm_is_rule_present(struct rte_lpm *lpm, uint32_t ip,
- uint8_t depth, uint32_t *next_hop), rte_lpm_is_rule_present_v1604);
static int32_t
-find_previous_rule_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
+find_previous_rule(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint8_t *sub_rule_depth)
{
int32_t rule_index;
@@ -1331,7 +739,7 @@ find_previous_rule_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
for (prev_depth = (uint8_t)(depth - 1); prev_depth > 0; prev_depth--) {
ip_masked = ip & depth_to_mask(prev_depth);
- rule_index = rule_find_v20(lpm, ip_masked, prev_depth);
+ rule_index = rule_find(lpm, ip_masked, prev_depth);
if (rule_index >= 0) {
*sub_rule_depth = prev_depth;
@@ -1343,133 +751,7 @@ find_previous_rule_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
}
static int32_t
-find_previous_rule_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
- uint8_t *sub_rule_depth)
-{
- int32_t rule_index;
- uint32_t ip_masked;
- uint8_t prev_depth;
-
- for (prev_depth = (uint8_t)(depth - 1); prev_depth > 0; prev_depth--) {
- ip_masked = ip & depth_to_mask(prev_depth);
-
- rule_index = rule_find_v1604(lpm, ip_masked, prev_depth);
-
- if (rule_index >= 0) {
- *sub_rule_depth = prev_depth;
- return rule_index;
- }
- }
-
- return -1;
-}
-
-static int32_t
-delete_depth_small_v20(struct rte_lpm_v20 *lpm, uint32_t ip_masked,
- uint8_t depth, int32_t sub_rule_index, uint8_t sub_rule_depth)
-{
- uint32_t tbl24_range, tbl24_index, tbl8_group_index, tbl8_index, i, j;
-
- /* Calculate the range and index into Table24. */
- tbl24_range = depth_to_range(depth);
- tbl24_index = (ip_masked >> 8);
-
- /*
- * Firstly check the sub_rule_index. A -1 indicates no replacement rule
- * and a positive number indicates a sub_rule_index.
- */
- if (sub_rule_index < 0) {
- /*
- * If no replacement rule exists then invalidate entries
- * associated with this rule.
- */
- for (i = tbl24_index; i < (tbl24_index + tbl24_range); i++) {
-
- if (lpm->tbl24[i].valid_group == 0 &&
- lpm->tbl24[i].depth <= depth) {
- struct rte_lpm_tbl_entry_v20
- zero_tbl24_entry = {
- .valid = INVALID,
- .depth = 0,
- .valid_group = 0,
- };
- zero_tbl24_entry.next_hop = 0;
- __atomic_store(&lpm->tbl24[i],
- &zero_tbl24_entry, __ATOMIC_RELEASE);
- } else if (lpm->tbl24[i].valid_group == 1) {
- /*
- * If TBL24 entry is extended, then there has
- * to be a rule with depth >= 25 in the
- * associated TBL8 group.
- */
-
- tbl8_group_index = lpm->tbl24[i].group_idx;
- tbl8_index = tbl8_group_index *
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
-
- for (j = tbl8_index; j < (tbl8_index +
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES); j++) {
-
- if (lpm->tbl8[j].depth <= depth)
- lpm->tbl8[j].valid = INVALID;
- }
- }
- }
- } else {
- /*
- * If a replacement rule exists then modify entries
- * associated with this rule.
- */
-
- struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- .next_hop = lpm->rules_tbl[sub_rule_index].next_hop,
- .valid = VALID,
- .valid_group = 0,
- .depth = sub_rule_depth,
- };
-
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = VALID,
- .valid_group = VALID,
- .depth = sub_rule_depth,
- };
- new_tbl8_entry.next_hop =
- lpm->rules_tbl[sub_rule_index].next_hop;
-
- for (i = tbl24_index; i < (tbl24_index + tbl24_range); i++) {
-
- if (lpm->tbl24[i].valid_group == 0 &&
- lpm->tbl24[i].depth <= depth) {
- __atomic_store(&lpm->tbl24[i], &new_tbl24_entry,
- __ATOMIC_RELEASE);
- } else if (lpm->tbl24[i].valid_group == 1) {
- /*
- * If TBL24 entry is extended, then there has
- * to be a rule with depth >= 25 in the
- * associated TBL8 group.
- */
-
- tbl8_group_index = lpm->tbl24[i].group_idx;
- tbl8_index = tbl8_group_index *
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
-
- for (j = tbl8_index; j < (tbl8_index +
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES); j++) {
-
- if (lpm->tbl8[j].depth <= depth)
- __atomic_store(&lpm->tbl8[j],
- &new_tbl8_entry,
- __ATOMIC_RELAXED);
- }
- }
- }
- }
-
- return 0;
-}
-
-static int32_t
-delete_depth_small_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
+delete_depth_small(struct rte_lpm *lpm, uint32_t ip_masked,
uint8_t depth, int32_t sub_rule_index, uint8_t sub_rule_depth)
{
#define group_idx next_hop
@@ -1576,7 +858,7 @@ delete_depth_small_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
* thus can be recycled
*/
static int32_t
-tbl8_recycle_check_v20(struct rte_lpm_tbl_entry_v20 *tbl8,
+tbl8_recycle_check(struct rte_lpm_tbl_entry *tbl8,
uint32_t tbl8_group_start)
{
uint32_t tbl8_group_end, i;
@@ -1623,140 +905,7 @@ tbl8_recycle_check_v20(struct rte_lpm_tbl_entry_v20 *tbl8,
}
static int32_t
-tbl8_recycle_check_v1604(struct rte_lpm_tbl_entry *tbl8,
- uint32_t tbl8_group_start)
-{
- uint32_t tbl8_group_end, i;
- tbl8_group_end = tbl8_group_start + RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
-
- /*
- * Check the first entry of the given tbl8. If it is invalid we know
- * this tbl8 does not contain any rule with a depth < RTE_LPM_MAX_DEPTH
- * (As they would affect all entries in a tbl8) and thus this table
- * can not be recycled.
- */
- if (tbl8[tbl8_group_start].valid) {
- /*
- * If first entry is valid check if the depth is less than 24
- * and if so check the rest of the entries to verify that they
- * are all of this depth.
- */
- if (tbl8[tbl8_group_start].depth <= MAX_DEPTH_TBL24) {
- for (i = (tbl8_group_start + 1); i < tbl8_group_end;
- i++) {
-
- if (tbl8[i].depth !=
- tbl8[tbl8_group_start].depth) {
-
- return -EEXIST;
- }
- }
- /* If all entries are the same return the tb8 index */
- return tbl8_group_start;
- }
-
- return -EEXIST;
- }
- /*
- * If the first entry is invalid check if the rest of the entries in
- * the tbl8 are invalid.
- */
- for (i = (tbl8_group_start + 1); i < tbl8_group_end; i++) {
- if (tbl8[i].valid)
- return -EEXIST;
- }
- /* If no valid entries are found then return -EINVAL. */
- return -EINVAL;
-}
-
-static int32_t
-delete_depth_big_v20(struct rte_lpm_v20 *lpm, uint32_t ip_masked,
- uint8_t depth, int32_t sub_rule_index, uint8_t sub_rule_depth)
-{
- uint32_t tbl24_index, tbl8_group_index, tbl8_group_start, tbl8_index,
- tbl8_range, i;
- int32_t tbl8_recycle_index;
-
- /*
- * Calculate the index into tbl24 and range. Note: All depths larger
- * than MAX_DEPTH_TBL24 are associated with only one tbl24 entry.
- */
- tbl24_index = ip_masked >> 8;
-
- /* Calculate the index into tbl8 and range. */
- tbl8_group_index = lpm->tbl24[tbl24_index].group_idx;
- tbl8_group_start = tbl8_group_index * RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
- tbl8_index = tbl8_group_start + (ip_masked & 0xFF);
- tbl8_range = depth_to_range(depth);
-
- if (sub_rule_index < 0) {
- /*
- * Loop through the range of entries on tbl8 for which the
- * rule_to_delete must be removed or modified.
- */
- for (i = tbl8_index; i < (tbl8_index + tbl8_range); i++) {
- if (lpm->tbl8[i].depth <= depth)
- lpm->tbl8[i].valid = INVALID;
- }
- } else {
- /* Set new tbl8 entry. */
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = VALID,
- .depth = sub_rule_depth,
- .valid_group = lpm->tbl8[tbl8_group_start].valid_group,
- };
-
- new_tbl8_entry.next_hop =
- lpm->rules_tbl[sub_rule_index].next_hop;
- /*
- * Loop through the range of entries on tbl8 for which the
- * rule_to_delete must be modified.
- */
- for (i = tbl8_index; i < (tbl8_index + tbl8_range); i++) {
- if (lpm->tbl8[i].depth <= depth)
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
- __ATOMIC_RELAXED);
- }
- }
-
- /*
- * Check if there are any valid entries in this tbl8 group. If all
- * tbl8 entries are invalid we can free the tbl8 and invalidate the
- * associated tbl24 entry.
- */
-
- tbl8_recycle_index = tbl8_recycle_check_v20(lpm->tbl8, tbl8_group_start);
-
- if (tbl8_recycle_index == -EINVAL) {
- /* Set tbl24 before freeing tbl8 to avoid race condition.
- * Prevent the free of the tbl8 group from hoisting.
- */
- lpm->tbl24[tbl24_index].valid = 0;
- __atomic_thread_fence(__ATOMIC_RELEASE);
- tbl8_free_v20(lpm->tbl8, tbl8_group_start);
- } else if (tbl8_recycle_index > -1) {
- /* Update tbl24 entry. */
- struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- .next_hop = lpm->tbl8[tbl8_recycle_index].next_hop,
- .valid = VALID,
- .valid_group = 0,
- .depth = lpm->tbl8[tbl8_recycle_index].depth,
- };
-
- /* Set tbl24 before freeing tbl8 to avoid race condition.
- * Prevent the free of the tbl8 group from hoisting.
- */
- __atomic_store(&lpm->tbl24[tbl24_index], &new_tbl24_entry,
- __ATOMIC_RELAXED);
- __atomic_thread_fence(__ATOMIC_RELEASE);
- tbl8_free_v20(lpm->tbl8, tbl8_group_start);
- }
-
- return 0;
-}
-
-static int32_t
-delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
+delete_depth_big(struct rte_lpm *lpm, uint32_t ip_masked,
uint8_t depth, int32_t sub_rule_index, uint8_t sub_rule_depth)
{
#define group_idx next_hop
@@ -1811,7 +960,7 @@ delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
* associated tbl24 entry.
*/
- tbl8_recycle_index = tbl8_recycle_check_v1604(lpm->tbl8, tbl8_group_start);
+ tbl8_recycle_index = tbl8_recycle_check(lpm->tbl8, tbl8_group_start);
if (tbl8_recycle_index == -EINVAL) {
/* Set tbl24 before freeing tbl8 to avoid race condition.
@@ -1819,7 +968,7 @@ delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
*/
lpm->tbl24[tbl24_index].valid = 0;
__atomic_thread_fence(__ATOMIC_RELEASE);
- tbl8_free_v1604(lpm->tbl8, tbl8_group_start);
+ tbl8_free(lpm->tbl8, tbl8_group_start);
} else if (tbl8_recycle_index > -1) {
/* Update tbl24 entry. */
struct rte_lpm_tbl_entry new_tbl24_entry = {
@@ -1835,7 +984,7 @@ delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
__atomic_store(&lpm->tbl24[tbl24_index], &new_tbl24_entry,
__ATOMIC_RELAXED);
__atomic_thread_fence(__ATOMIC_RELEASE);
- tbl8_free_v1604(lpm->tbl8, tbl8_group_start);
+ tbl8_free(lpm->tbl8, tbl8_group_start);
}
#undef group_idx
return 0;
@@ -1844,8 +993,8 @@ delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
/*
* Deletes a rule
*/
-int __vsym
-rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
+int
+rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
{
int32_t rule_to_delete_index, sub_rule_index;
uint32_t ip_masked;
@@ -1864,7 +1013,7 @@ rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
* Find the index of the input rule, that needs to be deleted, in the
* rule table.
*/
- rule_to_delete_index = rule_find_v20(lpm, ip_masked, depth);
+ rule_to_delete_index = rule_find(lpm, ip_masked, depth);
/*
* Check if rule_to_delete_index was found. If no rule was found the
@@ -1874,7 +1023,7 @@ rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
return -EINVAL;
/* Delete the rule from the rule table. */
- rule_delete_v20(lpm, rule_to_delete_index, depth);
+ rule_delete(lpm, rule_to_delete_index, depth);
/*
* Find rule to replace the rule_to_delete. If there is no rule to
@@ -1882,100 +1031,26 @@ rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
* entries associated with this rule.
*/
sub_rule_depth = 0;
- sub_rule_index = find_previous_rule_v20(lpm, ip, depth, &sub_rule_depth);
+ sub_rule_index = find_previous_rule(lpm, ip, depth, &sub_rule_depth);
/*
* If the input depth value is less than 25 use function
* delete_depth_small otherwise use delete_depth_big.
*/
if (depth <= MAX_DEPTH_TBL24) {
- return delete_depth_small_v20(lpm, ip_masked, depth,
+ return delete_depth_small(lpm, ip_masked, depth,
sub_rule_index, sub_rule_depth);
} else { /* If depth > MAX_DEPTH_TBL24 */
- return delete_depth_big_v20(lpm, ip_masked, depth, sub_rule_index,
+ return delete_depth_big(lpm, ip_masked, depth, sub_rule_index,
sub_rule_depth);
}
}
-VERSION_SYMBOL(rte_lpm_delete, _v20, 2.0);
-
-int __vsym
-rte_lpm_delete_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
-{
- int32_t rule_to_delete_index, sub_rule_index;
- uint32_t ip_masked;
- uint8_t sub_rule_depth;
- /*
- * Check input arguments. Note: IP must be a positive integer of 32
- * bits in length therefore it need not be checked.
- */
- if ((lpm == NULL) || (depth < 1) || (depth > RTE_LPM_MAX_DEPTH)) {
- return -EINVAL;
- }
-
- ip_masked = ip & depth_to_mask(depth);
-
- /*
- * Find the index of the input rule, that needs to be deleted, in the
- * rule table.
- */
- rule_to_delete_index = rule_find_v1604(lpm, ip_masked, depth);
-
- /*
- * Check if rule_to_delete_index was found. If no rule was found the
- * function rule_find returns -EINVAL.
- */
- if (rule_to_delete_index < 0)
- return -EINVAL;
-
- /* Delete the rule from the rule table. */
- rule_delete_v1604(lpm, rule_to_delete_index, depth);
-
- /*
- * Find rule to replace the rule_to_delete. If there is no rule to
- * replace the rule_to_delete we return -1 and invalidate the table
- * entries associated with this rule.
- */
- sub_rule_depth = 0;
- sub_rule_index = find_previous_rule_v1604(lpm, ip, depth, &sub_rule_depth);
-
- /*
- * If the input depth value is less than 25 use function
- * delete_depth_small otherwise use delete_depth_big.
- */
- if (depth <= MAX_DEPTH_TBL24) {
- return delete_depth_small_v1604(lpm, ip_masked, depth,
- sub_rule_index, sub_rule_depth);
- } else { /* If depth > MAX_DEPTH_TBL24 */
- return delete_depth_big_v1604(lpm, ip_masked, depth, sub_rule_index,
- sub_rule_depth);
- }
-}
-BIND_DEFAULT_SYMBOL(rte_lpm_delete, _v1604, 16.04);
-MAP_STATIC_SYMBOL(int rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip,
- uint8_t depth), rte_lpm_delete_v1604);
/*
* Delete all rules from the LPM table.
*/
-void __vsym
-rte_lpm_delete_all_v20(struct rte_lpm_v20 *lpm)
-{
- /* Zero rule information. */
- memset(lpm->rule_info, 0, sizeof(lpm->rule_info));
-
- /* Zero tbl24. */
- memset(lpm->tbl24, 0, sizeof(lpm->tbl24));
-
- /* Zero tbl8. */
- memset(lpm->tbl8, 0, sizeof(lpm->tbl8));
-
- /* Delete all rules form the rules table. */
- memset(lpm->rules_tbl, 0, sizeof(lpm->rules_tbl[0]) * lpm->max_rules);
-}
-VERSION_SYMBOL(rte_lpm_delete_all, _v20, 2.0);
-
-void __vsym
-rte_lpm_delete_all_v1604(struct rte_lpm *lpm)
+void
+rte_lpm_delete_all(struct rte_lpm *lpm)
{
/* Zero rule information. */
memset(lpm->rule_info, 0, sizeof(lpm->rule_info));
@@ -1990,6 +1065,3 @@ rte_lpm_delete_all_v1604(struct rte_lpm *lpm)
/* Delete all rules form the rules table. */
memset(lpm->rules_tbl, 0, sizeof(lpm->rules_tbl[0]) * lpm->max_rules);
}
-BIND_DEFAULT_SYMBOL(rte_lpm_delete_all, _v1604, 16.04);
-MAP_STATIC_SYMBOL(void rte_lpm_delete_all(struct rte_lpm *lpm),
- rte_lpm_delete_all_v1604);
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index 26303e6288..b9d49ac879 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -64,31 +64,6 @@ extern "C" {
#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
/** @internal Tbl24 entry structure. */
-__extension__
-struct rte_lpm_tbl_entry_v20 {
- /**
- * Stores Next hop (tbl8 or tbl24 when valid_group is not set) or
- * a group index pointing to a tbl8 structure (tbl24 only, when
- * valid_group is set)
- */
- RTE_STD_C11
- union {
- uint8_t next_hop;
- uint8_t group_idx;
- };
- /* Using single uint8_t to store 3 values. */
- uint8_t valid :1; /**< Validation flag. */
- /**
- * For tbl24:
- * - valid_group == 0: entry stores a next hop
- * - valid_group == 1: entry stores a group_index pointing to a tbl8
- * For tbl8:
- * - valid_group indicates whether the current tbl8 is in use or not
- */
- uint8_t valid_group :1;
- uint8_t depth :6; /**< Rule depth. */
-} __rte_aligned(sizeof(uint16_t));
-
__extension__
struct rte_lpm_tbl_entry {
/**
@@ -111,16 +86,6 @@ struct rte_lpm_tbl_entry {
};
#else
-__extension__
-struct rte_lpm_tbl_entry_v20 {
- uint8_t depth :6;
- uint8_t valid_group :1;
- uint8_t valid :1;
- union {
- uint8_t group_idx;
- uint8_t next_hop;
- };
-} __rte_aligned(sizeof(uint16_t));
__extension__
struct rte_lpm_tbl_entry {
@@ -141,11 +106,6 @@ struct rte_lpm_config {
};
/** @internal Rule structure. */
-struct rte_lpm_rule_v20 {
- uint32_t ip; /**< Rule IP address. */
- uint8_t next_hop; /**< Rule next hop. */
-};
-
struct rte_lpm_rule {
uint32_t ip; /**< Rule IP address. */
uint32_t next_hop; /**< Rule next hop. */
@@ -158,21 +118,6 @@ struct rte_lpm_rule_info {
};
/** @internal LPM structure. */
-struct rte_lpm_v20 {
- /* LPM metadata. */
- char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */
- uint32_t max_rules; /**< Max. balanced rules per lpm. */
- struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH]; /**< Rule info table. */
-
- /* LPM Tables. */
- struct rte_lpm_tbl_entry_v20 tbl24[RTE_LPM_TBL24_NUM_ENTRIES]
- __rte_cache_aligned; /**< LPM tbl24 table. */
- struct rte_lpm_tbl_entry_v20 tbl8[RTE_LPM_TBL8_NUM_ENTRIES]
- __rte_cache_aligned; /**< LPM tbl8 table. */
- struct rte_lpm_rule_v20 rules_tbl[]
- __rte_cache_aligned; /**< LPM rules. */
-};
-
struct rte_lpm {
/* LPM metadata. */
char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */
@@ -209,11 +154,6 @@ struct rte_lpm {
struct rte_lpm *
rte_lpm_create(const char *name, int socket_id,
const struct rte_lpm_config *config);
-struct rte_lpm_v20 *
-rte_lpm_create_v20(const char *name, int socket_id, int max_rules, int flags);
-struct rte_lpm *
-rte_lpm_create_v1604(const char *name, int socket_id,
- const struct rte_lpm_config *config);
/**
* Find an existing LPM object and return a pointer to it.
@@ -227,10 +167,6 @@ rte_lpm_create_v1604(const char *name, int socket_id,
*/
struct rte_lpm *
rte_lpm_find_existing(const char *name);
-struct rte_lpm_v20 *
-rte_lpm_find_existing_v20(const char *name);
-struct rte_lpm *
-rte_lpm_find_existing_v1604(const char *name);
/**
* Free an LPM object.
@@ -242,10 +178,6 @@ rte_lpm_find_existing_v1604(const char *name);
*/
void
rte_lpm_free(struct rte_lpm *lpm);
-void
-rte_lpm_free_v20(struct rte_lpm_v20 *lpm);
-void
-rte_lpm_free_v1604(struct rte_lpm *lpm);
/**
* Add a rule to the LPM table.
@@ -263,12 +195,6 @@ rte_lpm_free_v1604(struct rte_lpm *lpm);
*/
int
rte_lpm_add(struct rte_lpm *lpm, uint32_t ip, uint8_t depth, uint32_t next_hop);
-int
-rte_lpm_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
- uint8_t next_hop);
-int
-rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
- uint32_t next_hop);
/**
* Check if a rule is present in the LPM table,
@@ -288,12 +214,6 @@ rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
int
rte_lpm_is_rule_present(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t *next_hop);
-int
-rte_lpm_is_rule_present_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
-uint8_t *next_hop);
-int
-rte_lpm_is_rule_present_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
-uint32_t *next_hop);
/**
* Delete a rule from the LPM table.
@@ -309,10 +229,6 @@ uint32_t *next_hop);
*/
int
rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip, uint8_t depth);
-int
-rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth);
-int
-rte_lpm_delete_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth);
/**
* Delete all rules from the LPM table.
@@ -322,10 +238,6 @@ rte_lpm_delete_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth);
*/
void
rte_lpm_delete_all(struct rte_lpm *lpm);
-void
-rte_lpm_delete_all_v20(struct rte_lpm_v20 *lpm);
-void
-rte_lpm_delete_all_v1604(struct rte_lpm *lpm);
/**
* Lookup an IP into the LPM table.
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index 0d161dc327..c46e557e23 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -809,18 +809,6 @@ add_step(struct rte_lpm6 *lpm, struct rte_lpm6_tbl_entry *tbl,
return 1;
}
-/*
- * Add a route
- */
-int __vsym
-rte_lpm6_add_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint8_t next_hop)
-{
- return rte_lpm6_add_v1705(lpm, ip, depth, next_hop);
-}
-VERSION_SYMBOL(rte_lpm6_add, _v20, 2.0);
-
-
/*
* Simulate adding a route to LPM
*
@@ -842,7 +830,7 @@ simulate_add(struct rte_lpm6 *lpm, const uint8_t *masked_ip, uint8_t depth)
/* Inspect the first three bytes through tbl24 on the first step. */
ret = simulate_add_step(lpm, lpm->tbl24, &tbl_next, masked_ip,
- ADD_FIRST_BYTE, 1, depth, &need_tbl_nb);
+ ADD_FIRST_BYTE, 1, depth, &need_tbl_nb);
total_need_tbl_nb = need_tbl_nb;
/*
* Inspect one by one the rest of the bytes until
@@ -851,7 +839,7 @@ simulate_add(struct rte_lpm6 *lpm, const uint8_t *masked_ip, uint8_t depth)
for (i = ADD_FIRST_BYTE; i < RTE_LPM6_IPV6_ADDR_SIZE && ret == 1; i++) {
tbl = tbl_next;
ret = simulate_add_step(lpm, tbl, &tbl_next, masked_ip, 1,
- (uint8_t)(i+1), depth, &need_tbl_nb);
+ (uint8_t)(i + 1), depth, &need_tbl_nb);
total_need_tbl_nb += need_tbl_nb;
}
@@ -862,9 +850,12 @@ simulate_add(struct rte_lpm6 *lpm, const uint8_t *masked_ip, uint8_t depth)
return 0;
}
-int __vsym
-rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint32_t next_hop)
+/*
+ * Add a route
+ */
+int
+rte_lpm6_add(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
+ uint32_t next_hop)
{
struct rte_lpm6_tbl_entry *tbl;
struct rte_lpm6_tbl_entry *tbl_next = NULL;
@@ -896,8 +887,8 @@ rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
/* Inspect the first three bytes through tbl24 on the first step. */
tbl = lpm->tbl24;
status = add_step(lpm, tbl, TBL24_IND, &tbl_next, &tbl_next_num,
- masked_ip, ADD_FIRST_BYTE, 1, depth, next_hop,
- is_new_rule);
+ masked_ip, ADD_FIRST_BYTE, 1, depth, next_hop,
+ is_new_rule);
assert(status >= 0);
/*
@@ -907,17 +898,13 @@ rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
for (i = ADD_FIRST_BYTE; i < RTE_LPM6_IPV6_ADDR_SIZE && status == 1; i++) {
tbl = tbl_next;
status = add_step(lpm, tbl, tbl_next_num, &tbl_next,
- &tbl_next_num, masked_ip, 1, (uint8_t)(i+1),
- depth, next_hop, is_new_rule);
+ &tbl_next_num, masked_ip, 1, (uint8_t)(i + 1),
+ depth, next_hop, is_new_rule);
assert(status >= 0);
}
return status;
}
-BIND_DEFAULT_SYMBOL(rte_lpm6_add, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_lpm6_add(struct rte_lpm6 *lpm, uint8_t *ip,
- uint8_t depth, uint32_t next_hop),
- rte_lpm6_add_v1705);
/*
* Takes a pointer to a table entry and inspect one level.
@@ -955,26 +942,8 @@ lookup_step(const struct rte_lpm6 *lpm, const struct rte_lpm6_tbl_entry *tbl,
/*
* Looks up an IP
*/
-int __vsym
-rte_lpm6_lookup_v20(const struct rte_lpm6 *lpm, uint8_t *ip, uint8_t *next_hop)
-{
- uint32_t next_hop32 = 0;
- int32_t status;
-
- /* DEBUG: Check user input arguments. */
- if (next_hop == NULL)
- return -EINVAL;
-
- status = rte_lpm6_lookup_v1705(lpm, ip, &next_hop32);
- if (status == 0)
- *next_hop = (uint8_t)next_hop32;
-
- return status;
-}
-VERSION_SYMBOL(rte_lpm6_lookup, _v20, 2.0);
-
-int __vsym
-rte_lpm6_lookup_v1705(const struct rte_lpm6 *lpm, uint8_t *ip,
+int
+rte_lpm6_lookup(const struct rte_lpm6 *lpm, uint8_t *ip,
uint32_t *next_hop)
{
const struct rte_lpm6_tbl_entry *tbl;
@@ -1001,56 +970,12 @@ rte_lpm6_lookup_v1705(const struct rte_lpm6 *lpm, uint8_t *ip,
return status;
}
-BIND_DEFAULT_SYMBOL(rte_lpm6_lookup, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_lpm6_lookup(const struct rte_lpm6 *lpm, uint8_t *ip,
- uint32_t *next_hop), rte_lpm6_lookup_v1705);
/*
* Looks up a group of IP addresses
*/
-int __vsym
-rte_lpm6_lookup_bulk_func_v20(const struct rte_lpm6 *lpm,
- uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
- int16_t * next_hops, unsigned n)
-{
- unsigned i;
- const struct rte_lpm6_tbl_entry *tbl;
- const struct rte_lpm6_tbl_entry *tbl_next = NULL;
- uint32_t tbl24_index, next_hop;
- uint8_t first_byte;
- int status;
-
- /* DEBUG: Check user input arguments. */
- if ((lpm == NULL) || (ips == NULL) || (next_hops == NULL))
- return -EINVAL;
-
- for (i = 0; i < n; i++) {
- first_byte = LOOKUP_FIRST_BYTE;
- tbl24_index = (ips[i][0] << BYTES2_SIZE) |
- (ips[i][1] << BYTE_SIZE) | ips[i][2];
-
- /* Calculate pointer to the first entry to be inspected */
- tbl = &lpm->tbl24[tbl24_index];
-
- do {
- /* Continue inspecting following levels until success or failure */
- status = lookup_step(lpm, tbl, &tbl_next, ips[i], first_byte++,
- &next_hop);
- tbl = tbl_next;
- } while (status == 1);
-
- if (status < 0)
- next_hops[i] = -1;
- else
- next_hops[i] = (int16_t)next_hop;
- }
-
- return 0;
-}
-VERSION_SYMBOL(rte_lpm6_lookup_bulk_func, _v20, 2.0);
-
-int __vsym
-rte_lpm6_lookup_bulk_func_v1705(const struct rte_lpm6 *lpm,
+int
+rte_lpm6_lookup_bulk_func(const struct rte_lpm6 *lpm,
uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
int32_t *next_hops, unsigned int n)
{
@@ -1090,37 +1015,12 @@ rte_lpm6_lookup_bulk_func_v1705(const struct rte_lpm6 *lpm,
return 0;
}
-BIND_DEFAULT_SYMBOL(rte_lpm6_lookup_bulk_func, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_lpm6_lookup_bulk_func(const struct rte_lpm6 *lpm,
- uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
- int32_t *next_hops, unsigned int n),
- rte_lpm6_lookup_bulk_func_v1705);
/*
* Look for a rule in the high-level rules table
*/
-int __vsym
-rte_lpm6_is_rule_present_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint8_t *next_hop)
-{
- uint32_t next_hop32 = 0;
- int32_t status;
-
- /* DEBUG: Check user input arguments. */
- if (next_hop == NULL)
- return -EINVAL;
-
- status = rte_lpm6_is_rule_present_v1705(lpm, ip, depth, &next_hop32);
- if (status > 0)
- *next_hop = (uint8_t)next_hop32;
-
- return status;
-
-}
-VERSION_SYMBOL(rte_lpm6_is_rule_present, _v20, 2.0);
-
-int __vsym
-rte_lpm6_is_rule_present_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
+int
+rte_lpm6_is_rule_present(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint32_t *next_hop)
{
uint8_t masked_ip[RTE_LPM6_IPV6_ADDR_SIZE];
@@ -1136,10 +1036,6 @@ rte_lpm6_is_rule_present_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
return rule_find(lpm, masked_ip, depth, next_hop);
}
-BIND_DEFAULT_SYMBOL(rte_lpm6_is_rule_present, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_lpm6_is_rule_present(struct rte_lpm6 *lpm,
- uint8_t *ip, uint8_t depth, uint32_t *next_hop),
- rte_lpm6_is_rule_present_v1705);
/*
* Delete a rule from the rule table.
diff --git a/lib/librte_lpm/rte_lpm6.h b/lib/librte_lpm/rte_lpm6.h
index 5d59ccb1fe..37dfb20249 100644
--- a/lib/librte_lpm/rte_lpm6.h
+++ b/lib/librte_lpm/rte_lpm6.h
@@ -96,12 +96,6 @@ rte_lpm6_free(struct rte_lpm6 *lpm);
int
rte_lpm6_add(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint32_t next_hop);
-int
-rte_lpm6_add_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint8_t next_hop);
-int
-rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint32_t next_hop);
/**
* Check if a rule is present in the LPM table,
@@ -121,12 +115,6 @@ rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
int
rte_lpm6_is_rule_present(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint32_t *next_hop);
-int
-rte_lpm6_is_rule_present_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint8_t *next_hop);
-int
-rte_lpm6_is_rule_present_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint32_t *next_hop);
/**
* Delete a rule from the LPM table.
@@ -184,11 +172,6 @@ rte_lpm6_delete_all(struct rte_lpm6 *lpm);
*/
int
rte_lpm6_lookup(const struct rte_lpm6 *lpm, uint8_t *ip, uint32_t *next_hop);
-int
-rte_lpm6_lookup_v20(const struct rte_lpm6 *lpm, uint8_t *ip, uint8_t *next_hop);
-int
-rte_lpm6_lookup_v1705(const struct rte_lpm6 *lpm, uint8_t *ip,
- uint32_t *next_hop);
/**
* Lookup multiple IP addresses in an LPM table.
@@ -210,14 +193,6 @@ int
rte_lpm6_lookup_bulk_func(const struct rte_lpm6 *lpm,
uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
int32_t *next_hops, unsigned int n);
-int
-rte_lpm6_lookup_bulk_func_v20(const struct rte_lpm6 *lpm,
- uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
- int16_t *next_hops, unsigned int n);
-int
-rte_lpm6_lookup_bulk_func_v1705(const struct rte_lpm6 *lpm,
- uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
- int32_t *next_hops, unsigned int n);
#ifdef __cplusplus
}
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v7 04/10] timer: remove deprecated code
2019-11-06 16:54 8% ` [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
` (3 preceding siblings ...)
2019-11-08 16:25 23% ` [dpdk-dev] [PATCH v7 03/10] buildtools: add ABI update shell script Anatoly Burakov
@ 2019-11-08 16:25 4% ` Anatoly Burakov
2019-11-08 16:25 2% ` [dpdk-dev] [PATCH v7 05/10] lpm: " Anatoly Burakov
` (5 subsequent siblings)
10 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-08 16:25 UTC (permalink / raw)
To: dev
Cc: Marcin Baran, Robert Sanford, Erik Gabriel Carrillo,
john.mcnamara, ray.kinsella, bruce.richardson, thomas,
david.marchand
From: Marcin Baran <marcinx.baran@intel.com>
Remove code for old ABI versions ahead of ABI version bump.
Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
---
Notes:
v2:
- Moved this to before ABI version bump to avoid compile breakage
lib/librte_timer/rte_timer.c | 100 ++++-------------------------------
lib/librte_timer/rte_timer.h | 15 ------
2 files changed, 10 insertions(+), 105 deletions(-)
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 381a9f43f8..ca88454ff6 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -68,9 +68,6 @@ static struct rte_timer_data *rte_timer_data_arr;
static const uint32_t default_data_id;
static uint32_t rte_timer_subsystem_initialized;
-/* For maintaining older interfaces for a period */
-static struct rte_timer_data default_timer_data;
-
/* when debug is enabled, store some statistics */
#ifdef RTE_LIBRTE_TIMER_DEBUG
#define __TIMER_STAT_ADD(priv_timer, name, n) do { \
@@ -131,30 +128,14 @@ rte_timer_data_dealloc(uint32_t id)
return 0;
}
-void __vsym
-rte_timer_subsystem_init_v20(void)
-{
- unsigned lcore_id;
- struct priv_timer *priv_timer = default_timer_data.priv_timer;
-
- /* since priv_timer is static, it's zeroed by default, so only init some
- * fields.
- */
- for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id ++) {
- rte_spinlock_init(&priv_timer[lcore_id].list_lock);
- priv_timer[lcore_id].prev_lcore = lcore_id;
- }
-}
-VERSION_SYMBOL(rte_timer_subsystem_init, _v20, 2.0);
-
/* Init the timer library. Allocate an array of timer data structs in shared
* memory, and allocate the zeroth entry for use with original timer
* APIs. Since the intersection of the sets of lcore ids in primary and
* secondary processes should be empty, the zeroth entry can be shared by
* multiple processes.
*/
-int __vsym
-rte_timer_subsystem_init_v1905(void)
+int
+rte_timer_subsystem_init(void)
{
const struct rte_memzone *mz;
struct rte_timer_data *data;
@@ -209,9 +190,6 @@ rte_timer_subsystem_init_v1905(void)
return 0;
}
-MAP_STATIC_SYMBOL(int rte_timer_subsystem_init(void),
- rte_timer_subsystem_init_v1905);
-BIND_DEFAULT_SYMBOL(rte_timer_subsystem_init, _v1905, 19.05);
void
rte_timer_subsystem_finalize(void)
@@ -551,43 +529,14 @@ __rte_timer_reset(struct rte_timer *tim, uint64_t expire,
}
/* Reset and start the timer associated with the timer handle tim */
-int __vsym
-rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
- enum rte_timer_type type, unsigned int tim_lcore,
- rte_timer_cb_t fct, void *arg)
-{
- uint64_t cur_time = rte_get_timer_cycles();
- uint64_t period;
-
- if (unlikely((tim_lcore != (unsigned)LCORE_ID_ANY) &&
- !(rte_lcore_is_enabled(tim_lcore) ||
- rte_lcore_has_role(tim_lcore, ROLE_SERVICE))))
- return -1;
-
- if (type == PERIODICAL)
- period = ticks;
- else
- period = 0;
-
- return __rte_timer_reset(tim, cur_time + ticks, period, tim_lcore,
- fct, arg, 0, &default_timer_data);
-}
-VERSION_SYMBOL(rte_timer_reset, _v20, 2.0);
-
-int __vsym
-rte_timer_reset_v1905(struct rte_timer *tim, uint64_t ticks,
+int
+rte_timer_reset(struct rte_timer *tim, uint64_t ticks,
enum rte_timer_type type, unsigned int tim_lcore,
rte_timer_cb_t fct, void *arg)
{
return rte_timer_alt_reset(default_data_id, tim, ticks, type,
tim_lcore, fct, arg);
}
-MAP_STATIC_SYMBOL(int rte_timer_reset(struct rte_timer *tim, uint64_t ticks,
- enum rte_timer_type type,
- unsigned int tim_lcore,
- rte_timer_cb_t fct, void *arg),
- rte_timer_reset_v1905);
-BIND_DEFAULT_SYMBOL(rte_timer_reset, _v1905, 19.05);
int
rte_timer_alt_reset(uint32_t timer_data_id, struct rte_timer *tim,
@@ -657,21 +606,11 @@ __rte_timer_stop(struct rte_timer *tim, int local_is_locked,
}
/* Stop the timer associated with the timer handle tim */
-int __vsym
-rte_timer_stop_v20(struct rte_timer *tim)
-{
- return __rte_timer_stop(tim, 0, &default_timer_data);
-}
-VERSION_SYMBOL(rte_timer_stop, _v20, 2.0);
-
-int __vsym
-rte_timer_stop_v1905(struct rte_timer *tim)
+int
+rte_timer_stop(struct rte_timer *tim)
{
return rte_timer_alt_stop(default_data_id, tim);
}
-MAP_STATIC_SYMBOL(int rte_timer_stop(struct rte_timer *tim),
- rte_timer_stop_v1905);
-BIND_DEFAULT_SYMBOL(rte_timer_stop, _v1905, 19.05);
int
rte_timer_alt_stop(uint32_t timer_data_id, struct rte_timer *tim)
@@ -817,15 +756,8 @@ __rte_timer_manage(struct rte_timer_data *timer_data)
priv_timer[lcore_id].running_tim = NULL;
}
-void __vsym
-rte_timer_manage_v20(void)
-{
- __rte_timer_manage(&default_timer_data);
-}
-VERSION_SYMBOL(rte_timer_manage, _v20, 2.0);
-
-int __vsym
-rte_timer_manage_v1905(void)
+int
+rte_timer_manage(void)
{
struct rte_timer_data *timer_data;
@@ -835,8 +767,6 @@ rte_timer_manage_v1905(void)
return 0;
}
-MAP_STATIC_SYMBOL(int rte_timer_manage(void), rte_timer_manage_v1905);
-BIND_DEFAULT_SYMBOL(rte_timer_manage, _v1905, 19.05);
int
rte_timer_alt_manage(uint32_t timer_data_id,
@@ -1074,21 +1004,11 @@ __rte_timer_dump_stats(struct rte_timer_data *timer_data __rte_unused, FILE *f)
#endif
}
-void __vsym
-rte_timer_dump_stats_v20(FILE *f)
-{
- __rte_timer_dump_stats(&default_timer_data, f);
-}
-VERSION_SYMBOL(rte_timer_dump_stats, _v20, 2.0);
-
-int __vsym
-rte_timer_dump_stats_v1905(FILE *f)
+int
+rte_timer_dump_stats(FILE *f)
{
return rte_timer_alt_dump_stats(default_data_id, f);
}
-MAP_STATIC_SYMBOL(int rte_timer_dump_stats(FILE *f),
- rte_timer_dump_stats_v1905);
-BIND_DEFAULT_SYMBOL(rte_timer_dump_stats, _v1905, 19.05);
int
rte_timer_alt_dump_stats(uint32_t timer_data_id __rte_unused, FILE *f)
diff --git a/lib/librte_timer/rte_timer.h b/lib/librte_timer/rte_timer.h
index 05d287d8f2..9dc5fc3092 100644
--- a/lib/librte_timer/rte_timer.h
+++ b/lib/librte_timer/rte_timer.h
@@ -181,8 +181,6 @@ int rte_timer_data_dealloc(uint32_t id);
* subsystem
*/
int rte_timer_subsystem_init(void);
-int rte_timer_subsystem_init_v1905(void);
-void rte_timer_subsystem_init_v20(void);
/**
* @warning
@@ -250,13 +248,6 @@ void rte_timer_init(struct rte_timer *tim);
int rte_timer_reset(struct rte_timer *tim, uint64_t ticks,
enum rte_timer_type type, unsigned tim_lcore,
rte_timer_cb_t fct, void *arg);
-int rte_timer_reset_v1905(struct rte_timer *tim, uint64_t ticks,
- enum rte_timer_type type, unsigned int tim_lcore,
- rte_timer_cb_t fct, void *arg);
-int rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
- enum rte_timer_type type, unsigned int tim_lcore,
- rte_timer_cb_t fct, void *arg);
-
/**
* Loop until rte_timer_reset() succeeds.
@@ -313,8 +304,6 @@ rte_timer_reset_sync(struct rte_timer *tim, uint64_t ticks,
* - (-1): The timer is in the RUNNING or CONFIG state.
*/
int rte_timer_stop(struct rte_timer *tim);
-int rte_timer_stop_v1905(struct rte_timer *tim);
-int rte_timer_stop_v20(struct rte_timer *tim);
/**
* Loop until rte_timer_stop() succeeds.
@@ -358,8 +347,6 @@ int rte_timer_pending(struct rte_timer *tim);
* - -EINVAL: timer subsystem not yet initialized
*/
int rte_timer_manage(void);
-int rte_timer_manage_v1905(void);
-void rte_timer_manage_v20(void);
/**
* Dump statistics about timers.
@@ -371,8 +358,6 @@ void rte_timer_manage_v20(void);
* - -EINVAL: timer subsystem not yet initialized
*/
int rte_timer_dump_stats(FILE *f);
-int rte_timer_dump_stats_v1905(FILE *f);
-void rte_timer_dump_stats_v20(FILE *f);
/**
* @warning
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v7 03/10] buildtools: add ABI update shell script
2019-11-06 16:54 8% ` [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
` (2 preceding siblings ...)
2019-11-08 16:25 15% ` [dpdk-dev] [PATCH v7 02/10] buildtools: add script for updating symbols abi version Anatoly Burakov
@ 2019-11-08 16:25 23% ` Anatoly Burakov
2019-11-08 16:25 4% ` [dpdk-dev] [PATCH v7 04/10] timer: remove deprecated code Anatoly Burakov
` (6 subsequent siblings)
10 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-08 16:25 UTC (permalink / raw)
To: dev; +Cc: john.mcnamara, ray.kinsella, bruce.richardson, thomas, david.marchand
In order to facilitate mass updating of version files, add a shell
script that recurses into lib/ and drivers/ directories and calls
the ABI version update script.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
Notes:
v3:
- Switch to sh rather than bash, and remove bash-isms
- Address review comments
v2:
- Add this patch to split the shell script from previous commit
- Fixup miscellaneous bugs
buildtools/update-abi.sh | 42 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100755 buildtools/update-abi.sh
diff --git a/buildtools/update-abi.sh b/buildtools/update-abi.sh
new file mode 100755
index 0000000000..89ba5804a6
--- /dev/null
+++ b/buildtools/update-abi.sh
@@ -0,0 +1,42 @@
+#!/bin/sh
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+
+abi_version=$1
+abi_version_file="./config/ABI_VERSION"
+update_path="lib drivers"
+
+if [ -z "$1" ]; then
+ # output to stderr
+ >&2 echo "Please provide ABI version"
+ exit 1
+fi
+
+# check version string format
+echo $abi_version | grep -q -e "^[[:digit:]]\{1,2\}\.[[:digit:]]\{1,2\}$"
+if [ "$?" -ne 0 ]; then
+ # output to stderr
+ >&2 echo "ABI version must be formatted as MAJOR.MINOR version"
+ exit 1
+fi
+
+if [ -n "$2" ]; then
+ abi_version_file=$2
+fi
+
+if [ -n "$3" ]; then
+ # drop $1 and $2
+ shift 2
+ # assign all other arguments as update paths
+ update_path=$@
+fi
+
+echo "New ABI version:" $abi_version
+echo "ABI_VERSION path:" $abi_version_file
+echo "Path to update:" $update_path
+
+echo $abi_version > $abi_version_file
+
+find $update_path -name \*version.map -exec \
+ ./buildtools/update_version_map_abi.py {} \
+ $abi_version \; -print
--
2.17.1
^ permalink raw reply [relevance 23%]
* [dpdk-dev] [PATCH v7 02/10] buildtools: add script for updating symbols abi version
2019-11-06 16:54 8% ` [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
2019-11-08 16:25 8% ` [dpdk-dev] [PATCH v7 " Anatoly Burakov
2019-11-08 16:25 7% ` [dpdk-dev] [PATCH v7 01/10] config: change ABI versioning to global Anatoly Burakov
@ 2019-11-08 16:25 15% ` Anatoly Burakov
2019-11-08 16:25 23% ` [dpdk-dev] [PATCH v7 03/10] buildtools: add ABI update shell script Anatoly Burakov
` (7 subsequent siblings)
10 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-08 16:25 UTC (permalink / raw)
To: dev
Cc: Pawel Modrak, john.mcnamara, ray.kinsella, bruce.richardson,
thomas, david.marchand
From: Pawel Modrak <pawelx.modrak@intel.com>
Add a script that automatically merges all stable ABI's under one
ABI section with the new version, while leaving experimental
section exactly as it is.
Signed-off-by: Pawel Modrak <pawelx.modrak@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
Notes:
v7:
- Do not remove stable ABI if it was empty
v6:
- Split map file generation function in two
- Do not print stable ABI if it wasn't present
v3:
- Add comments to regex patterns
v2:
- Reworked script to be pep8-compliant and more reliable
buildtools/update_version_map_abi.py | 173 +++++++++++++++++++++++++++
1 file changed, 173 insertions(+)
create mode 100755 buildtools/update_version_map_abi.py
diff --git a/buildtools/update_version_map_abi.py b/buildtools/update_version_map_abi.py
new file mode 100755
index 0000000000..0f6196140e
--- /dev/null
+++ b/buildtools/update_version_map_abi.py
@@ -0,0 +1,173 @@
+#!/usr/bin/env python
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+
+"""
+A Python program to update the ABI version and function names in a DPDK
+lib_*_version.map file. Called from the buildtools/update_abi.sh utility.
+"""
+
+from __future__ import print_function
+import argparse
+import sys
+import re
+
+
+def __parse_map_file(f_in):
+ # match function name, followed by semicolon, followed by EOL, optionally
+ # with whitespace inbetween each item
+ func_line_regex = re.compile(r"\s*"
+ r"(?P<func>[a-zA-Z_0-9]+)"
+ r"\s*"
+ r";"
+ r"\s*"
+ r"$")
+ # match section name, followed by opening bracked, followed by EOL,
+ # optionally with whitespace inbetween each item
+ section_begin_regex = re.compile(r"\s*"
+ r"(?P<version>[a-zA-Z0-9_\.]+)"
+ r"\s*"
+ r"{"
+ r"\s*"
+ r"$")
+ # match closing bracket, optionally followed by section name (for when we
+ # inherit from another ABI version), followed by semicolon, followed by
+ # EOL, optionally with whitespace inbetween each item
+ section_end_regex = re.compile(r"\s*"
+ r"}"
+ r"\s*"
+ r"(?P<parent>[a-zA-Z0-9_\.]+)?"
+ r"\s*"
+ r";"
+ r"\s*"
+ r"$")
+
+ # for stable ABI, we don't care about which version introduced which
+ # function, we just flatten the list. there are dupes in certain files, so
+ # use a set instead of a list
+ stable_lines = set()
+ # copy experimental section as is
+ experimental_lines = []
+ in_experimental = False
+ has_stable = False
+
+ # gather all functions
+ for line in f_in:
+ # clean up the line
+ line = line.strip('\n').strip()
+
+ # is this an end of section?
+ match = section_end_regex.match(line)
+ if match:
+ # whatever section this was, it's not active any more
+ in_experimental = False
+ continue
+
+ # if we're in the middle of experimental section, we need to copy
+ # the section verbatim, so just add the line
+ if in_experimental:
+ experimental_lines += [line]
+ continue
+
+ # skip empty lines
+ if not line:
+ continue
+
+ # is this a beginning of a new section?
+ match = section_begin_regex.match(line)
+ if match:
+ cur_section = match.group("version")
+ # is it experimental?
+ in_experimental = cur_section == "EXPERIMENTAL"
+ if not in_experimental:
+ has_stable = True
+ continue
+
+ # is this a function?
+ match = func_line_regex.match(line)
+ if match:
+ stable_lines.add(match.group("func"))
+
+ return has_stable, stable_lines, experimental_lines
+
+
+def __generate_stable_abi(f_out, abi_version, lines):
+ # print ABI version header
+ print("DPDK_{} {{".format(abi_version), file=f_out)
+
+ # print global section if it exists
+ if lines:
+ print("\tglobal:", file=f_out)
+ # blank line
+ print(file=f_out)
+
+ # print all stable lines, alphabetically sorted
+ for line in sorted(lines):
+ print("\t{};".format(line), file=f_out)
+
+ # another blank line
+ print(file=f_out)
+
+ # print local section
+ print("\tlocal: *;", file=f_out)
+
+ # end stable version
+ print("};", file=f_out)
+
+
+def __generate_experimental_abi(f_out, lines):
+ # start experimental section
+ print("EXPERIMENTAL {", file=f_out)
+
+ # print all experimental lines as they were
+ for line in lines:
+ # don't print empty whitespace
+ if not line:
+ print("", file=f_out)
+ else:
+ print("\t{}".format(line), file=f_out)
+
+ # end section
+ print("};", file=f_out)
+
+
+def __main():
+ arg_parser = argparse.ArgumentParser(
+ description='Merge versions in linker version script.')
+
+ arg_parser.add_argument("map_file", type=str,
+ help='path to linker version script file '
+ '(pattern: *version.map)')
+ arg_parser.add_argument("abi_version", type=str,
+ help='target ABI version (pattern: MAJOR.MINOR)')
+
+ parsed = arg_parser.parse_args()
+
+ if not parsed.map_file.endswith('version.map'):
+ print("Invalid input file: {}".format(parsed.map_file),
+ file=sys.stderr)
+ arg_parser.print_help()
+ sys.exit(1)
+
+ if not re.match(r"\d{1,2}\.\d{1,2}", parsed.abi_version):
+ print("Invalid ABI version: {}".format(parsed.abi_version),
+ file=sys.stderr)
+ arg_parser.print_help()
+ sys.exit(1)
+
+ with open(parsed.map_file) as f_in:
+ has_stable, stable_lines, experimental_lines = __parse_map_file(f_in)
+
+ with open(parsed.map_file, 'w') as f_out:
+ need_newline = has_stable and experimental_lines
+ if has_stable:
+ __generate_stable_abi(f_out, parsed.abi_version, stable_lines)
+ if need_newline:
+ # separate sections with a newline
+ print(file=f_out)
+ if experimental_lines:
+ __generate_experimental_abi(f_out, experimental_lines)
+
+
+if __name__ == "__main__":
+ __main()
--
2.17.1
^ permalink raw reply [relevance 15%]
* [dpdk-dev] [PATCH v7 01/10] config: change ABI versioning to global
2019-11-06 16:54 8% ` [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
2019-11-08 16:25 8% ` [dpdk-dev] [PATCH v7 " Anatoly Burakov
@ 2019-11-08 16:25 7% ` Anatoly Burakov
2019-11-08 16:25 15% ` [dpdk-dev] [PATCH v7 02/10] buildtools: add script for updating symbols abi version Anatoly Burakov
` (8 subsequent siblings)
10 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-08 16:25 UTC (permalink / raw)
To: dev
Cc: Marcin Baran, Thomas Monjalon, Bruce Richardson, john.mcnamara,
ray.kinsella, david.marchand, Pawel Modrak
From: Marcin Baran <marcinx.baran@intel.com>
As per new ABI policy, all of the libraries are now versioned using
one global ABI version. Changes in this patch implement the
necessary steps to enable that.
Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
Signed-off-by: Pawel Modrak <pawelx.modrak@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
Notes:
v6:
- Silenced grep error message on trying to grep a directory
v3:
- Removed Windows support from Makefile changes
- Removed unneeded path conversions from meson files
buildtools/meson.build | 2 ++
config/ABI_VERSION | 1 +
config/meson.build | 4 +++-
drivers/meson.build | 20 ++++++++++++--------
lib/meson.build | 18 ++++++++++++------
meson_options.txt | 2 --
mk/rte.lib.mk | 13 ++++---------
7 files changed, 34 insertions(+), 26 deletions(-)
create mode 100644 config/ABI_VERSION
diff --git a/buildtools/meson.build b/buildtools/meson.build
index 32c79c1308..78ce69977d 100644
--- a/buildtools/meson.build
+++ b/buildtools/meson.build
@@ -12,3 +12,5 @@ if python3.found()
else
map_to_def_cmd = ['meson', 'runpython', files('map_to_def.py')]
endif
+
+is_experimental_cmd = [find_program('grep', 'findstr'), '^DPDK_']
diff --git a/config/ABI_VERSION b/config/ABI_VERSION
new file mode 100644
index 0000000000..9a7c1e503f
--- /dev/null
+++ b/config/ABI_VERSION
@@ -0,0 +1 @@
+20.0
diff --git a/config/meson.build b/config/meson.build
index 2b1cb92e7e..30aa2a5313 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -18,6 +18,8 @@ endforeach
# depending on the configuration options
pver = meson.project_version().split('.')
major_version = '@0@.@1@'.format(pver.get(0), pver.get(1))
+abi_version = run_command(find_program('cat', 'more'),
+ files('ABI_VERSION')).stdout().strip()
# extract all version information into the build configuration
dpdk_conf.set('RTE_VER_YEAR', pver.get(0).to_int())
@@ -37,7 +39,7 @@ endif
pmd_subdir_opt = get_option('drivers_install_subdir')
if pmd_subdir_opt.contains('<VERSION>')
- pmd_subdir_opt = major_version.join(pmd_subdir_opt.split('<VERSION>'))
+ pmd_subdir_opt = abi_version.join(pmd_subdir_opt.split('<VERSION>'))
endif
driver_install_path = join_paths(get_option('libdir'), pmd_subdir_opt)
eal_pmd_path = join_paths(get_option('prefix'), driver_install_path)
diff --git a/drivers/meson.build b/drivers/meson.build
index 156d2dc717..b03e0c3159 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -124,12 +124,19 @@ foreach class:dpdk_driver_classes
output: out_filename,
depends: [pmdinfogen, tmp_lib])
- if get_option('per_library_versions')
- lib_version = '@0@.1'.format(version)
- so_version = '@0@'.format(version)
+ version_map = '@0@/@1@/@2@_version.map'.format(
+ meson.current_source_dir(),
+ drv_path, lib_name)
+
+ is_experimental = run_command(is_experimental_cmd,
+ files(version_map)).returncode()
+
+ if is_experimental != 0
+ lib_version = '0.1'
+ so_version = '0'
else
- lib_version = major_version
- so_version = major_version
+ lib_version = abi_version
+ so_version = abi_version
endif
# now build the static driver
@@ -142,9 +149,6 @@ foreach class:dpdk_driver_classes
install: true)
# now build the shared driver
- version_map = '@0@/@1@/@2@_version.map'.format(
- meson.current_source_dir(),
- drv_path, lib_name)
shared_lib = shared_library(lib_name,
sources,
objects: objs,
diff --git a/lib/meson.build b/lib/meson.build
index b2ec9c09a9..3cff2482b1 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -106,12 +106,18 @@ foreach l:libraries
cflags += '-DRTE_USE_FUNCTION_VERSIONING'
endif
- if get_option('per_library_versions')
- lib_version = '@0@.1'.format(version)
- so_version = '@0@'.format(version)
+ version_map = '@0@/@1@/rte_@2@_version.map'.format(
+ meson.current_source_dir(), dir_name, name)
+
+ is_experimental = run_command(is_experimental_cmd,
+ files(version_map)).returncode()
+
+ if is_experimental != 0
+ lib_version = '0.1'
+ so_version = '0'
else
- lib_version = major_version
- so_version = major_version
+ lib_version = abi_version
+ so_version = abi_version
endif
# first build static lib
@@ -127,7 +133,7 @@ foreach l:libraries
dependencies: static_deps)
if not use_function_versioning
- # use pre-build objects to build shared lib
+ # then use pre-build objects to build shared lib
sources = []
objs += static_lib.extract_all_objects(recursive: false)
else
diff --git a/meson_options.txt b/meson_options.txt
index 89650b0e9c..da6a7f0302 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -30,8 +30,6 @@ option('max_lcores', type: 'integer', value: 128,
description: 'maximum number of cores/threads supported by EAL')
option('max_numa_nodes', type: 'integer', value: 4,
description: 'maximum number of NUMA nodes supported by EAL')
-option('per_library_versions', type: 'boolean', value: true,
- description: 'true: each lib gets its own version number, false: DPDK version used for each lib')
option('tests', type: 'boolean', value: true,
description: 'build unit tests')
option('use_hpet', type: 'boolean', value: false,
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index 4df8849a08..b49af9192b 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -11,20 +11,15 @@ EXTLIB_BUILD ?= n
# VPATH contains at least SRCDIR
VPATH += $(SRCDIR)
-ifneq ($(CONFIG_RTE_MAJOR_ABI),)
-ifneq ($(LIBABIVER),)
-LIBABIVER := $(CONFIG_RTE_MAJOR_ABI)
-endif
+ifneq ($(shell grep -s "^DPDK_" $(SRCDIR)/$(EXPORT_MAP)),)
+LIBABIVER := $(shell cat $(RTE_SRCDIR)/config/ABI_VERSION)
+else
+LIBABIVER := 0
endif
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
LIB := $(patsubst %.a,%.so.$(LIBABIVER),$(LIB))
ifeq ($(EXTLIB_BUILD),n)
-ifeq ($(CONFIG_RTE_MAJOR_ABI),)
-ifeq ($(CONFIG_RTE_NEXT_ABI),y)
-LIB := $(LIB).1
-endif
-endif
CPU_LDFLAGS += --version-script=$(SRCDIR)/$(EXPORT_MAP)
endif
endif
--
2.17.1
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [PATCH v7 00/10] Implement the new ABI policy and add helper scripts
2019-11-06 16:54 8% ` [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
@ 2019-11-08 16:25 8% ` Anatoly Burakov
2019-11-08 16:25 7% ` [dpdk-dev] [PATCH v7 01/10] config: change ABI versioning to global Anatoly Burakov
` (9 subsequent siblings)
10 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-08 16:25 UTC (permalink / raw)
To: dev; +Cc: john.mcnamara, ray.kinsella, bruce.richardson, thomas, david.marchand
This patchset prepares the codebase for the new ABI policy and
adds a few helper scripts.
There are two new scripts for managing ABI versions added. The
first one is a Python script that will read in a .map file,
flatten it and update the ABI version to the ABI version
specified on the command-line.
The second one is a shell script that will run the above mentioned
Python script recursively over the source tree and set the ABI
version to either that which is defined in config/ABI_VERSION, or
a user-specified one.
Example of its usage: buildtools/update-abi.sh 20.0
This will recurse into lib/ and drivers/ directory and update
whatever .map files it can find.
The other shell script that's added is one that can take in a .so
file and ensure that its declared public ABI matches either
current ABI, next ABI, or EXPERIMENTAL. This was moved to the
last commit because it made no sense to have it beforehand.
The source tree was verified to follow the new ABI policy using
the following command (assuming built binaries are in build/):
find ./build/lib ./build/drivers -name \*.so \
-exec ./buildtools/check-abi-version.sh {} \; -print
This returns 0.
Changes since v6:
- Rebase on top of latest master
- Fixed map file generation to generate stable ABI if it was there,
even if it was empty
Changes since v5:
- Addressed David's comments regarding libtool error messages
- Fixed map file generation to not generate empty stable ABI if
it wasn't there before
Changes since v4:
- Fixed shared library build issue for distributor
Changes since v3:
- Put distributor code back and cleaned it up
- Rebased on latest master and regenerated commit 9
Changes since v2:
- Addressed Bruce's review comments
- Removed single distributor mode as per Dave's suggestion
Changes since v1:
- Reordered patchset to have removal of old ABI's before introducing
the new one to avoid compile breakages between patches
- Added a new patch fixing missing symbol in octeontx common
- Split script commits into multiple commits and reordered them
- Re-generated the ABI bump commit
- Verified all scripts to work
Anatoly Burakov (2):
buildtools: add ABI update shell script
drivers/octeontx: add missing public symbol
Marcin Baran (6):
config: change ABI versioning to global
timer: remove deprecated code
lpm: remove deprecated code
distributor: remove deprecated code
distributor: rename v2.0 ABI to _single suffix
buildtools: add ABI versioning check script
Pawel Modrak (2):
buildtools: add script for updating symbols abi version
build: change ABI version to 20.0
buildtools/check-abi-version.sh | 54 +
buildtools/meson.build | 2 +
buildtools/update-abi.sh | 42 +
buildtools/update_version_map_abi.py | 173 +++
config/ABI_VERSION | 1 +
config/meson.build | 4 +-
.../rte_pmd_bbdev_fpga_lte_fec_version.map | 8 +-
.../null/rte_pmd_bbdev_null_version.map | 2 +-
.../rte_pmd_bbdev_turbo_sw_version.map | 2 +-
drivers/bus/dpaa/rte_bus_dpaa_version.map | 113 +-
drivers/bus/fslmc/rte_bus_fslmc_version.map | 154 +--
drivers/bus/ifpga/rte_bus_ifpga_version.map | 14 +-
drivers/bus/pci/rte_bus_pci_version.map | 2 +-
drivers/bus/vdev/rte_bus_vdev_version.map | 12 +-
drivers/bus/vmbus/rte_bus_vmbus_version.map | 12 +-
drivers/common/cpt/rte_common_cpt_version.map | 9 +-
.../common/dpaax/rte_common_dpaax_version.map | 14 +-
.../common/mvep/rte_common_mvep_version.map | 6 +-
.../octeontx/rte_common_octeontx_version.map | 7 +-
.../rte_common_octeontx2_version.map | 16 +-
.../compress/isal/rte_pmd_isal_version.map | 2 +-
.../rte_pmd_octeontx_compress_version.map | 2 +-
drivers/compress/qat/rte_pmd_qat_version.map | 2 +-
.../compress/zlib/rte_pmd_zlib_version.map | 2 +-
.../aesni_gcm/rte_pmd_aesni_gcm_version.map | 2 +-
.../aesni_mb/rte_pmd_aesni_mb_version.map | 2 +-
.../crypto/armv8/rte_pmd_armv8_version.map | 2 +-
.../caam_jr/rte_pmd_caam_jr_version.map | 3 +-
drivers/crypto/ccp/rte_pmd_ccp_version.map | 3 +-
.../dpaa2_sec/rte_pmd_dpaa2_sec_version.map | 10 +-
.../dpaa_sec/rte_pmd_dpaa_sec_version.map | 10 +-
.../crypto/kasumi/rte_pmd_kasumi_version.map | 2 +-
.../crypto/mvsam/rte_pmd_mvsam_version.map | 2 +-
.../crypto/nitrox/rte_pmd_nitrox_version.map | 2 +-
.../null/rte_pmd_null_crypto_version.map | 2 +-
.../rte_pmd_octeontx_crypto_version.map | 3 +-
.../rte_pmd_octeontx2_crypto_version.map | 3 +-
.../openssl/rte_pmd_openssl_version.map | 2 +-
.../rte_pmd_crypto_scheduler_version.map | 19 +-
.../crypto/snow3g/rte_pmd_snow3g_version.map | 2 +-
.../virtio/rte_pmd_virtio_crypto_version.map | 2 +-
drivers/crypto/zuc/rte_pmd_zuc_version.map | 2 +-
.../event/dpaa/rte_pmd_dpaa_event_version.map | 3 +-
.../dpaa2/rte_pmd_dpaa2_event_version.map | 2 +-
.../event/dsw/rte_pmd_dsw_event_version.map | 2 +-
.../rte_pmd_octeontx_event_version.map | 2 +-
.../rte_pmd_octeontx2_event_version.map | 3 +-
.../event/opdl/rte_pmd_opdl_event_version.map | 2 +-
.../rte_pmd_skeleton_event_version.map | 3 +-
drivers/event/sw/rte_pmd_sw_event_version.map | 2 +-
.../bucket/rte_mempool_bucket_version.map | 3 +-
.../mempool/dpaa/rte_mempool_dpaa_version.map | 2 +-
.../dpaa2/rte_mempool_dpaa2_version.map | 12 +-
.../octeontx/rte_mempool_octeontx_version.map | 2 +-
.../rte_mempool_octeontx2_version.map | 4 +-
.../mempool/ring/rte_mempool_ring_version.map | 3 +-
.../stack/rte_mempool_stack_version.map | 3 +-
drivers/meson.build | 20 +-
.../af_packet/rte_pmd_af_packet_version.map | 3 +-
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 2 +-
drivers/net/ark/rte_pmd_ark_version.map | 5 +-
.../net/atlantic/rte_pmd_atlantic_version.map | 4 +-
drivers/net/avp/rte_pmd_avp_version.map | 2 +-
drivers/net/axgbe/rte_pmd_axgbe_version.map | 2 +-
drivers/net/bnx2x/rte_pmd_bnx2x_version.map | 3 +-
drivers/net/bnxt/rte_pmd_bnxt_version.map | 4 +-
drivers/net/bonding/rte_pmd_bond_version.map | 47 +-
drivers/net/cxgbe/rte_pmd_cxgbe_version.map | 3 +-
drivers/net/dpaa/rte_pmd_dpaa_version.map | 11 +-
drivers/net/dpaa2/rte_pmd_dpaa2_version.map | 12 +-
drivers/net/e1000/rte_pmd_e1000_version.map | 3 +-
drivers/net/ena/rte_pmd_ena_version.map | 3 +-
drivers/net/enetc/rte_pmd_enetc_version.map | 3 +-
drivers/net/enic/rte_pmd_enic_version.map | 3 +-
.../net/failsafe/rte_pmd_failsafe_version.map | 3 +-
drivers/net/fm10k/rte_pmd_fm10k_version.map | 3 +-
drivers/net/hinic/rte_pmd_hinic_version.map | 3 +-
drivers/net/hns3/rte_pmd_hns3_version.map | 4 +-
drivers/net/i40e/rte_pmd_i40e_version.map | 65 +-
drivers/net/iavf/rte_pmd_iavf_version.map | 3 +-
drivers/net/ice/rte_pmd_ice_version.map | 3 +-
drivers/net/ifc/rte_pmd_ifc_version.map | 3 +-
drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map | 3 +-
drivers/net/ixgbe/rte_pmd_ixgbe_version.map | 62 +-
drivers/net/kni/rte_pmd_kni_version.map | 3 +-
.../net/liquidio/rte_pmd_liquidio_version.map | 3 +-
drivers/net/memif/rte_pmd_memif_version.map | 5 +-
drivers/net/mlx4/rte_pmd_mlx4_version.map | 3 +-
drivers/net/mlx5/rte_pmd_mlx5_version.map | 2 +-
drivers/net/mvneta/rte_pmd_mvneta_version.map | 2 +-
drivers/net/mvpp2/rte_pmd_mvpp2_version.map | 2 +-
drivers/net/netvsc/rte_pmd_netvsc_version.map | 4 +-
drivers/net/nfb/rte_pmd_nfb_version.map | 3 +-
drivers/net/nfp/rte_pmd_nfp_version.map | 2 +-
drivers/net/null/rte_pmd_null_version.map | 3 +-
.../net/octeontx/rte_pmd_octeontx_version.map | 10 +-
.../octeontx2/rte_pmd_octeontx2_version.map | 3 +-
drivers/net/pcap/rte_pmd_pcap_version.map | 3 +-
drivers/net/pfe/rte_pmd_pfe_version.map | 3 +-
drivers/net/qede/rte_pmd_qede_version.map | 3 +-
drivers/net/ring/rte_pmd_ring_version.map | 10 +-
drivers/net/sfc/rte_pmd_sfc_version.map | 3 +-
.../net/softnic/rte_pmd_softnic_version.map | 2 +-
.../net/szedata2/rte_pmd_szedata2_version.map | 2 +-
drivers/net/tap/rte_pmd_tap_version.map | 3 +-
.../net/thunderx/rte_pmd_thunderx_version.map | 3 +-
.../rte_pmd_vdev_netvsc_version.map | 3 +-
drivers/net/vhost/rte_pmd_vhost_version.map | 11 +-
drivers/net/virtio/rte_pmd_virtio_version.map | 3 +-
.../net/vmxnet3/rte_pmd_vmxnet3_version.map | 3 +-
.../rte_rawdev_dpaa2_cmdif_version.map | 3 +-
.../rte_rawdev_dpaa2_qdma_version.map | 4 +-
.../raw/ifpga/rte_rawdev_ifpga_version.map | 3 +-
drivers/raw/ioat/rte_rawdev_ioat_version.map | 3 +-
drivers/raw/ntb/rte_rawdev_ntb_version.map | 5 +-
.../rte_rawdev_octeontx2_dma_version.map | 3 +-
.../skeleton/rte_rawdev_skeleton_version.map | 3 +-
lib/librte_acl/rte_acl_version.map | 2 +-
.../rte_bitratestats_version.map | 2 +-
lib/librte_cfgfile/rte_cfgfile_version.map | 34 +-
lib/librte_cmdline/rte_cmdline_version.map | 10 +-
.../rte_cryptodev_version.map | 102 +-
lib/librte_distributor/Makefile | 2 +-
lib/librte_distributor/distributor_private.h | 10 +-
lib/librte_distributor/meson.build | 2 +-
lib/librte_distributor/rte_distributor.c | 98 +-
...ributor_v20.c => rte_distributor_single.c} | 73 +-
...ributor_v20.h => rte_distributor_single.h} | 26 +-
.../rte_distributor_v1705.h | 61 -
.../rte_distributor_version.map | 16 +-
lib/librte_eal/rte_eal_version.map | 324 ++----
lib/librte_efd/rte_efd_version.map | 2 +-
lib/librte_ethdev/rte_ethdev_version.map | 160 +--
lib/librte_eventdev/rte_eventdev_version.map | 130 +--
lib/librte_gro/rte_gro_version.map | 2 +-
lib/librte_gso/rte_gso_version.map | 2 +-
lib/librte_hash/rte_hash_version.map | 43 +-
lib/librte_ip_frag/rte_ip_frag_version.map | 10 +-
lib/librte_jobstats/rte_jobstats_version.map | 10 +-
lib/librte_kni/rte_kni_version.map | 2 +-
lib/librte_kvargs/rte_kvargs_version.map | 4 +-
.../rte_latencystats_version.map | 2 +-
lib/librte_lpm/rte_lpm.c | 1010 +----------------
lib/librte_lpm/rte_lpm.h | 88 --
lib/librte_lpm/rte_lpm6.c | 140 +--
lib/librte_lpm/rte_lpm6.h | 25 -
lib/librte_lpm/rte_lpm_version.map | 39 +-
lib/librte_mbuf/rte_mbuf_version.map | 49 +-
lib/librte_member/rte_member_version.map | 2 +-
lib/librte_mempool/rte_mempool_version.map | 44 +-
lib/librte_meter/rte_meter_version.map | 13 +-
lib/librte_metrics/rte_metrics_version.map | 2 +-
lib/librte_net/rte_net_version.map | 23 +-
lib/librte_pci/rte_pci_version.map | 2 +-
lib/librte_pdump/rte_pdump_version.map | 2 +-
lib/librte_pipeline/rte_pipeline_version.map | 36 +-
lib/librte_port/rte_port_version.map | 64 +-
lib/librte_power/rte_power_version.map | 24 +-
lib/librte_rawdev/rte_rawdev_version.map | 4 +-
lib/librte_reorder/rte_reorder_version.map | 8 +-
lib/librte_ring/rte_ring_version.map | 10 +-
lib/librte_sched/rte_sched_version.map | 14 +-
lib/librte_security/rte_security_version.map | 2 +-
lib/librte_table/rte_table_version.map | 2 +-
lib/librte_timer/rte_timer.c | 100 +-
lib/librte_timer/rte_timer.h | 15 -
lib/librte_timer/rte_timer_version.map | 12 +-
lib/librte_vhost/rte_vhost_version.map | 52 +-
lib/meson.build | 18 +-
meson_options.txt | 2 -
mk/rte.lib.mk | 13 +-
171 files changed, 1152 insertions(+), 2971 deletions(-)
create mode 100755 buildtools/check-abi-version.sh
create mode 100755 buildtools/update-abi.sh
create mode 100755 buildtools/update_version_map_abi.py
create mode 100644 config/ABI_VERSION
rename lib/librte_distributor/{rte_distributor_v20.c => rte_distributor_single.c} (84%)
rename lib/librte_distributor/{rte_distributor_v20.h => rte_distributor_single.h} (89%)
delete mode 100644 lib/librte_distributor/rte_distributor_v1705.h
--
2.17.1
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps
2019-11-05 15:15 2% [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps Anatoly Burakov
2019-11-05 17:15 0% ` Burakov, Anatoly
2019-11-06 21:53 0% ` David Marchand
@ 2019-11-07 6:35 0% ` Rajesh Ravi
2019-11-07 15:35 0% ` David Marchand
3 siblings, 0 replies; 200+ results
From: Rajesh Ravi @ 2019-11-07 6:35 UTC (permalink / raw)
To: Anatoly Burakov
Cc: dev, Bruce Richardson, Ajit Kumar Khaparde, Jonathan Richardson,
Scott Branden, Vikram Prakash, Srinath Mannam, David Marchand,
Thomas Monjalon
Tested-by: Rajesh Ravi <rajesh.ravi@broadcom.com>
Tested the patch modified for DPDK 19.02 along with SPDK 19.07
Regards,
Rajesh
On Tue, Nov 5, 2019 at 8:45 PM Anatoly Burakov <anatoly.burakov@intel.com>
wrote:
> Currently, externally created heaps are supposed to be automatically
> mapped for VFIO DMA by EAL, however they only do so if, at the time of
> heap creation, VFIO is initialized and has at least one device
> available. If no devices are available at the time of heap creation (or
> if devices were available, but were since hot-unplugged, thus dropping
> all VFIO container mappings), then VFIO mapping code would have skipped
> over externally allocated heaps.
>
> The fix is two-fold. First, we allow externally allocated memory
> segments to be marked as "heap" segments. This allows us to distinguish
> between external memory segments that were created via heap API, from
> those that were created via rte_extmem_register() API.
>
> Then, we fix the VFIO code to only skip non-heap external segments.
> Also, since external heaps are not guaranteed to have valid IOVA
> addresses, we will skip those which have invalid IOVA addresses as well.
>
> Fixes: 0f526d674f8e ("malloc: separate creating memseg list and malloc
> heap")
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
>
> Notes:
> This cannot be backported to older releases as it breaks the
> API and ABI. A separate fix is in the works for stable.
>
> lib/librte_eal/common/include/rte_memory.h | 1 +
> lib/librte_eal/common/rte_malloc.c | 1 +
> lib/librte_eal/freebsd/eal/eal_memory.c | 1 +
> lib/librte_eal/linux/eal/eal_memory.c | 3 ++
> lib/librte_eal/linux/eal/eal_vfio.c | 46 +++++++++++++++++++---
> 5 files changed, 47 insertions(+), 5 deletions(-)
>
> diff --git a/lib/librte_eal/common/include/rte_memory.h
> b/lib/librte_eal/common/include/rte_memory.h
> index 38e00e382c..bf81a2faa8 100644
> --- a/lib/librte_eal/common/include/rte_memory.h
> +++ b/lib/librte_eal/common/include/rte_memory.h
> @@ -81,6 +81,7 @@ struct rte_memseg_list {
> volatile uint32_t version; /**< version number for multiprocess
> sync. */
> size_t len; /**< Length of memory area covered by this memseg
> list. */
> unsigned int external; /**< 1 if this list points to external
> memory */
> + unsigned int heap; /**< 1 if this list points to a heap */
> struct rte_fbarray memseg_arr;
> };
>
> diff --git a/lib/librte_eal/common/rte_malloc.c
> b/lib/librte_eal/common/rte_malloc.c
> index 044d3a9078..413e4aa004 100644
> --- a/lib/librte_eal/common/rte_malloc.c
> +++ b/lib/librte_eal/common/rte_malloc.c
> @@ -396,6 +396,7 @@ rte_malloc_heap_memory_add(const char *heap_name, void
> *va_addr, size_t len,
>
> rte_spinlock_lock(&heap->lock);
> ret = malloc_heap_add_external_memory(heap, msl);
> + msl->heap = 1; /* mark it as heap segment */
> rte_spinlock_unlock(&heap->lock);
>
> unlock:
> diff --git a/lib/librte_eal/freebsd/eal/eal_memory.c
> b/lib/librte_eal/freebsd/eal/eal_memory.c
> index 7fe3178898..a97d8f0f0c 100644
> --- a/lib/librte_eal/freebsd/eal/eal_memory.c
> +++ b/lib/librte_eal/freebsd/eal/eal_memory.c
> @@ -93,6 +93,7 @@ rte_eal_hugepage_init(void)
> msl->page_sz = page_sz;
> msl->len = internal_config.memory;
> msl->socket_id = 0;
> + msl->heap = 1;
>
> /* populate memsegs. each memseg is 1 page long */
> for (cur_seg = 0; cur_seg < n_segs; cur_seg++) {
> diff --git a/lib/librte_eal/linux/eal/eal_memory.c
> b/lib/librte_eal/linux/eal/eal_memory.c
> index accfd2e232..43e4ffc757 100644
> --- a/lib/librte_eal/linux/eal/eal_memory.c
> +++ b/lib/librte_eal/linux/eal/eal_memory.c
> @@ -831,6 +831,7 @@ alloc_memseg_list(struct rte_memseg_list *msl,
> uint64_t page_sz,
> msl->page_sz = page_sz;
> msl->socket_id = socket_id;
> msl->base_va = NULL;
> + msl->heap = 1; /* mark it as a heap segment */
>
> RTE_LOG(DEBUG, EAL, "Memseg list allocated: 0x%zxkB at socket
> %i\n",
> (size_t)page_sz >> 10, socket_id);
> @@ -1405,6 +1406,7 @@ eal_legacy_hugepage_init(void)
> msl->page_sz = page_sz;
> msl->socket_id = 0;
> msl->len = internal_config.memory;
> + msl->heap = 1;
>
> /* we're in single-file segments mode, so only the segment
> list
> * fd needs to be set up.
> @@ -1677,6 +1679,7 @@ eal_legacy_hugepage_init(void)
> mem_sz = msl->len;
> munmap(msl->base_va, mem_sz);
> msl->base_va = NULL;
> + msl->heap = 0;
>
> /* destroy backing fbarray */
> rte_fbarray_destroy(&msl->memseg_arr);
> diff --git a/lib/librte_eal/linux/eal/eal_vfio.c
> b/lib/librte_eal/linux/eal/eal_vfio.c
> index d9541b1220..d5a2bbea0d 100644
> --- a/lib/librte_eal/linux/eal/eal_vfio.c
> +++ b/lib/librte_eal/linux/eal/eal_vfio.c
> @@ -1250,7 +1250,16 @@ type1_map(const struct rte_memseg_list *msl, const
> struct rte_memseg *ms,
> {
> int *vfio_container_fd = arg;
>
> - if (msl->external)
> + /* skip external memory that isn't a heap */
> + if (msl->external && !msl->heap)
> + return 0;
> +
> + /* skip any segments with invalid IOVA addresses */
> + if (ms->iova == RTE_BAD_IOVA)
> + return 0;
> +
> + /* if IOVA mode is VA, we've already mapped the internal segments
> */
> + if (!msl->external && rte_eal_iova_mode() == RTE_IOVA_VA)
> return 0;
>
> return vfio_type1_dma_mem_map(*vfio_container_fd, ms->addr_64,
> ms->iova,
> @@ -1313,12 +1322,18 @@ vfio_type1_dma_mem_map(int vfio_container_fd,
> uint64_t vaddr, uint64_t iova,
> static int
> vfio_type1_dma_map(int vfio_container_fd)
> {
> + int ret;
> if (rte_eal_iova_mode() == RTE_IOVA_VA) {
> /* with IOVA as VA mode, we can get away with mapping
> contiguous
> * chunks rather than going page-by-page.
> */
> - return rte_memseg_contig_walk(type1_map_contig,
> + ret = rte_memseg_contig_walk(type1_map_contig,
> &vfio_container_fd);
> + if (ret)
> + return ret;
> + /* we have to continue the walk because we've skipped the
> + * external segments during the config walk.
> + */
> }
> return rte_memseg_walk(type1_map, &vfio_container_fd);
> }
> @@ -1410,7 +1425,15 @@ vfio_spapr_map_walk(const struct rte_memseg_list
> *msl,
> {
> struct spapr_remap_walk_param *param = arg;
>
> - if (msl->external || ms->addr_64 == param->addr_64)
> + /* skip external memory that isn't a heap */
> + if (msl->external && !msl->heap)
> + return 0;
> +
> + /* skip any segments with invalid IOVA addresses */
> + if (ms->iova == RTE_BAD_IOVA)
> + return 0;
> +
> + if (ms->addr_64 == param->addr_64)
> return 0;
>
> return vfio_spapr_dma_do_map(param->vfio_container_fd,
> ms->addr_64, ms->iova,
> @@ -1423,7 +1446,15 @@ vfio_spapr_unmap_walk(const struct rte_memseg_list
> *msl,
> {
> struct spapr_remap_walk_param *param = arg;
>
> - if (msl->external || ms->addr_64 == param->addr_64)
> + /* skip external memory that isn't a heap */
> + if (msl->external && !msl->heap)
> + return 0;
> +
> + /* skip any segments with invalid IOVA addresses */
> + if (ms->iova == RTE_BAD_IOVA)
> + return 0;
> +
> + if (ms->addr_64 == param->addr_64)
> return 0;
>
> return vfio_spapr_dma_do_map(param->vfio_container_fd,
> ms->addr_64, ms->iova,
> @@ -1443,7 +1474,12 @@ vfio_spapr_window_size_walk(const struct
> rte_memseg_list *msl,
> struct spapr_walk_param *param = arg;
> uint64_t max = ms->iova + ms->len;
>
> - if (msl->external)
> + /* skip external memory that isn't a heap */
> + if (msl->external && !msl->heap)
> + return 0;
> +
> + /* skip any segments with invalid IOVA addresses */
> + if (ms->iova == RTE_BAD_IOVA)
> return 0;
>
> /* do not iterate ms we haven't mapped yet */
> --
> 2.17.1
>
--
Regards,
Rajesh
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
2019-11-08 12:51 0% ` Ferruh Yigit
@ 2019-11-08 16:11 0% ` Dekel Peled
2019-11-08 16:53 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Dekel Peled @ 2019-11-08 16:11 UTC (permalink / raw)
To: Ferruh Yigit, Matan Azrad, john.mcnamara, marko.kovacevic,
nhorman, ajit.khaparde, somnath.kotur, anatoly.burakov,
xuanziyang2, cloud.wangxiaoyun, zhouguoyang, wenzhuo.lu,
konstantin.ananyev, Shahaf Shuler, Slava Ovsiienko, rmody,
shshaikh, maxime.coquelin, tiwei.bie, zhihong.wang, yongwang,
Thomas Monjalon, arybchenko, jingjing.wu, bernard.iremonger
Cc: dev
Thanks, PSB.
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Friday, November 8, 2019 2:52 PM
> To: Matan Azrad <matan@mellanox.com>; Dekel Peled
> <dekelp@mellanox.com>; john.mcnamara@intel.com;
> marko.kovacevic@intel.com; nhorman@tuxdriver.com;
> ajit.khaparde@broadcom.com; somnath.kotur@broadcom.com;
> anatoly.burakov@intel.com; xuanziyang2@huawei.com;
> cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com;
> wenzhuo.lu@intel.com; konstantin.ananyev@intel.com; Shahaf Shuler
> <shahafs@mellanox.com>; Slava Ovsiienko <viacheslavo@mellanox.com>;
> rmody@marvell.com; shshaikh@marvell.com;
> maxime.coquelin@redhat.com; tiwei.bie@intel.com;
> zhihong.wang@intel.com; yongwang@vmware.com; Thomas Monjalon
> <thomas@monjalon.net>; arybchenko@solarflare.com;
> jingjing.wu@intel.com; bernard.iremonger@intel.com
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO
> packet size
>
> On 11/8/2019 11:56 AM, Matan Azrad wrote:
> >
> >
> > From: Ferruh Yigit
> >> On 11/8/2019 10:10 AM, Matan Azrad wrote:
> >>>
> >>>
> >>> From: Ferruh Yigit
> >>>> On 11/8/2019 6:54 AM, Matan Azrad wrote:
> >>>>> Hi
> >>>>>
> >>>>> From: Ferruh Yigit
> >>>>>> On 11/7/2019 12:35 PM, Dekel Peled wrote:
> >>>>>>> @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
> >>>>>>>
> >>>>>> RTE_ETHER_MAX_LEN;
> >>>>>>> }
> >>>>>>>
> >>>>>>> + /*
> >>>>>>> + * If LRO is enabled, check that the maximum aggregated
> >> packet
> >>>>>>> + * size is supported by the configured device.
> >>>>>>> + */
> >>>>>>> + if (dev_conf->rxmode.offloads &
> >> DEV_RX_OFFLOAD_TCP_LRO) {
> >>>>>>> + ret = check_lro_pkt_size(
> >>>>>>> + port_id, dev_conf-
> >>>>>>> rxmode.max_lro_pkt_size,
> >>>>>>> + dev_info.max_lro_pkt_size);
> >>>>>>> + if (ret != 0)
> >>>>>>> + goto rollback;
> >>>>>>> + }
> >>>>>>> +
> >>>>>>
> >>>>>> This check forces applications that enable LRO to provide
> >>>> 'max_lro_pkt_size'
> >>>>>> config value.
> >>>>>
> >>>>> Yes.(we can break an API, we noticed it)
> >>>>
> >>>> I am not talking about API/ABI breakage, that part is OK.
> >>>> With this check, if the application requested LRO offload but not
> >>>> provided 'max_lro_pkt_size' value, device configuration will fail.
> >>>>
> >>> Yes
> >>>> Can there be a case application is good with whatever the PMD can
> >>>> support as max?
> >>> Yes can be - you know, we can do everything we want but it is better
> >>> to be
> >> consistent:
> >>> Due to the fact of Max rx pkt len field is mandatory for JUMBO
> >>> offload, max
> >> lro pkt len should be mandatory for LRO offload.
> >>>
> >>> So your question is actually why both, non-lro packets and LRO
> >>> packets max
> >> size are mandatory...
> >>>
> >>>
> >>> I think it should be important values for net applications management.
> >>> Also good for mbuf size managements.
> >>>
> >>>>>
> >>>>>> - Why it is mandatory now, how it was working before if it is
> >>>>>> mandatory value?
> >>>>>
> >>>>> It is the same as max_rx_pkt_len which is mandatory for jumbo
> >>>>> frame
> >>>> offload.
> >>>>> So now, when the user configures a LRO offload he must to set max
> >>>>> lro pkt
> >>>> len.
> >>>>> We don't want to confuse the user here with the max rx pkt len
> >>>> configurations and behaviors, they should be with same logic.
> >>>>>
> >>>>> This parameter defines well the LRO behavior.
> >>>>> Before this, each PMD took its own interpretation to what should
> >>>>> be the
> >>>> maximum size for LRO aggregated packets.
> >>>>> Now, the user must say what is his intension, and the ethdev can
> >>>>> limit it
> >>>> according to the device capability.
> >>>>> By this way, also, the PMD can organize\optimize its data-path more.
> >>>>> Also, the application can create different mempools for LRO queues
> >>>>> to
> >>>> allow bigger packet receiving for LRO traffic.
> >>>>>
> >>>>>> - What happens if PMD doesn't provide 'max_lro_pkt_size', so it is
> '0'?
> >>>>> Yes, you can see the feature description Dekel added.
> >>>>> This patch also updates all the PMDs support an LRO for non-0 value.
> >>>>
> >>>> Of course I can see the updates Matan, my point is "What happens if
> >>>> PMD doesn't provide 'max_lro_pkt_size'",
> >>>> 1) There is no check for it right, so it is acceptable?
> >>>
> >>> There is check.
> >>> If the capability is 0, any non-zero configuration will fail.
> >>>
> >>>> 2) Are we making this filed mandatory to provide for PMDs, it is
> >>>> easy to make new fields mandatory for PMDs but is this really
> necessary?
> >>>
> >>> Yes, for consistence.
> >>>
> >>>>>
> >>>>> as same as max rx pkt len, no?
> >>>>>
> >>>>>> - What do you think setting 'max_lro_pkt_size' config value to
> >>>>>> what PMD provided if application doesn't provide it?
> >>>>> Same answers as above.
> >>>>>
> >>>>
> >>>> If application doesn't care the value, as it has been till now, and
> >>>> not provided explicit 'max_lro_pkt_size', why not ethdev level use
> >>>> the value provided by PMD instead of failing?
> >>>
> >>> Again, same question we can ask on max rx pkt len.
> >>>
> >>> Looks like the packet size is very important value which should be
> >>> set by
> >> the application.
> >>>
> >>> Previous applications have no option to configure it, so they
> >>> haven't
> >> configure it, (probably cover it somehow) I think it is our miss to
> >> supply this info.
> >>>
> >>> Let's do it in same way as we do max rx pkt len (as this patch main idea).
> >>> Later, we can change both to other meaning.
> >>>
> >>
> >> I think it is not a good reason to introduce a new mandatory config
> >> option for application because of 'max_rx_pkt_len' does it.
> >
> > It is mandatory only if LRO offload is configured.
> >
> >> Will it work, if:
> >> - If application doesn't provide this value, use the PMD max
> >
> > May cause a problem if the mbuf size is not enough for the PMD maximum.
>
> OK, this is what I was missing, for this case I was thinking max_rx_pkt_len will
> be used but you already explained that application may want to use different
> mempools for LRO queues.
>
> For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into
> account and program the device accordingly (of course in LRO enabled case)
> ?
> This part seems missing and should be highlighted to other PMD maintainers.
>
All relevant PMDs were modified and maintainers are copied on this patch series.
> >
> >> - If both application and PMD doesn't provide this value, fail on
> configure()?
> >
> > It will work.
> > In my opinion - not ideal.
> >
> > Matan
> >
> >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
2019-11-08 14:52 0% ` Ananyev, Konstantin
@ 2019-11-08 16:08 0% ` Dekel Peled
2019-11-08 16:28 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Dekel Peled @ 2019-11-08 16:08 UTC (permalink / raw)
To: Ananyev, Konstantin, Matan Azrad, Yigit, Ferruh, Mcnamara, John,
Kovacevic, Marko, nhorman, ajit.khaparde, somnath.kotur, Burakov,
Anatoly, xuanziyang2, cloud.wangxiaoyun, zhouguoyang, Lu,
Wenzhuo, Shahaf Shuler, Slava Ovsiienko, rmody, shshaikh,
maxime.coquelin, Bie, Tiwei, Wang, Zhihong, yongwang,
Thomas Monjalon, arybchenko, Wu, Jingjing, Iremonger, Bernard
Cc: dev
Thanks, PSB.
> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Sent: Friday, November 8, 2019 4:53 PM
> To: Dekel Peled <dekelp@mellanox.com>; Matan Azrad
> <matan@mellanox.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; Mcnamara,
> John <john.mcnamara@intel.com>; Kovacevic, Marko
> <marko.kovacevic@intel.com>; nhorman@tuxdriver.com;
> ajit.khaparde@broadcom.com; somnath.kotur@broadcom.com; Burakov,
> Anatoly <anatoly.burakov@intel.com>; xuanziyang2@huawei.com;
> cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com; Lu, Wenzhuo
> <wenzhuo.lu@intel.com>; Shahaf Shuler <shahafs@mellanox.com>; Slava
> Ovsiienko <viacheslavo@mellanox.com>; rmody@marvell.com;
> shshaikh@marvell.com; maxime.coquelin@redhat.com; Bie, Tiwei
> <tiwei.bie@intel.com>; Wang, Zhihong <zhihong.wang@intel.com>;
> yongwang@vmware.com; Thomas Monjalon <thomas@monjalon.net>;
> arybchenko@solarflare.com; Wu, Jingjing <jingjing.wu@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO
> packet size
>
>
> > > > > >>>> On 11/7/2019 12:35 PM, Dekel Peled wrote:
> > > > > >>>>> @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
> > > > > >>>>>
> > > > > >>>> RTE_ETHER_MAX_LEN;
> > > > > >>>>> }
> > > > > >>>>>
> > > > > >>>>> + /*
> > > > > >>>>> + * If LRO is enabled, check that the maximum
> aggregated
> > > > > packet
> > > > > >>>>> + * size is supported by the configured device.
> > > > > >>>>> + */
> > > > > >>>>> + if (dev_conf->rxmode.offloads &
> > > > > DEV_RX_OFFLOAD_TCP_LRO) {
> > > > > >>>>> + ret = check_lro_pkt_size(
> > > > > >>>>> + port_id, dev_conf-
> > > > > >>>>> rxmode.max_lro_pkt_size,
> > > > > >>>>> + dev_info.max_lro_pkt_size);
> > > > > >>>>> + if (ret != 0)
> > > > > >>>>> + goto rollback;
> > > > > >>>>> + }
> > > > > >>>>> +
> > > > > >>>>
> > > > > >>>> This check forces applications that enable LRO to provide
> > > > > >> 'max_lro_pkt_size'
> > > > > >>>> config value.
> > > > > >>>
> > > > > >>> Yes.(we can break an API, we noticed it)
> > > > > >>
> > > > > >> I am not talking about API/ABI breakage, that part is OK.
> > > > > >> With this check, if the application requested LRO offload but
> > > > > >> not provided 'max_lro_pkt_size' value, device configuration will
> fail.
> > > > > >>
> > > > > > Yes
> > > > > >> Can there be a case application is good with whatever the PMD
> > > > > >> can support as max?
> > > > > > Yes can be - you know, we can do everything we want but it is
> > > > > > better to be
> > > > > consistent:
> > > > > > Due to the fact of Max rx pkt len field is mandatory for JUMBO
> > > > > > offload, max
> > > > > lro pkt len should be mandatory for LRO offload.
> > > > > >
> > > > > > So your question is actually why both, non-lro packets and LRO
> > > > > > packets max
> > > > > size are mandatory...
> > > > > >
> > > > > >
> > > > > > I think it should be important values for net applications
> management.
> > > > > > Also good for mbuf size managements.
> > > > > >
> > > > > >>>
> > > > > >>>> - Why it is mandatory now, how it was working before if it
> > > > > >>>> is mandatory value?
> > > > > >>>
> > > > > >>> It is the same as max_rx_pkt_len which is mandatory for
> > > > > >>> jumbo frame
> > > > > >> offload.
> > > > > >>> So now, when the user configures a LRO offload he must to
> > > > > >>> set max lro pkt
> > > > > >> len.
> > > > > >>> We don't want to confuse the user here with the max rx pkt
> > > > > >>> len
> > > > > >> configurations and behaviors, they should be with same logic.
> > > > > >>>
> > > > > >>> This parameter defines well the LRO behavior.
> > > > > >>> Before this, each PMD took its own interpretation to what
> > > > > >>> should be the
> > > > > >> maximum size for LRO aggregated packets.
> > > > > >>> Now, the user must say what is his intension, and the ethdev
> > > > > >>> can limit it
> > > > > >> according to the device capability.
> > > > > >>> By this way, also, the PMD can organize\optimize its data-path
> more.
> > > > > >>> Also, the application can create different mempools for LRO
> > > > > >>> queues to
> > > > > >> allow bigger packet receiving for LRO traffic.
> > > > > >>>
> > > > > >>>> - What happens if PMD doesn't provide 'max_lro_pkt_size',
> > > > > >>>> so it is
> > > '0'?
> > > > > >>> Yes, you can see the feature description Dekel added.
> > > > > >>> This patch also updates all the PMDs support an LRO for non-0
> value.
> > > > > >>
> > > > > >> Of course I can see the updates Matan, my point is "What
> > > > > >> happens if PMD doesn't provide 'max_lro_pkt_size'",
> > > > > >> 1) There is no check for it right, so it is acceptable?
> > > > > >
> > > > > > There is check.
> > > > > > If the capability is 0, any non-zero configuration will fail.
> > > > > >
> > > > > >> 2) Are we making this filed mandatory to provide for PMDs, it
> > > > > >> is easy to make new fields mandatory for PMDs but is this
> > > > > >> really
> > > necessary?
> > > > > >
> > > > > > Yes, for consistence.
> > > > > >
> > > > > >>>
> > > > > >>> as same as max rx pkt len, no?
> > > > > >>>
> > > > > >>>> - What do you think setting 'max_lro_pkt_size' config value
> > > > > >>>> to what PMD provided if application doesn't provide it?
> > > > > >>> Same answers as above.
> > > > > >>>
> > > > > >>
> > > > > >> If application doesn't care the value, as it has been till
> > > > > >> now, and not provided explicit 'max_lro_pkt_size', why not
> > > > > >> ethdev level use the value provided by PMD instead of failing?
> > > > > >
> > > > > > Again, same question we can ask on max rx pkt len.
> > > > > >
> > > > > > Looks like the packet size is very important value which
> > > > > > should be set by
> > > > > the application.
> > > > > >
> > > > > > Previous applications have no option to configure it, so they
> > > > > > haven't
> > > > > configure it, (probably cover it somehow) I think it is our miss
> > > > > to supply this info.
> > > > > >
> > > > > > Let's do it in same way as we do max rx pkt len (as this patch main
> idea).
> > > > > > Later, we can change both to other meaning.
> > > > > >
> > > > >
> > > > > I think it is not a good reason to introduce a new mandatory
> > > > > config option for application because of 'max_rx_pkt_len' does it.
> > > >
> > > > It is mandatory only if LRO offload is configured.
> > >
> > > So max_rx_pkt_len will remain max size of one packet, while
> > > max_lro_len will be max accumulate size for each LRO session?
> > >
> >
> > Yes.
> >
> > > BTW, I think that for ixgbe max lro is RTE_IPV4_MAX_PKT_LEN.
> >
> > Please see my change in drivers/net/ixgbe/ixgbe_ethdev.c.
> > Change to RTE_IPV4_MAX_PKT_LEN?
> >
> > > ixgbe_vf, as I remember, doesn’t support LRO at all.
> >
> > Please see my change in drivers/net/ixgbe/ixgbe_vf_representor.c
> > Remove it?
>
> Yes, please for both.
Will change in v5.
>
> >
> > >
> > > >
> > > > > Will it work, if:
> > > > > - If application doesn't provide this value, use the PMD max
> > > >
> > > > May cause a problem if the mbuf size is not enough for the PMD
> maximum.
> > >
> > > Another question, what will happen if PMD will ignore that value and
> > > will generate packets bigger then requested?
> >
> > PMD should use this value and not ignore it.
>
> Hmm, ok but this patch updates mxl driver only...
> I suppose you expect other PMD maintainers to do the job for their PMDs,
> right?
> If so, are they aware (and agree) for this new hard requirement and changes
> required?
> Again what PMD should do if it can't support exact value?
> Let say user asked max_lro_size=20KB but PMD can do only 16KB or 24KB?
> Should it fail, or round to smallest, or ...?
>
> Actually I wonder, should it really be a hard requirement or more like a
> guidance to PMD?
> Why app needs and *exact* value for LRO size?
The exact value should be configured to HW as LRO session limit.
>
>
> > >
> > > >
> > > > > - If both application and PMD doesn't provide this value, fail
> > > > > on
> > > configure()?
> > > >
> > > > It will work.
> > > > In my opinion - not ideal.
> > > >
> > > > Matan
> > > >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
2019-11-08 14:10 0% ` Dekel Peled
@ 2019-11-08 14:52 0% ` Ananyev, Konstantin
2019-11-08 16:08 0% ` Dekel Peled
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2019-11-08 14:52 UTC (permalink / raw)
To: Dekel Peled, Matan Azrad, Yigit, Ferruh, Mcnamara, John,
Kovacevic, Marko, nhorman, ajit.khaparde, somnath.kotur, Burakov,
Anatoly, xuanziyang2, cloud.wangxiaoyun, zhouguoyang, Lu,
Wenzhuo, Shahaf Shuler, Slava Ovsiienko, rmody, shshaikh,
maxime.coquelin, Bie, Tiwei, Wang, Zhihong, yongwang,
Thomas Monjalon, arybchenko, Wu, Jingjing, Iremonger, Bernard
Cc: dev
> > > > >>>> On 11/7/2019 12:35 PM, Dekel Peled wrote:
> > > > >>>>> @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
> > > > >>>>>
> > > > >>>> RTE_ETHER_MAX_LEN;
> > > > >>>>> }
> > > > >>>>>
> > > > >>>>> + /*
> > > > >>>>> + * If LRO is enabled, check that the maximum aggregated
> > > > packet
> > > > >>>>> + * size is supported by the configured device.
> > > > >>>>> + */
> > > > >>>>> + if (dev_conf->rxmode.offloads &
> > > > DEV_RX_OFFLOAD_TCP_LRO) {
> > > > >>>>> + ret = check_lro_pkt_size(
> > > > >>>>> + port_id, dev_conf-
> > > > >>>>> rxmode.max_lro_pkt_size,
> > > > >>>>> + dev_info.max_lro_pkt_size);
> > > > >>>>> + if (ret != 0)
> > > > >>>>> + goto rollback;
> > > > >>>>> + }
> > > > >>>>> +
> > > > >>>>
> > > > >>>> This check forces applications that enable LRO to provide
> > > > >> 'max_lro_pkt_size'
> > > > >>>> config value.
> > > > >>>
> > > > >>> Yes.(we can break an API, we noticed it)
> > > > >>
> > > > >> I am not talking about API/ABI breakage, that part is OK.
> > > > >> With this check, if the application requested LRO offload but not
> > > > >> provided 'max_lro_pkt_size' value, device configuration will fail.
> > > > >>
> > > > > Yes
> > > > >> Can there be a case application is good with whatever the PMD can
> > > > >> support as max?
> > > > > Yes can be - you know, we can do everything we want but it is
> > > > > better to be
> > > > consistent:
> > > > > Due to the fact of Max rx pkt len field is mandatory for JUMBO
> > > > > offload, max
> > > > lro pkt len should be mandatory for LRO offload.
> > > > >
> > > > > So your question is actually why both, non-lro packets and LRO
> > > > > packets max
> > > > size are mandatory...
> > > > >
> > > > >
> > > > > I think it should be important values for net applications management.
> > > > > Also good for mbuf size managements.
> > > > >
> > > > >>>
> > > > >>>> - Why it is mandatory now, how it was working before if it is
> > > > >>>> mandatory value?
> > > > >>>
> > > > >>> It is the same as max_rx_pkt_len which is mandatory for jumbo
> > > > >>> frame
> > > > >> offload.
> > > > >>> So now, when the user configures a LRO offload he must to set
> > > > >>> max lro pkt
> > > > >> len.
> > > > >>> We don't want to confuse the user here with the max rx pkt len
> > > > >> configurations and behaviors, they should be with same logic.
> > > > >>>
> > > > >>> This parameter defines well the LRO behavior.
> > > > >>> Before this, each PMD took its own interpretation to what should
> > > > >>> be the
> > > > >> maximum size for LRO aggregated packets.
> > > > >>> Now, the user must say what is his intension, and the ethdev can
> > > > >>> limit it
> > > > >> according to the device capability.
> > > > >>> By this way, also, the PMD can organize\optimize its data-path more.
> > > > >>> Also, the application can create different mempools for LRO
> > > > >>> queues to
> > > > >> allow bigger packet receiving for LRO traffic.
> > > > >>>
> > > > >>>> - What happens if PMD doesn't provide 'max_lro_pkt_size', so it is
> > '0'?
> > > > >>> Yes, you can see the feature description Dekel added.
> > > > >>> This patch also updates all the PMDs support an LRO for non-0 value.
> > > > >>
> > > > >> Of course I can see the updates Matan, my point is "What happens
> > > > >> if PMD doesn't provide 'max_lro_pkt_size'",
> > > > >> 1) There is no check for it right, so it is acceptable?
> > > > >
> > > > > There is check.
> > > > > If the capability is 0, any non-zero configuration will fail.
> > > > >
> > > > >> 2) Are we making this filed mandatory to provide for PMDs, it is
> > > > >> easy to make new fields mandatory for PMDs but is this really
> > necessary?
> > > > >
> > > > > Yes, for consistence.
> > > > >
> > > > >>>
> > > > >>> as same as max rx pkt len, no?
> > > > >>>
> > > > >>>> - What do you think setting 'max_lro_pkt_size' config value to
> > > > >>>> what PMD provided if application doesn't provide it?
> > > > >>> Same answers as above.
> > > > >>>
> > > > >>
> > > > >> If application doesn't care the value, as it has been till now,
> > > > >> and not provided explicit 'max_lro_pkt_size', why not ethdev
> > > > >> level use the value provided by PMD instead of failing?
> > > > >
> > > > > Again, same question we can ask on max rx pkt len.
> > > > >
> > > > > Looks like the packet size is very important value which should be
> > > > > set by
> > > > the application.
> > > > >
> > > > > Previous applications have no option to configure it, so they
> > > > > haven't
> > > > configure it, (probably cover it somehow) I think it is our miss to
> > > > supply this info.
> > > > >
> > > > > Let's do it in same way as we do max rx pkt len (as this patch main idea).
> > > > > Later, we can change both to other meaning.
> > > > >
> > > >
> > > > I think it is not a good reason to introduce a new mandatory config
> > > > option for application because of 'max_rx_pkt_len' does it.
> > >
> > > It is mandatory only if LRO offload is configured.
> >
> > So max_rx_pkt_len will remain max size of one packet, while max_lro_len
> > will be max accumulate size for each LRO session?
> >
>
> Yes.
>
> > BTW, I think that for ixgbe max lro is RTE_IPV4_MAX_PKT_LEN.
>
> Please see my change in drivers/net/ixgbe/ixgbe_ethdev.c.
> Change to RTE_IPV4_MAX_PKT_LEN?
>
> > ixgbe_vf, as I remember, doesn’t support LRO at all.
>
> Please see my change in drivers/net/ixgbe/ixgbe_vf_representor.c
> Remove it?
Yes, please for both.
>
> >
> > >
> > > > Will it work, if:
> > > > - If application doesn't provide this value, use the PMD max
> > >
> > > May cause a problem if the mbuf size is not enough for the PMD maximum.
> >
> > Another question, what will happen if PMD will ignore that value and will
> > generate packets bigger then requested?
>
> PMD should use this value and not ignore it.
Hmm, ok but this patch updates mxl driver only...
I suppose you expect other PMD maintainers to do the job for their PMDs, right?
If so, are they aware (and agree) for this new hard requirement and changes required?
Again what PMD should do if it can't support exact value?
Let say user asked max_lro_size=20KB but PMD can do only 16KB or 24KB?
Should it fail, or round to smallest, or ...?
Actually I wonder, should it really be a hard requirement or more like a guidance to PMD?
Why app needs and *exact* value for LRO size?
> >
> > >
> > > > - If both application and PMD doesn't provide this value, fail on
> > configure()?
> > >
> > > It will work.
> > > In my opinion - not ideal.
> > >
> > > Matan
> > >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
2019-11-08 13:11 0% ` Ananyev, Konstantin
@ 2019-11-08 14:10 0% ` Dekel Peled
2019-11-08 14:52 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Dekel Peled @ 2019-11-08 14:10 UTC (permalink / raw)
To: Ananyev, Konstantin, Matan Azrad, Yigit, Ferruh, Mcnamara, John,
Kovacevic, Marko, nhorman, ajit.khaparde, somnath.kotur, Burakov,
Anatoly, xuanziyang2, cloud.wangxiaoyun, zhouguoyang, Lu,
Wenzhuo, Shahaf Shuler, Slava Ovsiienko, rmody, shshaikh,
maxime.coquelin, Bie, Tiwei, Wang, Zhihong, yongwang,
Thomas Monjalon, arybchenko, Wu, Jingjing, Iremonger, Bernard
Cc: dev
Thanks, PSB.
> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Sent: Friday, November 8, 2019 3:11 PM
> To: Matan Azrad <matan@mellanox.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Dekel Peled <dekelp@mellanox.com>; Mcnamara,
> John <john.mcnamara@intel.com>; Kovacevic, Marko
> <marko.kovacevic@intel.com>; nhorman@tuxdriver.com;
> ajit.khaparde@broadcom.com; somnath.kotur@broadcom.com; Burakov,
> Anatoly <anatoly.burakov@intel.com>; xuanziyang2@huawei.com;
> cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com; Lu, Wenzhuo
> <wenzhuo.lu@intel.com>; Shahaf Shuler <shahafs@mellanox.com>; Slava
> Ovsiienko <viacheslavo@mellanox.com>; rmody@marvell.com;
> shshaikh@marvell.com; maxime.coquelin@redhat.com; Bie, Tiwei
> <tiwei.bie@intel.com>; Wang, Zhihong <zhihong.wang@intel.com>;
> yongwang@vmware.com; Thomas Monjalon <thomas@monjalon.net>;
> arybchenko@solarflare.com; Wu, Jingjing <jingjing.wu@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO
> packet size
>
>
>
> > -----Original Message-----
> > From: Matan Azrad <matan@mellanox.com>
> > Sent: Friday, November 8, 2019 11:56 AM
> > To: Yigit, Ferruh <ferruh.yigit@intel.com>; Dekel Peled
> > <dekelp@mellanox.com>; Mcnamara, John <john.mcnamara@intel.com>;
> > Kovacevic, Marko <marko.kovacevic@intel.com>;
> nhorman@tuxdriver.com;
> > ajit.khaparde@broadcom.com; somnath.kotur@broadcom.com; Burakov,
> > Anatoly <anatoly.burakov@intel.com>; xuanziyang2@huawei.com;
> > cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com; Lu,
> Wenzhuo
> > <wenzhuo.lu@intel.com>; Ananyev, Konstantin
> > <konstantin.ananyev@intel.com>; Shahaf Shuler
> <shahafs@mellanox.com>;
> > Slava Ovsiienko <viacheslavo@mellanox.com>; rmody@marvell.com;
> > shshaikh@marvell.com; maxime.coquelin@redhat.com; Bie, Tiwei
> > <tiwei.bie@intel.com>; Wang, Zhihong <zhihong.wang@intel.com>;
> > yongwang@vmware.com; Thomas Monjalon <thomas@monjalon.net>;
> > arybchenko@solarflare.com; Wu, Jingjing <jingjing.wu@intel.com>;
> > Iremonger, Bernard <bernard.iremonger@intel.com>
> > Cc: dev@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max
> > LRO packet size
> >
> >
> >
> > From: Ferruh Yigit
> > > On 11/8/2019 10:10 AM, Matan Azrad wrote:
> > > >
> > > >
> > > > From: Ferruh Yigit
> > > >> On 11/8/2019 6:54 AM, Matan Azrad wrote:
> > > >>> Hi
> > > >>>
> > > >>> From: Ferruh Yigit
> > > >>>> On 11/7/2019 12:35 PM, Dekel Peled wrote:
> > > >>>>> @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
> > > >>>>>
> > > >>>> RTE_ETHER_MAX_LEN;
> > > >>>>> }
> > > >>>>>
> > > >>>>> + /*
> > > >>>>> + * If LRO is enabled, check that the maximum aggregated
> > > packet
> > > >>>>> + * size is supported by the configured device.
> > > >>>>> + */
> > > >>>>> + if (dev_conf->rxmode.offloads &
> > > DEV_RX_OFFLOAD_TCP_LRO) {
> > > >>>>> + ret = check_lro_pkt_size(
> > > >>>>> + port_id, dev_conf-
> > > >>>>> rxmode.max_lro_pkt_size,
> > > >>>>> + dev_info.max_lro_pkt_size);
> > > >>>>> + if (ret != 0)
> > > >>>>> + goto rollback;
> > > >>>>> + }
> > > >>>>> +
> > > >>>>
> > > >>>> This check forces applications that enable LRO to provide
> > > >> 'max_lro_pkt_size'
> > > >>>> config value.
> > > >>>
> > > >>> Yes.(we can break an API, we noticed it)
> > > >>
> > > >> I am not talking about API/ABI breakage, that part is OK.
> > > >> With this check, if the application requested LRO offload but not
> > > >> provided 'max_lro_pkt_size' value, device configuration will fail.
> > > >>
> > > > Yes
> > > >> Can there be a case application is good with whatever the PMD can
> > > >> support as max?
> > > > Yes can be - you know, we can do everything we want but it is
> > > > better to be
> > > consistent:
> > > > Due to the fact of Max rx pkt len field is mandatory for JUMBO
> > > > offload, max
> > > lro pkt len should be mandatory for LRO offload.
> > > >
> > > > So your question is actually why both, non-lro packets and LRO
> > > > packets max
> > > size are mandatory...
> > > >
> > > >
> > > > I think it should be important values for net applications management.
> > > > Also good for mbuf size managements.
> > > >
> > > >>>
> > > >>>> - Why it is mandatory now, how it was working before if it is
> > > >>>> mandatory value?
> > > >>>
> > > >>> It is the same as max_rx_pkt_len which is mandatory for jumbo
> > > >>> frame
> > > >> offload.
> > > >>> So now, when the user configures a LRO offload he must to set
> > > >>> max lro pkt
> > > >> len.
> > > >>> We don't want to confuse the user here with the max rx pkt len
> > > >> configurations and behaviors, they should be with same logic.
> > > >>>
> > > >>> This parameter defines well the LRO behavior.
> > > >>> Before this, each PMD took its own interpretation to what should
> > > >>> be the
> > > >> maximum size for LRO aggregated packets.
> > > >>> Now, the user must say what is his intension, and the ethdev can
> > > >>> limit it
> > > >> according to the device capability.
> > > >>> By this way, also, the PMD can organize\optimize its data-path more.
> > > >>> Also, the application can create different mempools for LRO
> > > >>> queues to
> > > >> allow bigger packet receiving for LRO traffic.
> > > >>>
> > > >>>> - What happens if PMD doesn't provide 'max_lro_pkt_size', so it is
> '0'?
> > > >>> Yes, you can see the feature description Dekel added.
> > > >>> This patch also updates all the PMDs support an LRO for non-0 value.
> > > >>
> > > >> Of course I can see the updates Matan, my point is "What happens
> > > >> if PMD doesn't provide 'max_lro_pkt_size'",
> > > >> 1) There is no check for it right, so it is acceptable?
> > > >
> > > > There is check.
> > > > If the capability is 0, any non-zero configuration will fail.
> > > >
> > > >> 2) Are we making this filed mandatory to provide for PMDs, it is
> > > >> easy to make new fields mandatory for PMDs but is this really
> necessary?
> > > >
> > > > Yes, for consistence.
> > > >
> > > >>>
> > > >>> as same as max rx pkt len, no?
> > > >>>
> > > >>>> - What do you think setting 'max_lro_pkt_size' config value to
> > > >>>> what PMD provided if application doesn't provide it?
> > > >>> Same answers as above.
> > > >>>
> > > >>
> > > >> If application doesn't care the value, as it has been till now,
> > > >> and not provided explicit 'max_lro_pkt_size', why not ethdev
> > > >> level use the value provided by PMD instead of failing?
> > > >
> > > > Again, same question we can ask on max rx pkt len.
> > > >
> > > > Looks like the packet size is very important value which should be
> > > > set by
> > > the application.
> > > >
> > > > Previous applications have no option to configure it, so they
> > > > haven't
> > > configure it, (probably cover it somehow) I think it is our miss to
> > > supply this info.
> > > >
> > > > Let's do it in same way as we do max rx pkt len (as this patch main idea).
> > > > Later, we can change both to other meaning.
> > > >
> > >
> > > I think it is not a good reason to introduce a new mandatory config
> > > option for application because of 'max_rx_pkt_len' does it.
> >
> > It is mandatory only if LRO offload is configured.
>
> So max_rx_pkt_len will remain max size of one packet, while max_lro_len
> will be max accumulate size for each LRO session?
>
Yes.
> BTW, I think that for ixgbe max lro is RTE_IPV4_MAX_PKT_LEN.
Please see my change in drivers/net/ixgbe/ixgbe_ethdev.c.
Change to RTE_IPV4_MAX_PKT_LEN?
> ixgbe_vf, as I remember, doesn’t support LRO at all.
Please see my change in drivers/net/ixgbe/ixgbe_vf_representor.c
Remove it?
>
> >
> > > Will it work, if:
> > > - If application doesn't provide this value, use the PMD max
> >
> > May cause a problem if the mbuf size is not enough for the PMD maximum.
>
> Another question, what will happen if PMD will ignore that value and will
> generate packets bigger then requested?
PMD should use this value and not ignore it.
>
> >
> > > - If both application and PMD doesn't provide this value, fail on
> configure()?
> >
> > It will work.
> > In my opinion - not ideal.
> >
> > Matan
> >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions
2019-11-06 21:07 10% ` Thomas Monjalon
@ 2019-11-08 14:09 5% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-11-08 14:09 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, stephen, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
On 06/11/2019 21:07, Thomas Monjalon wrote:
> Hi,
> Please find the techboard comments below.
>
> 06/11/2019 10:22, Ray Kinsella:
>> On 06/11/2019 09:06, Thomas Monjalon wrote:
>>> 06/11/2019 09:49, Ray Kinsella:
>>>> On 06/11/2019 00:11, Thomas Monjalon wrote:
>>>>> 05/11/2019 16:24, Ray Kinsella:
>>>>>> +#. Major ABI versions are declared every **year** and are then supported for one
>>>>>> + year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
>>>>>
>>>>> As discussed earlier, a major ABI version can be declared less often
>>>>> than one year in the future.
>>>>> An ABI is supported more than one year, because of the LTS branches.
>>>>> That's why I propose to replace with this sentence:
>>>>> "
>>>>> Major ABI versions are declared regularly and are then supported for
>>>>> at least one year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
>>>>> "
>>>>
>>>> So look, this one was a decision of the technical board.
>>>
>>> The techboard didn't decide to change the ABI every year.
>>> We decided to review the duration after the first year, with a plan to extend.
>>>
>>>> My position is still what was agreed was, "declared every year, and supported for one year".
>>>> I like it, it's crystal clear what is the policy, until we change the policy.
>>>
>>> I think it gives a wrong message.
>>>
>>>> That said, I can make the change no problem, but I need some others to chime in to ok it.
>>>> Perhaps at the head of the Techboard today?
>>>
>>> Yes I add it to the techboard meeting.
>
> The techboard propose other rewords:
> "supported" may be replaced with "compatibility is enforced"
> "every year" may be replaced with "no more frequently than every year"
> "declared" may be replaced with "could be declared"
>
> I think you got the idea. Please adjust wording to something more accurate.
>
> ###
ACK - done in v9
>
>>>>>> +A major ABI version is declared every year, aligned with that year's LTS
>>>>>> +release, e.g. v19.11. This ABI version is then supported for one year by all
>>>>>> +subsequent releases within that time period, until the next LTS release, e.g.
>>>>>> +v20.11.
>>>>>
>>>>> Let's reword like this:
>>>>> "
>>>>> A new major ABI version can be declared when a new LTS branch is started,
>
> It has been suggested to replace "can" with "may".
ACK - I loosened the wording as described above "no more frequently than every year" etc in v9
>
>>>>> e.g. ABI 19 for DPDK 19.11.0.
>>>>> This major ABI version is then supported until the next one,
>>>>> e.g. ABI 20 for DPDK 20.11.0.
>>>>> All ABI changes must be detailed in the release notes.
>>>>> "
>
> My reword is wrong because ABI versions should be 20 and 21 respectively.
ACK - fixed
>
>>>> This is more ambiguous, although what I said above stands.
>>>
>>> What you said is wrong because of 2 reasons:
>>> - it is not always one year for an major ABI
>>
>> Well that is a point of disagreement.
>
> The techboard agreed to remove "every year".
ACK - loosened the wording.
>>
>>> - it is always longer because of LTS branch
>>
>> Well I was pretty careful to qualify the ABI policy applies to releases over the year.
>> To distinguish it from LTS branch.
>
> As above, we may replace "ABI is supported" with
> "ABI compatibility is enforced".
>
>>>> If there is general agreement with changing this part of the policy, I am ok to make
>>>> the change.
>>>
>>> Yes let's review with the techboard.
>
> Please try to reflect techboard comments while keeping something understandable :)
>
> ###
ACK - yes, it is readable.
>
>>>>>> + ABI breakages due to changes such as reorganizing public
>>>>>> + structure fields for aesthetic or readability purposes should be avoided.
>>>>>
>>>>> Why it should be avoided?
>>>>> If the ABI is broken anyway, I don't see any reason to not break it more.
>>>>
>>>> This is text from the original ABI Policy - I think the general sentiment still stands.
>>>> Just because you have an ABI Breakage window doesn't mean you should feel free to break
>>>> the ABI. The 3 ACKs required from Technical Board member to change the ABI, are another
>>>> reflection of this.
>>>>
>>>> As a general rule.
>>>> Unnecessary changes should still be avoided, to reduce ABI churn between ABI versions.
>>>
>>> I agree we must avoid unnecessary API changes because it requires apps to adapt.
>>> But if the change is only ABI, and we are in an ABI-change window,
>>> I don't see any issue
>
> The techboard agrees that the ABI changes are unlimited but API changes must be avoided.
> It is suggested to replace "ABI" with "API". I think this reword is better:
> "
> API changes such as reorganizing public structure fields
> for aesthetic or readability purposes should be avoided.
> "
>
> ###
ACK - done
>
>>>>>> +Libraries marked as ``experimental`` are entirely not considered part of an ABI
>>>>>> +version, and may change without warning at any time. Experimental libraries
>>>>>> +always have a major version of ``0`` to indicate they exist outside of
>>>>>> +ABI Versioning, with the minor version incremented with each ABI change
>>>>>> +to library.
>>>>>
>>>>> It means not all libraries will have the same ABI version.
>>>>> It is contrary of "ABI version is managed at a project level",
>>>>> and I don't see a real benefit of a different version number.
>>>>
>>>> There is a benefit, major version 0 is a very clear indication that
>>>> the library exists outside of ABI management.
>>>> A library isn't in the ABI, until it is in the ABI - an then it gets
>>>> added to the major version number.
>>>>
>>>>> Anyway, some experimental functions can live inside a library
>>>>> with a stable ABI version number
>>>>
>>>> True, but if an entire library is experimental - let's be crystal
>>>> clear about that.
>>>
>>> I would like to see what others think.
>
> The techboard decided to keep this policy: .0 for pure experimental libs.
>
>
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
2019-11-08 11:56 0% ` Matan Azrad
2019-11-08 12:51 0% ` Ferruh Yigit
@ 2019-11-08 13:11 0% ` Ananyev, Konstantin
2019-11-08 14:10 0% ` Dekel Peled
1 sibling, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2019-11-08 13:11 UTC (permalink / raw)
To: Matan Azrad, Yigit, Ferruh, Dekel Peled, Mcnamara, John,
Kovacevic, Marko, nhorman, ajit.khaparde, somnath.kotur, Burakov,
Anatoly, xuanziyang2, cloud.wangxiaoyun, zhouguoyang, Lu,
Wenzhuo, Shahaf Shuler, Slava Ovsiienko, rmody, shshaikh,
maxime.coquelin, Bie, Tiwei, Wang, Zhihong, yongwang,
Thomas Monjalon, arybchenko, Wu, Jingjing, Iremonger, Bernard
Cc: dev
> -----Original Message-----
> From: Matan Azrad <matan@mellanox.com>
> Sent: Friday, November 8, 2019 11:56 AM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Dekel Peled <dekelp@mellanox.com>; Mcnamara, John <john.mcnamara@intel.com>;
> Kovacevic, Marko <marko.kovacevic@intel.com>; nhorman@tuxdriver.com; ajit.khaparde@broadcom.com;
> somnath.kotur@broadcom.com; Burakov, Anatoly <anatoly.burakov@intel.com>; xuanziyang2@huawei.com;
> cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Shahaf Shuler <shahafs@mellanox.com>; Slava Ovsiienko <viacheslavo@mellanox.com>;
> rmody@marvell.com; shshaikh@marvell.com; maxime.coquelin@redhat.com; Bie, Tiwei <tiwei.bie@intel.com>; Wang, Zhihong
> <zhihong.wang@intel.com>; yongwang@vmware.com; Thomas Monjalon <thomas@monjalon.net>; arybchenko@solarflare.com; Wu,
> Jingjing <jingjing.wu@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
>
>
>
> From: Ferruh Yigit
> > On 11/8/2019 10:10 AM, Matan Azrad wrote:
> > >
> > >
> > > From: Ferruh Yigit
> > >> On 11/8/2019 6:54 AM, Matan Azrad wrote:
> > >>> Hi
> > >>>
> > >>> From: Ferruh Yigit
> > >>>> On 11/7/2019 12:35 PM, Dekel Peled wrote:
> > >>>>> @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
> > >>>>>
> > >>>> RTE_ETHER_MAX_LEN;
> > >>>>> }
> > >>>>>
> > >>>>> + /*
> > >>>>> + * If LRO is enabled, check that the maximum aggregated
> > packet
> > >>>>> + * size is supported by the configured device.
> > >>>>> + */
> > >>>>> + if (dev_conf->rxmode.offloads &
> > DEV_RX_OFFLOAD_TCP_LRO) {
> > >>>>> + ret = check_lro_pkt_size(
> > >>>>> + port_id, dev_conf-
> > >>>>> rxmode.max_lro_pkt_size,
> > >>>>> + dev_info.max_lro_pkt_size);
> > >>>>> + if (ret != 0)
> > >>>>> + goto rollback;
> > >>>>> + }
> > >>>>> +
> > >>>>
> > >>>> This check forces applications that enable LRO to provide
> > >> 'max_lro_pkt_size'
> > >>>> config value.
> > >>>
> > >>> Yes.(we can break an API, we noticed it)
> > >>
> > >> I am not talking about API/ABI breakage, that part is OK.
> > >> With this check, if the application requested LRO offload but not
> > >> provided 'max_lro_pkt_size' value, device configuration will fail.
> > >>
> > > Yes
> > >> Can there be a case application is good with whatever the PMD can
> > >> support as max?
> > > Yes can be - you know, we can do everything we want but it is better to be
> > consistent:
> > > Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
> > lro pkt len should be mandatory for LRO offload.
> > >
> > > So your question is actually why both, non-lro packets and LRO packets max
> > size are mandatory...
> > >
> > >
> > > I think it should be important values for net applications management.
> > > Also good for mbuf size managements.
> > >
> > >>>
> > >>>> - Why it is mandatory now, how it was working before if it is
> > >>>> mandatory value?
> > >>>
> > >>> It is the same as max_rx_pkt_len which is mandatory for jumbo frame
> > >> offload.
> > >>> So now, when the user configures a LRO offload he must to set max
> > >>> lro pkt
> > >> len.
> > >>> We don't want to confuse the user here with the max rx pkt len
> > >> configurations and behaviors, they should be with same logic.
> > >>>
> > >>> This parameter defines well the LRO behavior.
> > >>> Before this, each PMD took its own interpretation to what should be
> > >>> the
> > >> maximum size for LRO aggregated packets.
> > >>> Now, the user must say what is his intension, and the ethdev can
> > >>> limit it
> > >> according to the device capability.
> > >>> By this way, also, the PMD can organize\optimize its data-path more.
> > >>> Also, the application can create different mempools for LRO queues
> > >>> to
> > >> allow bigger packet receiving for LRO traffic.
> > >>>
> > >>>> - What happens if PMD doesn't provide 'max_lro_pkt_size', so it is '0'?
> > >>> Yes, you can see the feature description Dekel added.
> > >>> This patch also updates all the PMDs support an LRO for non-0 value.
> > >>
> > >> Of course I can see the updates Matan, my point is "What happens if
> > >> PMD doesn't provide 'max_lro_pkt_size'",
> > >> 1) There is no check for it right, so it is acceptable?
> > >
> > > There is check.
> > > If the capability is 0, any non-zero configuration will fail.
> > >
> > >> 2) Are we making this filed mandatory to provide for PMDs, it is easy
> > >> to make new fields mandatory for PMDs but is this really necessary?
> > >
> > > Yes, for consistence.
> > >
> > >>>
> > >>> as same as max rx pkt len, no?
> > >>>
> > >>>> - What do you think setting 'max_lro_pkt_size' config value to what
> > >>>> PMD provided if application doesn't provide it?
> > >>> Same answers as above.
> > >>>
> > >>
> > >> If application doesn't care the value, as it has been till now, and
> > >> not provided explicit 'max_lro_pkt_size', why not ethdev level use
> > >> the value provided by PMD instead of failing?
> > >
> > > Again, same question we can ask on max rx pkt len.
> > >
> > > Looks like the packet size is very important value which should be set by
> > the application.
> > >
> > > Previous applications have no option to configure it, so they haven't
> > configure it, (probably cover it somehow) I think it is our miss to supply this
> > info.
> > >
> > > Let's do it in same way as we do max rx pkt len (as this patch main idea).
> > > Later, we can change both to other meaning.
> > >
> >
> > I think it is not a good reason to introduce a new mandatory config option for
> > application because of 'max_rx_pkt_len' does it.
>
> It is mandatory only if LRO offload is configured.
So max_rx_pkt_len will remain max size of one packet,
while max_lro_len will be max accumulate size for each LRO session?
BTW, I think that for ixgbe max lro is RTE_IPV4_MAX_PKT_LEN.
ixgbe_vf, as I remember, doesn’t support LRO at all.
>
> > Will it work, if:
> > - If application doesn't provide this value, use the PMD max
>
> May cause a problem if the mbuf size is not enough for the PMD maximum.
Another question, what will happen if PMD will ignore that value and will
generate packets bigger then requested?
>
> > - If both application and PMD doesn't provide this value, fail on configure()?
>
> It will work.
> In my opinion - not ideal.
>
> Matan
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
2019-11-08 11:56 0% ` Matan Azrad
@ 2019-11-08 12:51 0% ` Ferruh Yigit
2019-11-08 16:11 0% ` Dekel Peled
2019-11-08 13:11 0% ` Ananyev, Konstantin
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-11-08 12:51 UTC (permalink / raw)
To: Matan Azrad, Dekel Peled, john.mcnamara, marko.kovacevic,
nhorman, ajit.khaparde, somnath.kotur, anatoly.burakov,
xuanziyang2, cloud.wangxiaoyun, zhouguoyang, wenzhuo.lu,
konstantin.ananyev, Shahaf Shuler, Slava Ovsiienko, rmody,
shshaikh, maxime.coquelin, tiwei.bie, zhihong.wang, yongwang,
Thomas Monjalon, arybchenko, jingjing.wu, bernard.iremonger
Cc: dev
On 11/8/2019 11:56 AM, Matan Azrad wrote:
>
>
> From: Ferruh Yigit
>> On 11/8/2019 10:10 AM, Matan Azrad wrote:
>>>
>>>
>>> From: Ferruh Yigit
>>>> On 11/8/2019 6:54 AM, Matan Azrad wrote:
>>>>> Hi
>>>>>
>>>>> From: Ferruh Yigit
>>>>>> On 11/7/2019 12:35 PM, Dekel Peled wrote:
>>>>>>> @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
>>>>>>>
>>>>>> RTE_ETHER_MAX_LEN;
>>>>>>> }
>>>>>>>
>>>>>>> + /*
>>>>>>> + * If LRO is enabled, check that the maximum aggregated
>> packet
>>>>>>> + * size is supported by the configured device.
>>>>>>> + */
>>>>>>> + if (dev_conf->rxmode.offloads &
>> DEV_RX_OFFLOAD_TCP_LRO) {
>>>>>>> + ret = check_lro_pkt_size(
>>>>>>> + port_id, dev_conf-
>>>>>>> rxmode.max_lro_pkt_size,
>>>>>>> + dev_info.max_lro_pkt_size);
>>>>>>> + if (ret != 0)
>>>>>>> + goto rollback;
>>>>>>> + }
>>>>>>> +
>>>>>>
>>>>>> This check forces applications that enable LRO to provide
>>>> 'max_lro_pkt_size'
>>>>>> config value.
>>>>>
>>>>> Yes.(we can break an API, we noticed it)
>>>>
>>>> I am not talking about API/ABI breakage, that part is OK.
>>>> With this check, if the application requested LRO offload but not
>>>> provided 'max_lro_pkt_size' value, device configuration will fail.
>>>>
>>> Yes
>>>> Can there be a case application is good with whatever the PMD can
>>>> support as max?
>>> Yes can be - you know, we can do everything we want but it is better to be
>> consistent:
>>> Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
>> lro pkt len should be mandatory for LRO offload.
>>>
>>> So your question is actually why both, non-lro packets and LRO packets max
>> size are mandatory...
>>>
>>>
>>> I think it should be important values for net applications management.
>>> Also good for mbuf size managements.
>>>
>>>>>
>>>>>> - Why it is mandatory now, how it was working before if it is
>>>>>> mandatory value?
>>>>>
>>>>> It is the same as max_rx_pkt_len which is mandatory for jumbo frame
>>>> offload.
>>>>> So now, when the user configures a LRO offload he must to set max
>>>>> lro pkt
>>>> len.
>>>>> We don't want to confuse the user here with the max rx pkt len
>>>> configurations and behaviors, they should be with same logic.
>>>>>
>>>>> This parameter defines well the LRO behavior.
>>>>> Before this, each PMD took its own interpretation to what should be
>>>>> the
>>>> maximum size for LRO aggregated packets.
>>>>> Now, the user must say what is his intension, and the ethdev can
>>>>> limit it
>>>> according to the device capability.
>>>>> By this way, also, the PMD can organize\optimize its data-path more.
>>>>> Also, the application can create different mempools for LRO queues
>>>>> to
>>>> allow bigger packet receiving for LRO traffic.
>>>>>
>>>>>> - What happens if PMD doesn't provide 'max_lro_pkt_size', so it is '0'?
>>>>> Yes, you can see the feature description Dekel added.
>>>>> This patch also updates all the PMDs support an LRO for non-0 value.
>>>>
>>>> Of course I can see the updates Matan, my point is "What happens if
>>>> PMD doesn't provide 'max_lro_pkt_size'",
>>>> 1) There is no check for it right, so it is acceptable?
>>>
>>> There is check.
>>> If the capability is 0, any non-zero configuration will fail.
>>>
>>>> 2) Are we making this filed mandatory to provide for PMDs, it is easy
>>>> to make new fields mandatory for PMDs but is this really necessary?
>>>
>>> Yes, for consistence.
>>>
>>>>>
>>>>> as same as max rx pkt len, no?
>>>>>
>>>>>> - What do you think setting 'max_lro_pkt_size' config value to what
>>>>>> PMD provided if application doesn't provide it?
>>>>> Same answers as above.
>>>>>
>>>>
>>>> If application doesn't care the value, as it has been till now, and
>>>> not provided explicit 'max_lro_pkt_size', why not ethdev level use
>>>> the value provided by PMD instead of failing?
>>>
>>> Again, same question we can ask on max rx pkt len.
>>>
>>> Looks like the packet size is very important value which should be set by
>> the application.
>>>
>>> Previous applications have no option to configure it, so they haven't
>> configure it, (probably cover it somehow) I think it is our miss to supply this
>> info.
>>>
>>> Let's do it in same way as we do max rx pkt len (as this patch main idea).
>>> Later, we can change both to other meaning.
>>>
>>
>> I think it is not a good reason to introduce a new mandatory config option for
>> application because of 'max_rx_pkt_len' does it.
>
> It is mandatory only if LRO offload is configured.
>
>> Will it work, if:
>> - If application doesn't provide this value, use the PMD max
>
> May cause a problem if the mbuf size is not enough for the PMD maximum.
OK, this is what I was missing, for this case I was thinking max_rx_pkt_len will
be used but you already explained that application may want to use different
mempools for LRO queues.
For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into account and
program the device accordingly (of course in LRO enabled case) ?
This part seems missing and should be highlighted to other PMD maintainers.
>
>> - If both application and PMD doesn't provide this value, fail on configure()?
>
> It will work.
> In my opinion - not ideal.
>
> Matan
>
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v9 4/4] doc: add maintainer for abi policy
2019-11-08 12:46 10% [dpdk-dev] [PATCH v9 0/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
` (2 preceding siblings ...)
2019-11-08 12:46 35% ` [dpdk-dev] [PATCH v9 3/4] doc: updates to versioning guide for " Ray Kinsella
@ 2019-11-08 12:46 13% ` Ray Kinsella
2019-11-08 17:18 4% ` Thomas Monjalon
3 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-11-08 12:46 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, john.mcnamara, marko.kovacevic, hemant.agrawal,
ktraynor, aconole
Add an entry to the maintainer file for the abi policy.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: John Mcnamara <john.mcnamara@intel.com>
---
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 717c318..d5bb806 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -84,6 +84,10 @@ M: Marko Kovacevic <marko.kovacevic@intel.com>
F: README
F: doc/
+ABI Policy
+M: Ray Kinsella <mdr@ashroe.eu>
+F: doc/guides/contributing/abi_*.rst
+
Developers and Maintainers Tools
M: Thomas Monjalon <thomas@monjalon.net>
F: MAINTAINERS
--
2.7.4
^ permalink raw reply [relevance 13%]
* [dpdk-dev] [PATCH v9 3/4] doc: updates to versioning guide for abi versions
2019-11-08 12:46 10% [dpdk-dev] [PATCH v9 0/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-11-08 12:46 18% ` [dpdk-dev] [PATCH v9 1/4] doc: separate versioning.rst into version and policy Ray Kinsella
2019-11-08 12:46 23% ` [dpdk-dev] [PATCH v9 2/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
@ 2019-11-08 12:46 35% ` Ray Kinsella
2019-11-08 12:46 13% ` [dpdk-dev] [PATCH v9 4/4] doc: add maintainer for abi policy Ray Kinsella
3 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-11-08 12:46 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, john.mcnamara, marko.kovacevic, hemant.agrawal,
ktraynor, aconole
Updates to the ABI versioning guide, to account for the changes to the DPDK
ABI/API policy. Fixes for references to abi versioning and policy guides.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: John Mcnamara <john.mcnamara@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/contributing/abi_policy.rst | 15 +-
doc/guides/contributing/abi_versioning.rst | 250 +++++++++++++++++++----------
doc/guides/contributing/patches.rst | 6 +-
doc/guides/rel_notes/deprecation.rst | 6 +-
4 files changed, 183 insertions(+), 94 deletions(-)
diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst
index 0965bcc..6ebdd83 100644
--- a/doc/guides/contributing/abi_policy.rst
+++ b/doc/guides/contributing/abi_policy.rst
@@ -19,11 +19,11 @@ General Guidelines
#. Major ABI version are usually but not always declared aligned with a
:ref:`LTS release <stable_lts_releases>`.
#. The ABI version is managed at a project level in DPDK, with the ABI version
- reflected in all library's soname.
+ reflected in all :ref:`library's soname <what_is_soname>`.
#. The ABI should be preserved and not changed lightly. ABI changes must follow
the outlined :ref:`deprecation process <abi_changes>`.
#. The addition of symbols is generally not problematic. The modification of
- symbols is managed with ABI Versioning.
+ symbols is managed with :ref:`ABI Versioning <abi_versioning>`.
#. The removal of symbols is considered an :ref:`ABI breakage <abi_breakages>`,
once approved these will form part of the next ABI version.
#. Libraries or APIs marked as :ref:`Experimental <experimental_apis>` are not
@@ -67,13 +67,14 @@ An ABI version is an instance of a library's ABI at a specific release. Certain
releases are considered to be milestone releases, the yearly LTS release for
example. The ABI of a milestone release may be declared as a 'major ABI
version', where this ABI version is then supported for some number of subsequent
-releases and is annotated in the library's soname.
+releases and is annotated in the library's :ref:`soname<what_is_soname>`.
ABI version support in subsequent releases facilitates application upgrades, by
enabling applications built against the milestone release to upgrade to
subsequent releases of a library without a rebuild.
-More details on major ABI version can be found in the ABI Versioning guide.
+More details on major ABI version can be found in the :ref:`ABI versioning
+<major_abi_versions>` guide.
The DPDK ABI policy
-------------------
@@ -146,7 +147,7 @@ The requirements for changing the ABI are:
CPU vendors, end-users, etc.
#. Backward compatibility with the major ABI version must be maintained through
- ABI Versioning, with :ref:`forward-only <forward-only>` compatibility
+ :ref:`abi_versioning`, with :ref:`forward-only <forward-only>` compatibility
offered for any ABI changes that are indicated to be part of the next ABI
version.
@@ -223,7 +224,7 @@ declarations of major ABI versions.
* DPDK 20.02 release defines a new function ``rte_foo(uint8_t bar)``, and
this is not a problem as long as the symbol ``rte_foo@DPDK20`` is
- preserved through ABI Versioning.
+ preserved through :ref:`abi_versioning`.
- The new function may be marked with the ``__rte_experimental`` tag for a
number of releases, as described in the section :ref:`experimental_apis`.
@@ -321,5 +322,5 @@ Libraries
Libraries marked as ``experimental`` are entirely not considered part of an ABI
version, and may change without warning at any time. Experimental libraries
always have a major version of ``0`` to indicate they exist outside of
-ABI Versioning, with the minor version incremented with each ABI change
+:ref:`abi_versioning` , with the minor version incremented with each ABI change
to library.
diff --git a/doc/guides/contributing/abi_versioning.rst b/doc/guides/contributing/abi_versioning.rst
index 1c5612c..a3d5479 100644
--- a/doc/guides/contributing/abi_versioning.rst
+++ b/doc/guides/contributing/abi_versioning.rst
@@ -1,44 +1,134 @@
.. SPDX-License-Identifier: BSD-3-Clause
Copyright 2018 The DPDK contributors
-.. library_versioning:
+.. _abi_versioning:
-Library versioning
+ABI Versioning
+==============
+
+This document details the mechanics of ABI version management in DPDK.
+
+.. _what_is_soname:
+
+What is a library's soname?
+---------------------------
+
+System libraries usually adopt the familiar major and minor version naming
+convention, where major versions (e.g. ``librte_eal 20.x, 21.x``) are presumed
+to be ABI incompatible with each other and minor versions (e.g. ``librte_eal
+20.1, 20.2``) are presumed to be ABI compatible. A library's `soname
+<https://en.wikipedia.org/wiki/Soname>`_. is typically used to provide backward
+compatibility information about a given library, describing the lowest common
+denominator ABI supported by the library. The soname or logical name for the
+library, is typically comprised of the library's name and major version e.g.
+``librte_eal.so.20``.
+
+During an application's build process, a library's soname is noted as a runtime
+dependency of the application. This information is then used by the `dynamic
+linker <https://en.wikipedia.org/wiki/Dynamic_linker>`_ when resolving the
+applications dependencies at runtime, to load a library supporting the correct
+ABI version. The library loaded at runtime therefore, may be a minor revision
+supporting the same major ABI version (e.g. ``librte_eal.20.2``), as the library
+used to link the application (e.g ``librte_eal.20.0``).
+
+.. _major_abi_versions:
+
+Major ABI versions
------------------
-Downstreams might want to provide different DPDK releases at the same time to
-support multiple consumers of DPDK linked against older and newer sonames.
+An ABI version change to a given library, especially in core libraries such as
+``librte_mbuf``, may cause an implicit ripple effect on the ABI of it's
+consuming libraries, causing ABI breakages. There may however be no explicit
+reason to bump a dependent library's ABI version, as there may have been no
+obvious change to the dependent library's API, even though the library's ABI
+compatibility will have been broken.
+
+This interdependence of DPDK libraries, means that ABI versioning of libraries
+is more manageable at a project level, with all project libraries sharing a
+**single ABI version**. In addition, the need to maintain a stable ABI for some
+number of releases as described in the section :doc:`abi_policy`, means
+that ABI version increments need to carefully planned and managed at a project
+level.
+
+Major ABI versions are therefore declared typically aligned with an LTS release
+and is then supported some number of subsequent releases, shared across all
+libraries. This means that a single project level ABI version, reflected in all
+individual library's soname, library filenames and associated version maps
+persists over multiple releases.
+
+.. code-block:: none
+
+ $ head ./lib/librte_acl/rte_acl_version.map
+ DPDK_20 {
+ global:
+ ...
-Also due to the interdependencies that DPDK libraries can have applications
-might end up with an executable space in which multiple versions of a library
-are mapped by ld.so.
+ $ head ./lib/librte_eal/rte_eal_version.map
+ DPDK_20 {
+ global:
+ ...
-Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
-depending on LibA.
+When an ABI change is made between major ABI versions to a given library, a new
+section is added to that library's version map describing the impending new ABI
+version, as described in the section :ref:`example_abi_macro_usage`. The
+library's soname and filename however do not change, e.g. ``libacl.so.20``, as
+ABI compatibility with the last major ABI version continues to be preserved for
+that library.
-.. note::
+.. code-block:: none
- Application
- \-> LibA.old
- \-> LibB.new -> LibA.new
+ $ head ./lib/librte_acl/rte_acl_version.map
+ DPDK_20 {
+ global:
+ ...
-That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
-If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
-library - versions defined in the libraries ``LIBABIVER``.
-An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
-``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
+ DPDK_21 {
+ global:
+
+ } DPDK_20;
+ ...
+ $ head ./lib/librte_eal/rte_eal_version.map
+ DPDK_20 {
+ global:
+ ...
+
+However when a new ABI version is declared, for example DPDK ``21``, old
+depreciated functions may be safely removed at this point and the entire old
+major ABI version removed, see the section :ref:`deprecating_entire_abi` on
+how this may be done.
+
+.. code-block:: none
+
+ $ head ./lib/librte_acl/rte_acl_version.map
+ DPDK_21 {
+ global:
+ ...
+
+ $ head ./lib/librte_eal/rte_eal_version.map
+ DPDK_21 {
+ global:
+ ...
+
+At the same time, the major ABI version is changed atomically across all
+libraries by incrementing the major version in individual library's soname, e.g.
+``libacl.so.21``. This is done by bumping the LIBABIVER number in the libraries
+Makefile to indicate to dynamic linking applications that this is a later, and
+possibly incompatible library version:
+
+.. code-block:: c
+
+ -LIBABIVER := 20
+ +LIBABIVER := 21
-ABI versioning
---------------
Versioning Macros
-~~~~~~~~~~~~~~~~~
+-----------------
When a symbol is exported from a library to provide an API, it also provides a
calling convention (ABI) that is embodied in its name, return type and
arguments. Occasionally that function may need to change to accommodate new
-functionality or behavior. When that occurs, it is desirable to allow for
+functionality or behavior. When that occurs, it is may be required to allow for
backward compatibility for a time with older binaries that are dynamically
linked to the DPDK.
@@ -61,8 +151,10 @@ The macros exported are:
fully qualified function ``p``, so that if a symbol becomes versioned, it
can still be mapped back to the public symbol name.
+.. _example_abi_macro_usage:
+
Examples of ABI Macro use
-^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~
Updating a public API
_____________________
@@ -106,16 +198,16 @@ maintain previous ABI versions that are accessible only to previously compiled
binaries
The addition of a parameter to the function is ABI breaking as the function is
-public, and existing application may use it in its current form. However, the
+public, and existing application may use it in its current form. However, the
compatibility macros in DPDK allow a developer to use symbol versioning so that
multiple functions can be mapped to the same public symbol based on when an
-application was linked to it. To see how this is done, we start with the
-requisite libraries version map file. Initially the version map file for the
-acl library looks like this
+application was linked to it. To see how this is done, we start with the
+requisite libraries version map file. Initially the version map file for the acl
+library looks like this
.. code-block:: none
- DPDK_2.0 {
+ DPDK_20 {
global:
rte_acl_add_rules;
@@ -141,7 +233,7 @@ This file needs to be modified as follows
.. code-block:: none
- DPDK_2.0 {
+ DPDK_20 {
global:
rte_acl_add_rules;
@@ -163,16 +255,16 @@ This file needs to be modified as follows
local: *;
};
- DPDK_2.1 {
+ DPDK_21 {
global:
rte_acl_create;
- } DPDK_2.0;
+ } DPDK_20;
The addition of the new block tells the linker that a new version node is
-available (DPDK_2.1), which contains the symbol rte_acl_create, and inherits the
-symbols from the DPDK_2.0 node. This list is directly translated into a list of
-exported symbols when DPDK is compiled as a shared library
+available (DPDK_21), which contains the symbol rte_acl_create, and inherits
+the symbols from the DPDK_20 node. This list is directly translated into a
+list of exported symbols when DPDK is compiled as a shared library
Next, we need to specify in the code which function map to the rte_acl_create
symbol at which versions. First, at the site of the initial symbol definition,
@@ -191,22 +283,22 @@ with the public symbol name
Note that the base name of the symbol was kept intact, as this is conducive to
the macros used for versioning symbols. That is our next step, mapping this new
-symbol name to the initial symbol name at version node 2.0. Immediately after
+symbol name to the initial symbol name at version node 20. Immediately after
the function, we add this line of code
.. code-block:: c
- VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
+ VERSION_SYMBOL(rte_acl_create, _v20, 20);
-Remembering to also add the rte_function_versioning.h header to the requisite c file where
-these changes are being made. The above macro instructs the linker to create a
-new symbol ``rte_acl_create@DPDK_2.0``, which matches the symbol created in older
-builds, but now points to the above newly named function. We have now mapped
-the original rte_acl_create symbol to the original function (but with a new
-name)
+Remembering to also add the rte_function_versioning.h header to the requisite c
+file where these changes are being made. The above macro instructs the linker to
+create a new symbol ``rte_acl_create@DPDK_20``, which matches the symbol created
+in older builds, but now points to the above newly named function. We have now
+mapped the original rte_acl_create symbol to the original function (but with a
+new name).
-Next, we need to create the 2.1 version of the symbol. We create a new function
-name, with a different suffix, and implement it appropriately
+Next, we need to create the 21 version of the symbol. We create a new function
+name, with a different suffix, and implement it appropriately
.. code-block:: c
@@ -220,12 +312,12 @@ name, with a different suffix, and implement it appropriately
return ctx;
}
-This code serves as our new API call. Its the same as our old call, but adds
-the new parameter in place. Next we need to map this function to the symbol
-``rte_acl_create@DPDK_2.1``. To do this, we modify the public prototype of the call
-in the header file, adding the macro there to inform all including applications,
-that on re-link, the default rte_acl_create symbol should point to this
-function. Note that we could do this by simply naming the function above
+This code serves as our new API call. Its the same as our old call, but adds the
+new parameter in place. Next we need to map this function to the symbol
+``rte_acl_create@DPDK_21``. To do this, we modify the public prototype of the
+call in the header file, adding the macro there to inform all including
+applications, that on re-link, the default rte_acl_create symbol should point to
+this function. Note that we could do this by simply naming the function above
rte_acl_create, and the linker would chose the most recent version tag to apply
in the version script, but we can also do this in the header file
@@ -233,11 +325,11 @@ in the version script, but we can also do this in the header file
struct rte_acl_ctx *
-rte_acl_create(const struct rte_acl_param *param);
- +rte_acl_create(const struct rte_acl_param *param, int debug);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+ +rte_acl_create_v21(const struct rte_acl_param *param, int debug);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
The BIND_DEFAULT_SYMBOL macro explicitly tells applications that include this
-header, to link to the rte_acl_create_v21 function and apply the DPDK_2.1
+header, to link to the rte_acl_create_v21 function and apply the DPDK_21
version node to it. This method is more explicit and flexible than just
re-implementing the exact symbol name, and allows for other features (such as
linking to the old symbol version by default, when the new ABI is to be opt-in
@@ -257,6 +349,7 @@ assumption is that the most recent version of the symbol is the one you want to
map. So, back in the C file where, immediately after ``rte_acl_create_v21`` is
defined, we add this
+
.. code-block:: c
struct rte_acl_ctx *
@@ -270,21 +363,22 @@ That tells the compiler that, when building a static library, any calls to the
symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
That's it, on the next shared library rebuild, there will be two versions of
-rte_acl_create, an old DPDK_2.0 version, used by previously built applications,
-and a new DPDK_2.1 version, used by future built applications.
+rte_acl_create, an old DPDK_20 version, used by previously built applications,
+and a new DPDK_21 version, used by future built applications.
Deprecating part of a public API
________________________________
-Lets assume that you've done the above update, and after a few releases have
-passed you decide you would like to retire the old version of the function.
-After having gone through the ABI deprecation announcement process, removal is
-easy. Start by removing the symbol from the requisite version map file:
+Lets assume that you've done the above update, and in preparation for the next
+major ABI version you decide you would like to retire the old version of the
+function. After having gone through the ABI deprecation announcement process,
+removal is easy. Start by removing the symbol from the requisite version map
+file:
.. code-block:: none
- DPDK_2.0 {
+ DPDK_20 {
global:
rte_acl_add_rules;
@@ -306,48 +400,42 @@ easy. Start by removing the symbol from the requisite version map file:
local: *;
};
- DPDK_2.1 {
+ DPDK_21 {
global:
rte_acl_create;
- } DPDK_2.0;
+ } DPDK_20;
Next remove the corresponding versioned export.
.. code-block:: c
- -VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
+ -VERSION_SYMBOL(rte_acl_create, _v20, 20);
Note that the internal function definition could also be removed, but its used
-in our example by the newer version _v21, so we leave it in place. This is a
-coding style choice.
-
-Lastly, we need to bump the LIBABIVER number for this library in the Makefile to
-indicate to applications doing dynamic linking that this is a later, and
-possibly incompatible library version:
-
-.. code-block:: c
+in our example by the newer version v21, so we leave it in place and declare it
+as static. This is a coding style choice.
- -LIBABIVER := 1
- +LIBABIVER := 2
+.. _deprecating_entire_abi:
Deprecating an entire ABI version
_________________________________
-While removing a symbol from and ABI may be useful, it is often more practical
-to remove an entire version node at once. If a version node completely
-specifies an API, then removing part of it, typically makes it incomplete. In
-those cases it is better to remove the entire node
+While removing a symbol from an ABI may be useful, it is more practical to
+remove an entire version node at once, as is typically done at the declaration
+of a major ABI version. If a version node completely specifies an API, then
+removing part of it, typically makes it incomplete. In those cases it is better
+to remove the entire node.
To do this, start by modifying the version map file, such that all symbols from
-the node to be removed are merged into the next node in the map
+the node to be removed are merged into the next node in the map.
In the case of our map above, it would transform to look as follows
.. code-block:: none
- DPDK_2.1 {
+ DPDK_21 {
global:
rte_acl_add_rules;
@@ -375,8 +463,8 @@ symbols.
.. code-block:: c
- -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 2.0);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+ -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 20);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
Lastly, any VERSION_SYMBOL macros that point to the old version node should be
removed, taking care to keep, where need old code in place to support newer
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index c9ec529..2140303 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -156,9 +156,9 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* For other PMDs and more info, refer to the ``MAINTAINERS`` file.
-* New external functions should be added to the local ``version.map`` file.
- See the :doc:`Guidelines for ABI policy and versioning </contributing/abi_versioning>`.
- New external functions should also be added in alphabetical order.
+* New external functions should be added to the local ``version.map`` file. See
+ the :doc:`ABI policy <abi_policy>` and :ref:`ABI versioning <abi_versioning>`
+ guides. New external functions should also be added in alphabetical order.
* Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``.
See the :ref:`Release Notes section of the Documentation Guidelines <doc_guidelines>` for details.
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index cf37d80..d454915 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -4,9 +4,9 @@
ABI and API Deprecation
=======================
-See the :doc:`guidelines document for details of the ABI policy </contributing/abi_versioning>`.
-API and ABI deprecation notices are to be posted here.
-
+See the guidelines document for details of the :doc:`ABI policy
+<../contributing/abi_policy>`. API and ABI deprecation notices are to be posted
+here.
Deprecation Notices
-------------------
--
2.7.4
^ permalink raw reply [relevance 35%]
* [dpdk-dev] [PATCH v9 1/4] doc: separate versioning.rst into version and policy
2019-11-08 12:46 10% [dpdk-dev] [PATCH v9 0/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
@ 2019-11-08 12:46 18% ` Ray Kinsella
2019-11-08 12:46 23% ` [dpdk-dev] [PATCH v9 2/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-11-08 12:46 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, john.mcnamara, marko.kovacevic, hemant.agrawal,
ktraynor, aconole
Separate versioning.rst into abi versioning and abi policy guidance, in
preparation for adding more detail to the abi policy.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: John Mcnamara <john.mcnamara@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/contributing/abi_policy.rst | 167 ++++++++
doc/guides/contributing/abi_versioning.rst | 427 +++++++++++++++++++++
doc/guides/contributing/index.rst | 3 +-
doc/guides/contributing/patches.rst | 2 +-
doc/guides/contributing/versioning.rst | 591 -----------------------------
doc/guides/rel_notes/deprecation.rst | 2 +-
6 files changed, 598 insertions(+), 594 deletions(-)
create mode 100644 doc/guides/contributing/abi_policy.rst
create mode 100644 doc/guides/contributing/abi_versioning.rst
delete mode 100644 doc/guides/contributing/versioning.rst
diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst
new file mode 100644
index 0000000..d4f4e9f
--- /dev/null
+++ b/doc/guides/contributing/abi_policy.rst
@@ -0,0 +1,167 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2018 The DPDK contributors
+
+DPDK ABI/API policy
+===================
+
+Description
+-----------
+
+This document details some methods for handling ABI management in the DPDK.
+
+General Guidelines
+------------------
+
+#. Whenever possible, ABI should be preserved
+#. ABI/API may be changed with a deprecation process
+#. The modification of symbols can generally be managed with versioning
+#. Libraries or APIs marked in ``experimental`` state may change without constraint
+#. New APIs will be marked as ``experimental`` for at least one release to allow
+ any issues found by users of the new API to be fixed quickly
+#. The addition of symbols is generally not problematic
+#. The removal of symbols generally is an ABI break and requires bumping of the
+ LIBABIVER macro
+#. Updates to the minimum hardware requirements, which drop support for hardware which
+ was previously supported, should be treated as an ABI change.
+
+What is an ABI
+~~~~~~~~~~~~~~
+
+An ABI (Application Binary Interface) is the set of runtime interfaces exposed
+by a library. It is similar to an API (Application Programming Interface) but
+is the result of compilation. It is also effectively cloned when applications
+link to dynamic libraries. That is to say when an application is compiled to
+link against dynamic libraries, it is assumed that the ABI remains constant
+between the time the application is compiled/linked, and the time that it runs.
+Therefore, in the case of dynamic linking, it is critical that an ABI is
+preserved, or (when modified), done in such a way that the application is unable
+to behave improperly or in an unexpected fashion.
+
+
+ABI/API Deprecation
+-------------------
+
+The DPDK ABI policy
+~~~~~~~~~~~~~~~~~~~
+
+ABI versions are set at the time of major release labeling, and the ABI may
+change multiple times, without warning, between the last release label and the
+HEAD label of the git tree.
+
+ABI versions, once released, are available until such time as their
+deprecation has been noted in the Release Notes for at least one major release
+cycle. For example consider the case where the ABI for DPDK 2.0 has been
+shipped and then a decision is made to modify it during the development of
+DPDK 2.1. The decision will be recorded in the Release Notes for the DPDK 2.1
+release and the modification will be made available in the DPDK 2.2 release.
+
+ABI versions may be deprecated in whole or in part as needed by a given
+update.
+
+Some ABI changes may be too significant to reasonably maintain multiple
+versions. In those cases ABI's may be updated without backward compatibility
+being provided. The requirements for doing so are:
+
+#. At least 3 acknowledgments of the need to do so must be made on the
+ dpdk.org mailing list.
+
+ - The acknowledgment of the maintainer of the component is mandatory, or if
+ no maintainer is available for the component, the tree/sub-tree maintainer
+ for that component must acknowledge the ABI change instead.
+
+ - It is also recommended that acknowledgments from different "areas of
+ interest" be sought for each deprecation, for example: from NIC vendors,
+ CPU vendors, end-users, etc.
+
+#. The changes (including an alternative map file) can be included with
+ deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option,
+ to provide more details about oncoming changes.
+ ``RTE_NEXT_ABI`` wrapper will be removed when it become the default ABI.
+ More preferred way to provide this information is sending the feature
+ as a separate patch and reference it in deprecation notice.
+
+#. A full deprecation cycle, as explained above, must be made to offer
+ downstream consumers sufficient warning of the change.
+
+Note that the above process for ABI deprecation should not be undertaken
+lightly. ABI stability is extremely important for downstream consumers of the
+DPDK, especially when distributed in shared object form. Every effort should
+be made to preserve the ABI whenever possible. The ABI should only be changed
+for significant reasons, such as performance enhancements. ABI breakage due to
+changes such as reorganizing public structure fields for aesthetic or
+readability purposes should be avoided.
+
+.. note::
+
+ Updates to the minimum hardware requirements, which drop support for hardware
+ which was previously supported, should be treated as an ABI change, and
+ follow the relevant deprecation policy procedures as above: 3 acks and
+ announcement at least one release in advance.
+
+Examples of Deprecation Notices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following are some examples of ABI deprecation notices which would be
+added to the Release Notes:
+
+* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
+ to be replaced with the inline function ``rte_foo()``.
+
+* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
+ in version 2.0. Backwards compatibility will be maintained for this function
+ until the release of version 2.1
+
+* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
+ performance reasons. Existing binary applications will have backwards
+ compatibility in release 2.0, while newly built binaries will need to
+ reference the new structure variant ``struct rte_foo2``. Compatibility will
+ be removed in release 2.2, and all applications will require updating and
+ rebuilding to the new structure at that time, which will be renamed to the
+ original ``struct rte_foo``.
+
+* Significant ABI changes are planned for the ``librte_dostuff`` library. The
+ upcoming release 2.0 will not contain these changes, but release 2.1 will,
+ and no backwards compatibility is planned due to the extensive nature of
+ these changes. Binaries using this library built prior to version 2.1 will
+ require updating and recompilation.
+
+New API replacing previous one
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If a new API proposed functionally replaces an existing one, when the new API
+becomes non-experimental then the old one is marked with ``__rte_deprecated``.
+Deprecated APIs are removed completely just after the next LTS.
+
+Reminder that old API should follow deprecation process to be removed.
+
+
+Experimental APIs
+-----------------
+
+APIs marked as ``experimental`` are not considered part of the ABI and may
+change without warning at any time. Since changes to APIs are most likely
+immediately after their introduction, as users begin to take advantage of
+those new APIs and start finding issues with them, new DPDK APIs will be
+automatically marked as ``experimental`` to allow for a period of stabilization
+before they become part of a tracked ABI.
+
+Note that marking an API as experimental is a multi step process.
+To mark an API as experimental, the symbols which are desired to be exported
+must be placed in an EXPERIMENTAL version block in the corresponding libraries'
+version map script.
+Secondly, the corresponding prototypes of those exported functions (in the
+development header files), must be marked with the ``__rte_experimental`` tag
+(see ``rte_compat.h``).
+The DPDK build makefiles perform a check to ensure that the map file and the
+C code reflect the same list of symbols.
+This check can be circumvented by defining ``ALLOW_EXPERIMENTAL_API``
+during compilation in the corresponding library Makefile.
+
+In addition to tagging the code with ``__rte_experimental``,
+the doxygen markup must also contain the EXPERIMENTAL string,
+and the MAINTAINERS file should note the EXPERIMENTAL libraries.
+
+For removing the experimental tag associated with an API, deprecation notice
+is not required. Though, an API should remain in experimental state for at least
+one release. Thereafter, normal process of posting patch for review to mailing
+list can be followed.
diff --git a/doc/guides/contributing/abi_versioning.rst b/doc/guides/contributing/abi_versioning.rst
new file mode 100644
index 0000000..1c5612c
--- /dev/null
+++ b/doc/guides/contributing/abi_versioning.rst
@@ -0,0 +1,427 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2018 The DPDK contributors
+
+.. library_versioning:
+
+Library versioning
+------------------
+
+Downstreams might want to provide different DPDK releases at the same time to
+support multiple consumers of DPDK linked against older and newer sonames.
+
+Also due to the interdependencies that DPDK libraries can have applications
+might end up with an executable space in which multiple versions of a library
+are mapped by ld.so.
+
+Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
+depending on LibA.
+
+.. note::
+
+ Application
+ \-> LibA.old
+ \-> LibB.new -> LibA.new
+
+That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
+If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
+library - versions defined in the libraries ``LIBABIVER``.
+An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
+``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
+
+
+ABI versioning
+--------------
+
+Versioning Macros
+~~~~~~~~~~~~~~~~~
+
+When a symbol is exported from a library to provide an API, it also provides a
+calling convention (ABI) that is embodied in its name, return type and
+arguments. Occasionally that function may need to change to accommodate new
+functionality or behavior. When that occurs, it is desirable to allow for
+backward compatibility for a time with older binaries that are dynamically
+linked to the DPDK.
+
+To support backward compatibility the ``rte_function_versioning.h``
+header file provides macros to use when updating exported functions. These
+macros are used in conjunction with the ``rte_<library>_version.map`` file for
+a given library to allow multiple versions of a symbol to exist in a shared
+library so that older binaries need not be immediately recompiled.
+
+The macros exported are:
+
+* ``VERSION_SYMBOL(b, e, n)``: Creates a symbol version table entry binding
+ versioned symbol ``b@DPDK_n`` to the internal function ``b_e``.
+
+* ``BIND_DEFAULT_SYMBOL(b, e, n)``: Creates a symbol version entry instructing
+ the linker to bind references to symbol ``b`` to the internal symbol
+ ``b_e``.
+
+* ``MAP_STATIC_SYMBOL(f, p)``: Declare the prototype ``f``, and map it to the
+ fully qualified function ``p``, so that if a symbol becomes versioned, it
+ can still be mapped back to the public symbol name.
+
+Examples of ABI Macro use
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Updating a public API
+_____________________
+
+Assume we have a function as follows
+
+.. code-block:: c
+
+ /*
+ * Create an acl context object for apps to
+ * manipulate
+ */
+ struct rte_acl_ctx *
+ rte_acl_create(const struct rte_acl_param *param)
+ {
+ ...
+ }
+
+
+Assume that struct rte_acl_ctx is a private structure, and that a developer
+wishes to enhance the acl api so that a debugging flag can be enabled on a
+per-context basis. This requires an addition to the structure (which, being
+private, is safe), but it also requires modifying the code as follows
+
+.. code-block:: c
+
+ /*
+ * Create an acl context object for apps to
+ * manipulate
+ */
+ struct rte_acl_ctx *
+ rte_acl_create(const struct rte_acl_param *param, int debug)
+ {
+ ...
+ }
+
+
+Note also that, being a public function, the header file prototype must also be
+changed, as must all the call sites, to reflect the new ABI footprint. We will
+maintain previous ABI versions that are accessible only to previously compiled
+binaries
+
+The addition of a parameter to the function is ABI breaking as the function is
+public, and existing application may use it in its current form. However, the
+compatibility macros in DPDK allow a developer to use symbol versioning so that
+multiple functions can be mapped to the same public symbol based on when an
+application was linked to it. To see how this is done, we start with the
+requisite libraries version map file. Initially the version map file for the
+acl library looks like this
+
+.. code-block:: none
+
+ DPDK_2.0 {
+ global:
+
+ rte_acl_add_rules;
+ rte_acl_build;
+ rte_acl_classify;
+ rte_acl_classify_alg;
+ rte_acl_classify_scalar;
+ rte_acl_create;
+ rte_acl_dump;
+ rte_acl_find_existing;
+ rte_acl_free;
+ rte_acl_ipv4vlan_add_rules;
+ rte_acl_ipv4vlan_build;
+ rte_acl_list_dump;
+ rte_acl_reset;
+ rte_acl_reset_rules;
+ rte_acl_set_ctx_classify;
+
+ local: *;
+ };
+
+This file needs to be modified as follows
+
+.. code-block:: none
+
+ DPDK_2.0 {
+ global:
+
+ rte_acl_add_rules;
+ rte_acl_build;
+ rte_acl_classify;
+ rte_acl_classify_alg;
+ rte_acl_classify_scalar;
+ rte_acl_create;
+ rte_acl_dump;
+ rte_acl_find_existing;
+ rte_acl_free;
+ rte_acl_ipv4vlan_add_rules;
+ rte_acl_ipv4vlan_build;
+ rte_acl_list_dump;
+ rte_acl_reset;
+ rte_acl_reset_rules;
+ rte_acl_set_ctx_classify;
+
+ local: *;
+ };
+
+ DPDK_2.1 {
+ global:
+ rte_acl_create;
+
+ } DPDK_2.0;
+
+The addition of the new block tells the linker that a new version node is
+available (DPDK_2.1), which contains the symbol rte_acl_create, and inherits the
+symbols from the DPDK_2.0 node. This list is directly translated into a list of
+exported symbols when DPDK is compiled as a shared library
+
+Next, we need to specify in the code which function map to the rte_acl_create
+symbol at which versions. First, at the site of the initial symbol definition,
+we need to update the function so that it is uniquely named, and not in conflict
+with the public symbol name
+
+.. code-block:: c
+
+ struct rte_acl_ctx *
+ -rte_acl_create(const struct rte_acl_param *param)
+ +rte_acl_create_v20(const struct rte_acl_param *param)
+ {
+ size_t sz;
+ struct rte_acl_ctx *ctx;
+ ...
+
+Note that the base name of the symbol was kept intact, as this is conducive to
+the macros used for versioning symbols. That is our next step, mapping this new
+symbol name to the initial symbol name at version node 2.0. Immediately after
+the function, we add this line of code
+
+.. code-block:: c
+
+ VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
+
+Remembering to also add the rte_function_versioning.h header to the requisite c file where
+these changes are being made. The above macro instructs the linker to create a
+new symbol ``rte_acl_create@DPDK_2.0``, which matches the symbol created in older
+builds, but now points to the above newly named function. We have now mapped
+the original rte_acl_create symbol to the original function (but with a new
+name)
+
+Next, we need to create the 2.1 version of the symbol. We create a new function
+name, with a different suffix, and implement it appropriately
+
+.. code-block:: c
+
+ struct rte_acl_ctx *
+ rte_acl_create_v21(const struct rte_acl_param *param, int debug);
+ {
+ struct rte_acl_ctx *ctx = rte_acl_create_v20(param);
+
+ ctx->debug = debug;
+
+ return ctx;
+ }
+
+This code serves as our new API call. Its the same as our old call, but adds
+the new parameter in place. Next we need to map this function to the symbol
+``rte_acl_create@DPDK_2.1``. To do this, we modify the public prototype of the call
+in the header file, adding the macro there to inform all including applications,
+that on re-link, the default rte_acl_create symbol should point to this
+function. Note that we could do this by simply naming the function above
+rte_acl_create, and the linker would chose the most recent version tag to apply
+in the version script, but we can also do this in the header file
+
+.. code-block:: c
+
+ struct rte_acl_ctx *
+ -rte_acl_create(const struct rte_acl_param *param);
+ +rte_acl_create(const struct rte_acl_param *param, int debug);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+
+The BIND_DEFAULT_SYMBOL macro explicitly tells applications that include this
+header, to link to the rte_acl_create_v21 function and apply the DPDK_2.1
+version node to it. This method is more explicit and flexible than just
+re-implementing the exact symbol name, and allows for other features (such as
+linking to the old symbol version by default, when the new ABI is to be opt-in
+for a period.
+
+One last thing we need to do. Note that we've taken what was a public symbol,
+and duplicated it into two uniquely and differently named symbols. We've then
+mapped each of those back to the public symbol ``rte_acl_create`` with different
+version tags. This only applies to dynamic linking, as static linking has no
+notion of versioning. That leaves this code in a position of no longer having a
+symbol simply named ``rte_acl_create`` and a static build will fail on that
+missing symbol.
+
+To correct this, we can simply map a function of our choosing back to the public
+symbol in the static build with the ``MAP_STATIC_SYMBOL`` macro. Generally the
+assumption is that the most recent version of the symbol is the one you want to
+map. So, back in the C file where, immediately after ``rte_acl_create_v21`` is
+defined, we add this
+
+.. code-block:: c
+
+ struct rte_acl_ctx *
+ rte_acl_create_v21(const struct rte_acl_param *param, int debug)
+ {
+ ...
+ }
+ MAP_STATIC_SYMBOL(struct rte_acl_ctx *rte_acl_create(const struct rte_acl_param *param, int debug), rte_acl_create_v21);
+
+That tells the compiler that, when building a static library, any calls to the
+symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
+
+That's it, on the next shared library rebuild, there will be two versions of
+rte_acl_create, an old DPDK_2.0 version, used by previously built applications,
+and a new DPDK_2.1 version, used by future built applications.
+
+
+Deprecating part of a public API
+________________________________
+
+Lets assume that you've done the above update, and after a few releases have
+passed you decide you would like to retire the old version of the function.
+After having gone through the ABI deprecation announcement process, removal is
+easy. Start by removing the symbol from the requisite version map file:
+
+.. code-block:: none
+
+ DPDK_2.0 {
+ global:
+
+ rte_acl_add_rules;
+ rte_acl_build;
+ rte_acl_classify;
+ rte_acl_classify_alg;
+ rte_acl_classify_scalar;
+ rte_acl_dump;
+ - rte_acl_create
+ rte_acl_find_existing;
+ rte_acl_free;
+ rte_acl_ipv4vlan_add_rules;
+ rte_acl_ipv4vlan_build;
+ rte_acl_list_dump;
+ rte_acl_reset;
+ rte_acl_reset_rules;
+ rte_acl_set_ctx_classify;
+
+ local: *;
+ };
+
+ DPDK_2.1 {
+ global:
+ rte_acl_create;
+ } DPDK_2.0;
+
+
+Next remove the corresponding versioned export.
+
+.. code-block:: c
+
+ -VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
+
+
+Note that the internal function definition could also be removed, but its used
+in our example by the newer version _v21, so we leave it in place. This is a
+coding style choice.
+
+Lastly, we need to bump the LIBABIVER number for this library in the Makefile to
+indicate to applications doing dynamic linking that this is a later, and
+possibly incompatible library version:
+
+.. code-block:: c
+
+ -LIBABIVER := 1
+ +LIBABIVER := 2
+
+Deprecating an entire ABI version
+_________________________________
+
+While removing a symbol from and ABI may be useful, it is often more practical
+to remove an entire version node at once. If a version node completely
+specifies an API, then removing part of it, typically makes it incomplete. In
+those cases it is better to remove the entire node
+
+To do this, start by modifying the version map file, such that all symbols from
+the node to be removed are merged into the next node in the map
+
+In the case of our map above, it would transform to look as follows
+
+.. code-block:: none
+
+ DPDK_2.1 {
+ global:
+
+ rte_acl_add_rules;
+ rte_acl_build;
+ rte_acl_classify;
+ rte_acl_classify_alg;
+ rte_acl_classify_scalar;
+ rte_acl_dump;
+ rte_acl_create
+ rte_acl_find_existing;
+ rte_acl_free;
+ rte_acl_ipv4vlan_add_rules;
+ rte_acl_ipv4vlan_build;
+ rte_acl_list_dump;
+ rte_acl_reset;
+ rte_acl_reset_rules;
+ rte_acl_set_ctx_classify;
+
+ local: *;
+ };
+
+Then any uses of BIND_DEFAULT_SYMBOL that pointed to the old node should be
+updated to point to the new version node in any header files for all affected
+symbols.
+
+.. code-block:: c
+
+ -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 2.0);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+
+Lastly, any VERSION_SYMBOL macros that point to the old version node should be
+removed, taking care to keep, where need old code in place to support newer
+versions of the symbol.
+
+
+Running the ABI Validator
+-------------------------
+
+The ``devtools`` directory in the DPDK source tree contains a utility program,
+``validate-abi.sh``, for validating the DPDK ABI based on the Linux `ABI
+Compliance Checker
+<http://ispras.linuxbase.org/index.php/ABI_compliance_checker>`_.
+
+This has a dependency on the ``abi-compliance-checker`` and ``and abi-dumper``
+utilities which can be installed via a package manager. For example::
+
+ sudo yum install abi-compliance-checker
+ sudo yum install abi-dumper
+
+The syntax of the ``validate-abi.sh`` utility is::
+
+ ./devtools/validate-abi.sh <REV1> <REV2>
+
+Where ``REV1`` and ``REV2`` are valid gitrevisions(7)
+https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
+on the local repo.
+
+For example::
+
+ # Check between the previous and latest commit:
+ ./devtools/validate-abi.sh HEAD~1 HEAD
+
+ # Check on a specific compilation target:
+ ./devtools/validate-abi.sh -t x86_64-native-linux-gcc HEAD~1 HEAD
+
+ # Check between two tags:
+ ./devtools/validate-abi.sh v2.0.0 v2.1.0
+
+ # Check between git master and local topic-branch "vhost-hacking":
+ ./devtools/validate-abi.sh master vhost-hacking
+
+After the validation script completes (it can take a while since it need to
+compile both tags) it will create compatibility reports in the
+``./abi-check/compat_report`` directory. Listed incompatibilities can be found
+as follows::
+
+ grep -lr Incompatible abi-check/compat_reports/
diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
index e2608d3..2fefd91 100644
--- a/doc/guides/contributing/index.rst
+++ b/doc/guides/contributing/index.rst
@@ -10,7 +10,8 @@ Contributor's Guidelines
coding_style
design
- versioning
+ abi_policy
+ abi_versioning
documentation
patches
vulnerability
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 9e1013b..c9ec529 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -157,7 +157,7 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* For other PMDs and more info, refer to the ``MAINTAINERS`` file.
* New external functions should be added to the local ``version.map`` file.
- See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
+ See the :doc:`Guidelines for ABI policy and versioning </contributing/abi_versioning>`.
New external functions should also be added in alphabetical order.
* Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``.
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
deleted file mode 100644
index 64984c5..0000000
--- a/doc/guides/contributing/versioning.rst
+++ /dev/null
@@ -1,591 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
- Copyright 2018 The DPDK contributors
-
-DPDK ABI/API policy
-===================
-
-Description
------------
-
-This document details some methods for handling ABI management in the DPDK.
-
-General Guidelines
-------------------
-
-#. Whenever possible, ABI should be preserved
-#. ABI/API may be changed with a deprecation process
-#. The modification of symbols can generally be managed with versioning
-#. Libraries or APIs marked in ``experimental`` state may change without constraint
-#. New APIs will be marked as ``experimental`` for at least one release to allow
- any issues found by users of the new API to be fixed quickly
-#. The addition of symbols is generally not problematic
-#. The removal of symbols generally is an ABI break and requires bumping of the
- LIBABIVER macro
-#. Updates to the minimum hardware requirements, which drop support for hardware which
- was previously supported, should be treated as an ABI change.
-
-What is an ABI
-~~~~~~~~~~~~~~
-
-An ABI (Application Binary Interface) is the set of runtime interfaces exposed
-by a library. It is similar to an API (Application Programming Interface) but
-is the result of compilation. It is also effectively cloned when applications
-link to dynamic libraries. That is to say when an application is compiled to
-link against dynamic libraries, it is assumed that the ABI remains constant
-between the time the application is compiled/linked, and the time that it runs.
-Therefore, in the case of dynamic linking, it is critical that an ABI is
-preserved, or (when modified), done in such a way that the application is unable
-to behave improperly or in an unexpected fashion.
-
-
-ABI/API Deprecation
--------------------
-
-The DPDK ABI policy
-~~~~~~~~~~~~~~~~~~~
-
-ABI versions are set at the time of major release labeling, and the ABI may
-change multiple times, without warning, between the last release label and the
-HEAD label of the git tree.
-
-ABI versions, once released, are available until such time as their
-deprecation has been noted in the Release Notes for at least one major release
-cycle. For example consider the case where the ABI for DPDK 2.0 has been
-shipped and then a decision is made to modify it during the development of
-DPDK 2.1. The decision will be recorded in the Release Notes for the DPDK 2.1
-release and the modification will be made available in the DPDK 2.2 release.
-
-ABI versions may be deprecated in whole or in part as needed by a given
-update.
-
-Some ABI changes may be too significant to reasonably maintain multiple
-versions. In those cases ABI's may be updated without backward compatibility
-being provided. The requirements for doing so are:
-
-#. At least 3 acknowledgments of the need to do so must be made on the
- dpdk.org mailing list.
-
- - The acknowledgment of the maintainer of the component is mandatory, or if
- no maintainer is available for the component, the tree/sub-tree maintainer
- for that component must acknowledge the ABI change instead.
-
- - It is also recommended that acknowledgments from different "areas of
- interest" be sought for each deprecation, for example: from NIC vendors,
- CPU vendors, end-users, etc.
-
-#. The changes (including an alternative map file) can be included with
- deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option,
- to provide more details about oncoming changes.
- ``RTE_NEXT_ABI`` wrapper will be removed when it become the default ABI.
- More preferred way to provide this information is sending the feature
- as a separate patch and reference it in deprecation notice.
-
-#. A full deprecation cycle, as explained above, must be made to offer
- downstream consumers sufficient warning of the change.
-
-Note that the above process for ABI deprecation should not be undertaken
-lightly. ABI stability is extremely important for downstream consumers of the
-DPDK, especially when distributed in shared object form. Every effort should
-be made to preserve the ABI whenever possible. The ABI should only be changed
-for significant reasons, such as performance enhancements. ABI breakage due to
-changes such as reorganizing public structure fields for aesthetic or
-readability purposes should be avoided.
-
-.. note::
-
- Updates to the minimum hardware requirements, which drop support for hardware
- which was previously supported, should be treated as an ABI change, and
- follow the relevant deprecation policy procedures as above: 3 acks and
- announcement at least one release in advance.
-
-Examples of Deprecation Notices
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The following are some examples of ABI deprecation notices which would be
-added to the Release Notes:
-
-* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
- to be replaced with the inline function ``rte_foo()``.
-
-* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
- in version 2.0. Backwards compatibility will be maintained for this function
- until the release of version 2.1
-
-* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
- performance reasons. Existing binary applications will have backwards
- compatibility in release 2.0, while newly built binaries will need to
- reference the new structure variant ``struct rte_foo2``. Compatibility will
- be removed in release 2.2, and all applications will require updating and
- rebuilding to the new structure at that time, which will be renamed to the
- original ``struct rte_foo``.
-
-* Significant ABI changes are planned for the ``librte_dostuff`` library. The
- upcoming release 2.0 will not contain these changes, but release 2.1 will,
- and no backwards compatibility is planned due to the extensive nature of
- these changes. Binaries using this library built prior to version 2.1 will
- require updating and recompilation.
-
-New API replacing previous one
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If a new API proposed functionally replaces an existing one, when the new API
-becomes non-experimental then the old one is marked with ``__rte_deprecated``.
-Deprecated APIs are removed completely just after the next LTS.
-
-Reminder that old API should follow deprecation process to be removed.
-
-
-Experimental APIs
------------------
-
-APIs marked as ``experimental`` are not considered part of the ABI and may
-change without warning at any time. Since changes to APIs are most likely
-immediately after their introduction, as users begin to take advantage of
-those new APIs and start finding issues with them, new DPDK APIs will be
-automatically marked as ``experimental`` to allow for a period of stabilization
-before they become part of a tracked ABI.
-
-Note that marking an API as experimental is a multi step process.
-To mark an API as experimental, the symbols which are desired to be exported
-must be placed in an EXPERIMENTAL version block in the corresponding libraries'
-version map script.
-Secondly, the corresponding prototypes of those exported functions (in the
-development header files), must be marked with the ``__rte_experimental`` tag
-(see ``rte_compat.h``).
-The DPDK build makefiles perform a check to ensure that the map file and the
-C code reflect the same list of symbols.
-This check can be circumvented by defining ``ALLOW_EXPERIMENTAL_API``
-during compilation in the corresponding library Makefile.
-
-In addition to tagging the code with ``__rte_experimental``,
-the doxygen markup must also contain the EXPERIMENTAL string,
-and the MAINTAINERS file should note the EXPERIMENTAL libraries.
-
-For removing the experimental tag associated with an API, deprecation notice
-is not required. Though, an API should remain in experimental state for at least
-one release. Thereafter, normal process of posting patch for review to mailing
-list can be followed.
-
-
-Library versioning
-------------------
-
-Downstreams might want to provide different DPDK releases at the same time to
-support multiple consumers of DPDK linked against older and newer sonames.
-
-Also due to the interdependencies that DPDK libraries can have applications
-might end up with an executable space in which multiple versions of a library
-are mapped by ld.so.
-
-Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
-depending on LibA.
-
-.. note::
-
- Application
- \-> LibA.old
- \-> LibB.new -> LibA.new
-
-That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
-If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
-library - versions defined in the libraries ``LIBABIVER``.
-An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
-``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
-
-
-ABI versioning
---------------
-
-Versioning Macros
-~~~~~~~~~~~~~~~~~
-
-When a symbol is exported from a library to provide an API, it also provides a
-calling convention (ABI) that is embodied in its name, return type and
-arguments. Occasionally that function may need to change to accommodate new
-functionality or behavior. When that occurs, it is desirable to allow for
-backward compatibility for a time with older binaries that are dynamically
-linked to the DPDK.
-
-To support backward compatibility the ``rte_function_versioning.h``
-header file provides macros to use when updating exported functions. These
-macros are used in conjunction with the ``rte_<library>_version.map`` file for
-a given library to allow multiple versions of a symbol to exist in a shared
-library so that older binaries need not be immediately recompiled.
-
-The macros exported are:
-
-* ``VERSION_SYMBOL(b, e, n)``: Creates a symbol version table entry binding
- versioned symbol ``b@DPDK_n`` to the internal function ``b_e``.
-
-* ``BIND_DEFAULT_SYMBOL(b, e, n)``: Creates a symbol version entry instructing
- the linker to bind references to symbol ``b`` to the internal symbol
- ``b_e``.
-
-* ``MAP_STATIC_SYMBOL(f, p)``: Declare the prototype ``f``, and map it to the
- fully qualified function ``p``, so that if a symbol becomes versioned, it
- can still be mapped back to the public symbol name.
-
-Examples of ABI Macro use
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Updating a public API
-_____________________
-
-Assume we have a function as follows
-
-.. code-block:: c
-
- /*
- * Create an acl context object for apps to
- * manipulate
- */
- struct rte_acl_ctx *
- rte_acl_create(const struct rte_acl_param *param)
- {
- ...
- }
-
-
-Assume that struct rte_acl_ctx is a private structure, and that a developer
-wishes to enhance the acl api so that a debugging flag can be enabled on a
-per-context basis. This requires an addition to the structure (which, being
-private, is safe), but it also requires modifying the code as follows
-
-.. code-block:: c
-
- /*
- * Create an acl context object for apps to
- * manipulate
- */
- struct rte_acl_ctx *
- rte_acl_create(const struct rte_acl_param *param, int debug)
- {
- ...
- }
-
-
-Note also that, being a public function, the header file prototype must also be
-changed, as must all the call sites, to reflect the new ABI footprint. We will
-maintain previous ABI versions that are accessible only to previously compiled
-binaries
-
-The addition of a parameter to the function is ABI breaking as the function is
-public, and existing application may use it in its current form. However, the
-compatibility macros in DPDK allow a developer to use symbol versioning so that
-multiple functions can be mapped to the same public symbol based on when an
-application was linked to it. To see how this is done, we start with the
-requisite libraries version map file. Initially the version map file for the
-acl library looks like this
-
-.. code-block:: none
-
- DPDK_2.0 {
- global:
-
- rte_acl_add_rules;
- rte_acl_build;
- rte_acl_classify;
- rte_acl_classify_alg;
- rte_acl_classify_scalar;
- rte_acl_create;
- rte_acl_dump;
- rte_acl_find_existing;
- rte_acl_free;
- rte_acl_ipv4vlan_add_rules;
- rte_acl_ipv4vlan_build;
- rte_acl_list_dump;
- rte_acl_reset;
- rte_acl_reset_rules;
- rte_acl_set_ctx_classify;
-
- local: *;
- };
-
-This file needs to be modified as follows
-
-.. code-block:: none
-
- DPDK_2.0 {
- global:
-
- rte_acl_add_rules;
- rte_acl_build;
- rte_acl_classify;
- rte_acl_classify_alg;
- rte_acl_classify_scalar;
- rte_acl_create;
- rte_acl_dump;
- rte_acl_find_existing;
- rte_acl_free;
- rte_acl_ipv4vlan_add_rules;
- rte_acl_ipv4vlan_build;
- rte_acl_list_dump;
- rte_acl_reset;
- rte_acl_reset_rules;
- rte_acl_set_ctx_classify;
-
- local: *;
- };
-
- DPDK_2.1 {
- global:
- rte_acl_create;
-
- } DPDK_2.0;
-
-The addition of the new block tells the linker that a new version node is
-available (DPDK_2.1), which contains the symbol rte_acl_create, and inherits the
-symbols from the DPDK_2.0 node. This list is directly translated into a list of
-exported symbols when DPDK is compiled as a shared library
-
-Next, we need to specify in the code which function map to the rte_acl_create
-symbol at which versions. First, at the site of the initial symbol definition,
-we need to update the function so that it is uniquely named, and not in conflict
-with the public symbol name
-
-.. code-block:: c
-
- struct rte_acl_ctx *
- -rte_acl_create(const struct rte_acl_param *param)
- +rte_acl_create_v20(const struct rte_acl_param *param)
- {
- size_t sz;
- struct rte_acl_ctx *ctx;
- ...
-
-Note that the base name of the symbol was kept intact, as this is conducive to
-the macros used for versioning symbols. That is our next step, mapping this new
-symbol name to the initial symbol name at version node 2.0. Immediately after
-the function, we add this line of code
-
-.. code-block:: c
-
- VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
-
-Remembering to also add the rte_function_versioning.h header to the requisite c file where
-these changes are being made. The above macro instructs the linker to create a
-new symbol ``rte_acl_create@DPDK_2.0``, which matches the symbol created in older
-builds, but now points to the above newly named function. We have now mapped
-the original rte_acl_create symbol to the original function (but with a new
-name)
-
-Next, we need to create the 2.1 version of the symbol. We create a new function
-name, with a different suffix, and implement it appropriately
-
-.. code-block:: c
-
- struct rte_acl_ctx *
- rte_acl_create_v21(const struct rte_acl_param *param, int debug);
- {
- struct rte_acl_ctx *ctx = rte_acl_create_v20(param);
-
- ctx->debug = debug;
-
- return ctx;
- }
-
-This code serves as our new API call. Its the same as our old call, but adds
-the new parameter in place. Next we need to map this function to the symbol
-``rte_acl_create@DPDK_2.1``. To do this, we modify the public prototype of the call
-in the header file, adding the macro there to inform all including applications,
-that on re-link, the default rte_acl_create symbol should point to this
-function. Note that we could do this by simply naming the function above
-rte_acl_create, and the linker would chose the most recent version tag to apply
-in the version script, but we can also do this in the header file
-
-.. code-block:: c
-
- struct rte_acl_ctx *
- -rte_acl_create(const struct rte_acl_param *param);
- +rte_acl_create(const struct rte_acl_param *param, int debug);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
-
-The BIND_DEFAULT_SYMBOL macro explicitly tells applications that include this
-header, to link to the rte_acl_create_v21 function and apply the DPDK_2.1
-version node to it. This method is more explicit and flexible than just
-re-implementing the exact symbol name, and allows for other features (such as
-linking to the old symbol version by default, when the new ABI is to be opt-in
-for a period.
-
-One last thing we need to do. Note that we've taken what was a public symbol,
-and duplicated it into two uniquely and differently named symbols. We've then
-mapped each of those back to the public symbol ``rte_acl_create`` with different
-version tags. This only applies to dynamic linking, as static linking has no
-notion of versioning. That leaves this code in a position of no longer having a
-symbol simply named ``rte_acl_create`` and a static build will fail on that
-missing symbol.
-
-To correct this, we can simply map a function of our choosing back to the public
-symbol in the static build with the ``MAP_STATIC_SYMBOL`` macro. Generally the
-assumption is that the most recent version of the symbol is the one you want to
-map. So, back in the C file where, immediately after ``rte_acl_create_v21`` is
-defined, we add this
-
-.. code-block:: c
-
- struct rte_acl_ctx *
- rte_acl_create_v21(const struct rte_acl_param *param, int debug)
- {
- ...
- }
- MAP_STATIC_SYMBOL(struct rte_acl_ctx *rte_acl_create(const struct rte_acl_param *param, int debug), rte_acl_create_v21);
-
-That tells the compiler that, when building a static library, any calls to the
-symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
-
-That's it, on the next shared library rebuild, there will be two versions of
-rte_acl_create, an old DPDK_2.0 version, used by previously built applications,
-and a new DPDK_2.1 version, used by future built applications.
-
-
-Deprecating part of a public API
-________________________________
-
-Lets assume that you've done the above update, and after a few releases have
-passed you decide you would like to retire the old version of the function.
-After having gone through the ABI deprecation announcement process, removal is
-easy. Start by removing the symbol from the requisite version map file:
-
-.. code-block:: none
-
- DPDK_2.0 {
- global:
-
- rte_acl_add_rules;
- rte_acl_build;
- rte_acl_classify;
- rte_acl_classify_alg;
- rte_acl_classify_scalar;
- rte_acl_dump;
- - rte_acl_create
- rte_acl_find_existing;
- rte_acl_free;
- rte_acl_ipv4vlan_add_rules;
- rte_acl_ipv4vlan_build;
- rte_acl_list_dump;
- rte_acl_reset;
- rte_acl_reset_rules;
- rte_acl_set_ctx_classify;
-
- local: *;
- };
-
- DPDK_2.1 {
- global:
- rte_acl_create;
- } DPDK_2.0;
-
-
-Next remove the corresponding versioned export.
-
-.. code-block:: c
-
- -VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
-
-
-Note that the internal function definition could also be removed, but its used
-in our example by the newer version _v21, so we leave it in place. This is a
-coding style choice.
-
-Lastly, we need to bump the LIBABIVER number for this library in the Makefile to
-indicate to applications doing dynamic linking that this is a later, and
-possibly incompatible library version:
-
-.. code-block:: c
-
- -LIBABIVER := 1
- +LIBABIVER := 2
-
-Deprecating an entire ABI version
-_________________________________
-
-While removing a symbol from and ABI may be useful, it is often more practical
-to remove an entire version node at once. If a version node completely
-specifies an API, then removing part of it, typically makes it incomplete. In
-those cases it is better to remove the entire node
-
-To do this, start by modifying the version map file, such that all symbols from
-the node to be removed are merged into the next node in the map
-
-In the case of our map above, it would transform to look as follows
-
-.. code-block:: none
-
- DPDK_2.1 {
- global:
-
- rte_acl_add_rules;
- rte_acl_build;
- rte_acl_classify;
- rte_acl_classify_alg;
- rte_acl_classify_scalar;
- rte_acl_dump;
- rte_acl_create
- rte_acl_find_existing;
- rte_acl_free;
- rte_acl_ipv4vlan_add_rules;
- rte_acl_ipv4vlan_build;
- rte_acl_list_dump;
- rte_acl_reset;
- rte_acl_reset_rules;
- rte_acl_set_ctx_classify;
-
- local: *;
- };
-
-Then any uses of BIND_DEFAULT_SYMBOL that pointed to the old node should be
-updated to point to the new version node in any header files for all affected
-symbols.
-
-.. code-block:: c
-
- -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 2.0);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
-
-Lastly, any VERSION_SYMBOL macros that point to the old version node should be
-removed, taking care to keep, where need old code in place to support newer
-versions of the symbol.
-
-
-Running the ABI Validator
--------------------------
-
-The ``devtools`` directory in the DPDK source tree contains a utility program,
-``validate-abi.sh``, for validating the DPDK ABI based on the Linux `ABI
-Compliance Checker
-<http://ispras.linuxbase.org/index.php/ABI_compliance_checker>`_.
-
-This has a dependency on the ``abi-compliance-checker`` and ``and abi-dumper``
-utilities which can be installed via a package manager. For example::
-
- sudo yum install abi-compliance-checker
- sudo yum install abi-dumper
-
-The syntax of the ``validate-abi.sh`` utility is::
-
- ./devtools/validate-abi.sh <REV1> <REV2>
-
-Where ``REV1`` and ``REV2`` are valid gitrevisions(7)
-https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
-on the local repo.
-
-For example::
-
- # Check between the previous and latest commit:
- ./devtools/validate-abi.sh HEAD~1 HEAD
-
- # Check on a specific compilation target:
- ./devtools/validate-abi.sh -t x86_64-native-linux-gcc HEAD~1 HEAD
-
- # Check between two tags:
- ./devtools/validate-abi.sh v2.0.0 v2.1.0
-
- # Check between git master and local topic-branch "vhost-hacking":
- ./devtools/validate-abi.sh master vhost-hacking
-
-After the validation script completes (it can take a while since it need to
-compile both tags) it will create compatibility reports in the
-``./abi-check/compat_report`` directory. Listed incompatibilities can be found
-as follows::
-
- grep -lr Incompatible abi-check/compat_reports/
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 4249aab..cf37d80 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -4,7 +4,7 @@
ABI and API Deprecation
=======================
-See the :doc:`guidelines document for details of the ABI policy </contributing/versioning>`.
+See the :doc:`guidelines document for details of the ABI policy </contributing/abi_versioning>`.
API and ABI deprecation notices are to be posted here.
--
2.7.4
^ permalink raw reply [relevance 18%]
* [dpdk-dev] [PATCH v9 2/4] doc: changes to abi policy introducing major abi versions
2019-11-08 12:46 10% [dpdk-dev] [PATCH v9 0/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-11-08 12:46 18% ` [dpdk-dev] [PATCH v9 1/4] doc: separate versioning.rst into version and policy Ray Kinsella
@ 2019-11-08 12:46 23% ` Ray Kinsella
2019-11-08 17:11 5% ` Thomas Monjalon
2019-11-08 12:46 35% ` [dpdk-dev] [PATCH v9 3/4] doc: updates to versioning guide for " Ray Kinsella
2019-11-08 12:46 13% ` [dpdk-dev] [PATCH v9 4/4] doc: add maintainer for abi policy Ray Kinsella
3 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-11-08 12:46 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, john.mcnamara, marko.kovacevic, hemant.agrawal,
ktraynor, aconole
This policy change introduces major ABI versions, these are
declared every year, typically aligned with the LTS release
and are supported by subsequent releases in the following year.
This change is intended to improve ABI stabilty for those projects
consuming DPDK.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: John Mcnamara <john.mcnamara@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/contributing/abi_policy.rst | 324 ++++--
.../contributing/img/abi_stability_policy.svg | 1059 ++++++++++++++++++++
doc/guides/contributing/img/what_is_an_abi.svg | 382 +++++++
doc/guides/contributing/stable.rst | 12 +-
4 files changed, 1686 insertions(+), 91 deletions(-)
create mode 100644 doc/guides/contributing/img/abi_stability_policy.svg
create mode 100644 doc/guides/contributing/img/what_is_an_abi.svg
diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst
index d4f4e9f..0965bcc 100644
--- a/doc/guides/contributing/abi_policy.rst
+++ b/doc/guides/contributing/abi_policy.rst
@@ -1,31 +1,47 @@
.. SPDX-License-Identifier: BSD-3-Clause
- Copyright 2018 The DPDK contributors
+ Copyright 2019 The DPDK contributors
-DPDK ABI/API policy
-===================
+ABI Policy
+==========
Description
-----------
-This document details some methods for handling ABI management in the DPDK.
+This document details the management policy that ensures the long-term stability
+of the DPDK ABI and API.
General Guidelines
------------------
-#. Whenever possible, ABI should be preserved
-#. ABI/API may be changed with a deprecation process
-#. The modification of symbols can generally be managed with versioning
-#. Libraries or APIs marked in ``experimental`` state may change without constraint
-#. New APIs will be marked as ``experimental`` for at least one release to allow
- any issues found by users of the new API to be fixed quickly
-#. The addition of symbols is generally not problematic
-#. The removal of symbols generally is an ABI break and requires bumping of the
- LIBABIVER macro
-#. Updates to the minimum hardware requirements, which drop support for hardware which
- was previously supported, should be treated as an ABI change.
-
-What is an ABI
-~~~~~~~~~~~~~~
+#. Major ABI versions are declared no more frequently than yearly. Compatibility
+ with the major ABI version is mandatory in subsequent releases until a new
+ major ABI version is declared.
+#. Major ABI version are usually but not always declared aligned with a
+ :ref:`LTS release <stable_lts_releases>`.
+#. The ABI version is managed at a project level in DPDK, with the ABI version
+ reflected in all library's soname.
+#. The ABI should be preserved and not changed lightly. ABI changes must follow
+ the outlined :ref:`deprecation process <abi_changes>`.
+#. The addition of symbols is generally not problematic. The modification of
+ symbols is managed with ABI Versioning.
+#. The removal of symbols is considered an :ref:`ABI breakage <abi_breakages>`,
+ once approved these will form part of the next ABI version.
+#. Libraries or APIs marked as :ref:`Experimental <experimental_apis>` are not
+ considered part of an ABI version and may change without constraint.
+#. Updates to the :ref:`minimum hardware requirements <hw_rqmts>`, which drop
+ support for hardware which was previously supported, should be treated as an
+ ABI change.
+
+.. note::
+
+ In 2019, the DPDK community stated its intention to move to ABI stable
+ releases, over a number of release cycles. This change begins with
+ maintaining ABI stability through one year of DPDK releases starting from
+ DPDK 19.11. This policy will be reviewed in 2020, with intention of
+ lengthening the stability period.
+
+What is an ABI?
+~~~~~~~~~~~~~~~
An ABI (Application Binary Interface) is the set of runtime interfaces exposed
by a library. It is similar to an API (Application Programming Interface) but
@@ -37,30 +53,82 @@ Therefore, in the case of dynamic linking, it is critical that an ABI is
preserved, or (when modified), done in such a way that the application is unable
to behave improperly or in an unexpected fashion.
+.. _figure_what_is_an_abi:
+
+.. figure:: img/what_is_an_abi.*
+
+ Illustration of DPDK API and ABI.
-ABI/API Deprecation
--------------------
+
+What is an ABI version?
+~~~~~~~~~~~~~~~~~~~~~~~
+
+An ABI version is an instance of a library's ABI at a specific release. Certain
+releases are considered to be milestone releases, the yearly LTS release for
+example. The ABI of a milestone release may be declared as a 'major ABI
+version', where this ABI version is then supported for some number of subsequent
+releases and is annotated in the library's soname.
+
+ABI version support in subsequent releases facilitates application upgrades, by
+enabling applications built against the milestone release to upgrade to
+subsequent releases of a library without a rebuild.
+
+More details on major ABI version can be found in the ABI Versioning guide.
The DPDK ABI policy
-~~~~~~~~~~~~~~~~~~~
+-------------------
+
+A new major ABI version is declared no more frequently than yearly, with
+declarations usually aligning with a LTS release, e.g. ABI 20 for DPDK 19.11.
+Compatibility with the major ABI version is then mandatory in subsequent
+releases until the next major ABI version is declared, e.g. ABI 21 for DPDK
+20.11.
-ABI versions are set at the time of major release labeling, and the ABI may
-change multiple times, without warning, between the last release label and the
-HEAD label of the git tree.
+At the declaration of a major ABI version, major version numbers encoded in
+libraries' sonames are bumped to indicate the new version, with the minor
+version reset to ``0``. An example would be ``librte_eal.so.20.3`` would become
+``librte_eal.so.21.0``.
-ABI versions, once released, are available until such time as their
-deprecation has been noted in the Release Notes for at least one major release
-cycle. For example consider the case where the ABI for DPDK 2.0 has been
-shipped and then a decision is made to modify it during the development of
-DPDK 2.1. The decision will be recorded in the Release Notes for the DPDK 2.1
-release and the modification will be made available in the DPDK 2.2 release.
+The ABI may then change multiple times, without warning, between the last major
+ABI version increment and the HEAD label of the git tree, with the condition
+that ABI compatibility with the major ABI version is preserved and therefore
+sonames do not change.
-ABI versions may be deprecated in whole or in part as needed by a given
-update.
+Minor versions are incremented to indicate the release of a new ABI compatible
+DPDK release, typically the DPDK quarterly releases. An example of this, might
+be that ``librte_eal.so.20.1`` would indicate the first ABI compatible DPDK
+release, following the declaration of the new major ABI version ``20``.
-Some ABI changes may be too significant to reasonably maintain multiple
-versions. In those cases ABI's may be updated without backward compatibility
-being provided. The requirements for doing so are:
+An ABI version is supported in all new releases until the next major ABI version
+is declared. When changing the major ABI version, the release notes will detail
+all ABI changes.
+
+.. _figure_abi_stability_policy:
+
+.. figure:: img/abi_stability_policy.*
+
+ Mapping of new ABI versions and ABI version compatibility to DPDK
+ releases.
+
+.. _abi_changes:
+
+ABI Changes
+~~~~~~~~~~~
+
+The ABI may still change after the declaration of a major ABI version, that is
+new APIs may be still added or existing APIs may be modified.
+
+.. Warning::
+
+ Note that, this policy details the method by which the ABI may be changed,
+ with due regard to preserving compatibility and observing deprecation
+ notices. This process however should not be undertaken lightly, as a general
+ rule ABI stability is extremely important for downstream consumers of DPDK.
+ The API should only be changed for significant reasons, such as performance
+ enhancements. API breakages due to changes such as reorganizing public
+ structure fields for aesthetic or readability purposes should be avoided.
+
+The requirements for changing the ABI are:
#. At least 3 acknowledgments of the need to do so must be made on the
dpdk.org mailing list.
@@ -69,34 +137,119 @@ being provided. The requirements for doing so are:
no maintainer is available for the component, the tree/sub-tree maintainer
for that component must acknowledge the ABI change instead.
+ - The acknowledgment of three members of the technical board, as delegates
+ of the `technical board <https://core.dpdk.org/techboard/>`_ acknowledging
+ the need for the ABI change, is also mandatory.
+
- It is also recommended that acknowledgments from different "areas of
interest" be sought for each deprecation, for example: from NIC vendors,
CPU vendors, end-users, etc.
-#. The changes (including an alternative map file) can be included with
- deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option,
- to provide more details about oncoming changes.
- ``RTE_NEXT_ABI`` wrapper will be removed when it become the default ABI.
- More preferred way to provide this information is sending the feature
- as a separate patch and reference it in deprecation notice.
+#. Backward compatibility with the major ABI version must be maintained through
+ ABI Versioning, with :ref:`forward-only <forward-only>` compatibility
+ offered for any ABI changes that are indicated to be part of the next ABI
+ version.
-#. A full deprecation cycle, as explained above, must be made to offer
- downstream consumers sufficient warning of the change.
+ - In situations where backward compatibility is not possible, read the
+ section on :ref:`abi_breakages`.
-Note that the above process for ABI deprecation should not be undertaken
-lightly. ABI stability is extremely important for downstream consumers of the
-DPDK, especially when distributed in shared object form. Every effort should
-be made to preserve the ABI whenever possible. The ABI should only be changed
-for significant reasons, such as performance enhancements. ABI breakage due to
-changes such as reorganizing public structure fields for aesthetic or
-readability purposes should be avoided.
+ - No backward or forward compatibility is offered for API changes marked as
+ ``experimental``, as described in the section on :ref:`Experimental APIs
+ and Libraries <experimental_apis>`.
-.. note::
+#. If a newly proposed API functionally replaces an existing one, when the new
+ API becomes non-experimental, then the old one is marked with
+ ``__rte_deprecated``.
+
+ - The depreciated API should follow the notification process to be removed,
+ see :ref:`deprecation_notices`.
+
+ - At the declaration of the next major ABI version, those ABI changes then
+ become a formal part of the new ABI and the requirement to preserve ABI
+ compatibility with the last major ABI version is then dropped.
+
+ - The responsibility for removing redundant ABI compatibility code rests
+ with the original contributor of the ABI changes, failing that, then with
+ the contributor's company and then finally with the maintainer.
+
+.. _forward-only:
+
+.. Note::
+
+ Note that forward-only compatibility is offered for those changes made
+ between major ABI versions. As a library's soname can only describe
+ compatibility with the last major ABI version, until the next major ABI
+ version is declared, these changes therefore cannot be resolved as a runtime
+ dependency through the soname. Therefore any application wishing to make use
+ of these ABI changes can only ensure that its runtime dependencies are met
+ through Operating System package versioning.
+
+.. _hw_rqmts:
+
+.. Note::
Updates to the minimum hardware requirements, which drop support for hardware
which was previously supported, should be treated as an ABI change, and
- follow the relevant deprecation policy procedures as above: 3 acks and
- announcement at least one release in advance.
+ follow the relevant deprecation policy procedures as above: 3 acks, technical
+ board approval and announcement at least one release in advance.
+
+.. _abi_breakages:
+
+ABI Breakages
+~~~~~~~~~~~~~
+
+For those ABI changes that are too significant to reasonably maintain multiple
+symbol versions, there is an amended process. In these cases, ABIs may be
+updated without the requirement of backward compatibility being provided. These
+changes must follow the same process :ref:`described above <abi_changes>` as non-breaking
+changes, however with the following additional requirements:
+
+#. ABI breaking changes (including an alternative map file) can be included with
+ deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option, to provide
+ more details about oncoming changes. ``RTE_NEXT_ABI`` wrapper will be removed
+ at the declaration of the next major ABI version.
+
+#. Once approved, and after the deprecation notice has been observed these
+ changes will form part of the next declared major ABI version.
+
+Examples of ABI Changes
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The following are examples of allowable ABI changes occurring between
+declarations of major ABI versions.
+
+* DPDK 19.11 release, defines the function ``rte_foo()``, and ``rte_foo()``
+ as part of the major ABI version ``20``.
+
+* DPDK 20.02 release defines a new function ``rte_foo(uint8_t bar)``, and
+ this is not a problem as long as the symbol ``rte_foo@DPDK20`` is
+ preserved through ABI Versioning.
+
+ - The new function may be marked with the ``__rte_experimental`` tag for a
+ number of releases, as described in the section :ref:`experimental_apis`.
+
+ - Once ``rte_foo(uint8_t bar)`` becomes non-experimental ``rte_foo()`` is then
+ declared as ``__rte_depreciated``, with an associated deprecation notice
+ provided.
+
+* DPDK 19.11 is not re-released to include ``rte_foo(uint8_t bar)``, the new
+ version of ``rte_foo`` only exists from DPDK 20.02 onwards as described in the
+ :ref:`note on forward-only compatibility<forward-only>`.
+
+* DPDK 20.02 release defines the experimental function ``__rte_experimental
+ rte_baz()``. This function may or may not exist in the DPDK 20.05 release.
+
+* An application ``dPacket`` wishes to use ``rte_foo(uint8_t bar)``, before the
+ declaration of the DPDK ``21`` major API version. The application can only
+ ensure its runtime dependencies are met by specifying ``DPDK (>= 20.2)`` as
+ an explicit package dependency, as the soname only may only indicate the
+ supported major ABI version.
+
+* At the release of DPDK 20.11, the function ``rte_foo(uint8_t bar)`` becomes
+ formally part of then new major ABI version DPDK 21.0 and ``rte_foo()`` may be
+ removed.
+
+.. _deprecation_notices:
Examples of Deprecation Notices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -104,46 +257,42 @@ Examples of Deprecation Notices
The following are some examples of ABI deprecation notices which would be
added to the Release Notes:
-* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
- to be replaced with the inline function ``rte_foo()``.
+* The Macro ``#RTE_FOO`` is deprecated and will be removed with ABI version
+ 21, to be replaced with the inline function ``rte_foo()``.
* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
- in version 2.0. Backwards compatibility will be maintained for this function
- until the release of version 2.1
+ in version 20.2. Backwards compatibility will be maintained for this function
+ until the release of the new DPDK major ABI version 21, in DPDK version
+ 20.11.
-* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
+* The members of ``struct rte_foo`` have been reorganized in DPDK 20.02 for
performance reasons. Existing binary applications will have backwards
- compatibility in release 2.0, while newly built binaries will need to
- reference the new structure variant ``struct rte_foo2``. Compatibility will
- be removed in release 2.2, and all applications will require updating and
+ compatibility in release 20.02, while newly built binaries will need to
+ reference the new structure variant ``struct rte_foo2``. Compatibility will be
+ removed in release 20.11, and all applications will require updating and
rebuilding to the new structure at that time, which will be renamed to the
original ``struct rte_foo``.
* Significant ABI changes are planned for the ``librte_dostuff`` library. The
- upcoming release 2.0 will not contain these changes, but release 2.1 will,
+ upcoming release 20.02 will not contain these changes, but release 20.11 will,
and no backwards compatibility is planned due to the extensive nature of
- these changes. Binaries using this library built prior to version 2.1 will
+ these changes. Binaries using this library built prior to ABI version 21 will
require updating and recompilation.
-New API replacing previous one
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If a new API proposed functionally replaces an existing one, when the new API
-becomes non-experimental then the old one is marked with ``__rte_deprecated``.
-Deprecated APIs are removed completely just after the next LTS.
+.. _experimental_apis:
-Reminder that old API should follow deprecation process to be removed.
+Experimental
+------------
+APIs
+~~~~
-Experimental APIs
------------------
-
-APIs marked as ``experimental`` are not considered part of the ABI and may
-change without warning at any time. Since changes to APIs are most likely
-immediately after their introduction, as users begin to take advantage of
-those new APIs and start finding issues with them, new DPDK APIs will be
-automatically marked as ``experimental`` to allow for a period of stabilization
-before they become part of a tracked ABI.
+APIs marked as ``experimental`` are not considered part of an ABI version and
+may change without warning at any time. Since changes to APIs are most likely
+immediately after their introduction, as users begin to take advantage of those
+new APIs and start finding issues with them, new DPDK APIs will be automatically
+marked as ``experimental`` to allow for a period of stabilization before they
+become part of a tracked ABI version.
Note that marking an API as experimental is a multi step process.
To mark an API as experimental, the symbols which are desired to be exported
@@ -161,7 +310,16 @@ In addition to tagging the code with ``__rte_experimental``,
the doxygen markup must also contain the EXPERIMENTAL string,
and the MAINTAINERS file should note the EXPERIMENTAL libraries.
-For removing the experimental tag associated with an API, deprecation notice
-is not required. Though, an API should remain in experimental state for at least
-one release. Thereafter, normal process of posting patch for review to mailing
-list can be followed.
+For removing the experimental tag associated with an API, deprecation notice is
+not required. Though, an API should remain in experimental state for at least
+one release. Thereafter, the normal process of posting patch for review to
+mailing list can be followed.
+
+Libraries
+~~~~~~~~~
+
+Libraries marked as ``experimental`` are entirely not considered part of an ABI
+version, and may change without warning at any time. Experimental libraries
+always have a major version of ``0`` to indicate they exist outside of
+ABI Versioning, with the minor version incremented with each ABI change
+to library.
diff --git a/doc/guides/contributing/img/abi_stability_policy.svg b/doc/guides/contributing/img/abi_stability_policy.svg
new file mode 100644
index 0000000..4fd4007
--- /dev/null
+++ b/doc/guides/contributing/img/abi_stability_policy.svg
@@ -0,0 +1,1059 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1237.4869"
+ height="481.37463"
+ version="1.1"
+ viewBox="0 0 1237.4869 481.37463"
+ xml:space="preserve"
+ id="svg7800"
+ sodipodi:docname="abi_stability_policy.svg"
+ inkscape:version="0.92.2 (5c3e80d, 2017-08-06)"><metadata
+ id="metadata7804"><rdf:RDF><cc:Work
+ rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" /></cc:Work></rdf:RDF></metadata><sodipodi:namedview
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1"
+ objecttolerance="10"
+ gridtolerance="10"
+ guidetolerance="10"
+ inkscape:pageopacity="0"
+ inkscape:pageshadow="2"
+ inkscape:window-width="1920"
+ inkscape:window-height="1017"
+ id="namedview7802"
+ showgrid="false"
+ inkscape:zoom="0.8875"
+ inkscape:cx="840.50495"
+ inkscape:cy="179.36692"
+ inkscape:window-x="-8"
+ inkscape:window-y="-8"
+ inkscape:window-maximized="1"
+ inkscape:current-layer="svg7800" /><defs
+ id="defs7394"><clipPath
+ id="clipPath3975"><path
+ d="M 0,1.2207e-4 H 960 V 540.00012 H 0 Z"
+ id="path7226"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4003"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7229"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4025"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7232"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4037"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7235"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4049"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7238"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4061"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7241"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4073"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7244"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4085"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7247"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4097"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7250"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4109"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7253"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4121"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7256"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4133"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7259"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4145"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7262"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4157"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7265"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4169"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7268"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4181"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7271"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4193"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7274"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4205"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7277"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4217"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7280"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4229"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7283"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4241"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7286"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4253"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7289"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4265"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7292"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4277"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7295"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4289"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7298"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4301"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7301"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4313"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7304"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4327"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7307"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4339"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7310"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4351"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7313"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4363"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7316"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4375"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7319"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4389"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7322"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4403"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7325"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4417"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7328"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4429"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7331"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4441"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7334"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4453"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7337"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4477"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7340"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4489"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7343"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4501"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7346"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4513"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7349"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4525"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7352"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4537"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7355"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4549"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7358"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4561"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7361"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4573"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7364"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4589"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7367"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4601"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7370"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4615"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7373"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4629"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7376"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4641"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7379"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4653"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7382"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4673"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7385"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4685"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7388"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4699"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7391"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath></defs><g
+ id="g7406"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><path
+ style="fill:#44546a"
+ inkscape:connector-curvature="0"
+ id="path7400"
+ d="m 161.83,180.57 773.79,4.78 c 0.82,0.01 1.49,0.68 1.49,1.51 -0.01,0.83 -0.68,1.5 -1.51,1.49 l -773.79,-4.78 c -0.83,-0.01 -1.5,-0.68 -1.49,-1.51 0.01,-0.83 0.68,-1.5 1.51,-1.49 z m 772.3,1.77 8.97,4.56 -9.03,4.44 z" /><path
+ style="fill:#00b050;fill-rule:evenodd"
+ inkscape:connector-curvature="0"
+ id="path7402"
+ d="m 173.28,182.22 c 0,4.67 3.36,8.46 7.5,8.46 4.14,0 7.5,-3.79 7.5,-8.46 0,-4.67 -3.36,-8.46 -7.5,-8.46 -4.14,0 -7.5,3.79 -7.5,8.46 z" /><path
+ style="fill:#00b050;fill-rule:evenodd"
+ inkscape:connector-curvature="0"
+ id="path7404"
+ d="m 612.24,183.78 c 0,4.67 3.36,8.46 7.5,8.46 4.14,0 7.5,-3.79 7.5,-8.46 0,-4.67 -3.36,-8.46 -7.5,-8.46 -4.14,0 -7.5,3.79 -7.5,8.46 z" /></g><g
+ style="fill:#ff0000;fill-rule:evenodd"
+ id="g7420"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><path
+ inkscape:connector-curvature="0"
+ id="path7408"
+ d="m 228.12,182.22 c 0,4.67 3.36,8.46 7.5,8.46 4.14,0 7.5,-3.79 7.5,-8.46 0,-4.67 -3.36,-8.46 -7.5,-8.46 -4.14,0 -7.5,3.79 -7.5,8.46 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7410"
+ d="m 282.96,182.22 c 0,4.67 3.36,8.46 7.5,8.46 4.14,0 7.5,-3.79 7.5,-8.46 0,-4.67 -3.36,-8.46 -7.5,-8.46 -4.14,0 -7.5,3.79 -7.5,8.46 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7412"
+ d="m 337.8,182.22 c 0,4.67 3.38,8.46 7.56,8.46 4.18,0 7.56,-3.79 7.56,-8.46 0,-4.67 -3.38,-8.46 -7.56,-8.46 -4.18,0 -7.56,3.79 -7.56,8.46 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7414"
+ d="m 447.6,182.22 c 0,4.67 3.36,8.46 7.5,8.46 4.14,0 7.5,-3.79 7.5,-8.46 0,-4.67 -3.36,-8.46 -7.5,-8.46 -4.14,0 -7.5,3.79 -7.5,8.46 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7416"
+ d="m 502.44,182.34 c 0,4.67 3.38,8.46 7.56,8.46 4.18,0 7.56,-3.79 7.56,-8.46 0,-4.67 -3.38,-8.46 -7.56,-8.46 -4.18,0 -7.56,3.79 -7.56,8.46 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7418"
+ d="m 557.28,182.34 c 0,4.67 3.38,8.46 7.56,8.46 4.18,0 7.56,-3.79 7.56,-8.46 0,-4.67 -3.38,-8.46 -7.56,-8.46 -4.18,0 -7.56,3.79 -7.56,8.46 z" /></g><g
+ id="g7426"
+ clip-path="url(#clipPath4003)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7424"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,152.98,149.45)"><tspan
+ id="tspan7422"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 24.10668 31.22496">v19.11</tspan></text>
+</g><path
+ style="fill:#00b050;fill-rule:evenodd;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7428"
+ d="m 499.42541,379.9105 c 0,-6.22651 4.47989,-11.27972 9.99975,-11.27972 5.51986,0 9.99975,5.05321 9.99975,11.27972 0,6.22651 -4.47989,11.27972 -9.99975,11.27972 -5.51986,0 -9.99975,-5.05321 -9.99975,-11.27972 z" /><path
+ style="fill:#00b050;fill-rule:evenodd;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7430"
+ d="m 1084.6908,373.67065 c 0,-6.22651 4.4799,-11.27971 9.9997,-11.27971 5.5199,0 9.9998,5.0532 9.9998,11.27971 0,6.22652 -4.4799,11.27972 -9.9998,11.27972 -5.5198,0 -9.9997,-5.0532 -9.9997,-11.27972 z" /><g
+ style="fill:#ff0000;fill-rule:evenodd"
+ id="g7438"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><path
+ inkscape:connector-curvature="0"
+ id="path7432"
+ d="m 667.08,185.4 c 0,4.64 3.36,8.4 7.5,8.4 4.14,0 7.5,-3.76 7.5,-8.4 0,-4.64 -3.36,-8.4 -7.5,-8.4 -4.14,0 -7.5,3.76 -7.5,8.4 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7434"
+ d="m 721.92,185.58 c 0,4.67 3.38,8.46 7.56,8.46 4.18,0 7.56,-3.79 7.56,-8.46 0,-4.67 -3.38,-8.46 -7.56,-8.46 -4.18,0 -7.56,3.79 -7.56,8.46 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7436"
+ d="m 776.76,185.58 c 0,4.67 3.38,8.46 7.56,8.46 4.18,0 7.56,-3.79 7.56,-8.46 0,-4.67 -3.38,-8.46 -7.56,-8.46 -4.18,0 -7.56,3.79 -7.56,8.46 z" /></g><g
+ id="g7444"
+ clip-path="url(#clipPath4025)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7442"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,210.14,150.1)"><tspan
+ id="tspan7440"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 24.10668 31.22496">v20.02</tspan></text>
+</g><g
+ id="g7450"
+ clip-path="url(#clipPath4037)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7448"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,265.01,150.1)"><tspan
+ id="tspan7446"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 24.10668 31.22496">v20.05</tspan></text>
+</g><g
+ id="g7456"
+ clip-path="url(#clipPath4049)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7454"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,319.9,150.77)"><tspan
+ id="tspan7452"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 24.10668 31.22496">v20.08</tspan></text>
+</g><g
+ id="g7462"
+ clip-path="url(#clipPath4061)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7460"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,375,150.94)"><tspan
+ id="tspan7458"
+ y="0"
+ x="0 7.9180322 14.992224 22.066416 25.652737 32.726929">V20.11</tspan></text>
+</g><g
+ id="g7468"
+ clip-path="url(#clipPath4073)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7466"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,429.17,150.94)"><tspan
+ id="tspan7464"
+ y="0"
+ x="0 6.3569279 13.445184 20.519377 24.105696 31.179888">v21.02</tspan></text>
+</g><g
+ id="g7474"
+ clip-path="url(#clipPath4085)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7472"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,483,150.55)"><tspan
+ id="tspan7470"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 24.10668 31.22496">v21.05</tspan></text>
+</g><g
+ id="g7480"
+ clip-path="url(#clipPath4097)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7478"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,537.38,150.82)"><tspan
+ id="tspan7476"
+ y="0"
+ x="0 6.3569279 13.445184 20.519377 24.105696 31.179888">v21.08</tspan></text>
+</g><g
+ id="g7486"
+ clip-path="url(#clipPath4109)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7484"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,592.27,150.82)"><tspan
+ id="tspan7482"
+ y="0"
+ x="0 6.3569279 13.445184 20.519377 24.105696 31.179888">v21.11</tspan></text>
+</g><g
+ id="g7492"
+ clip-path="url(#clipPath4121)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7490"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,647.14,151.46)"><tspan
+ id="tspan7488"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 24.10668 31.22496">v22.02</tspan></text>
+</g><g
+ id="g7498"
+ clip-path="url(#clipPath4133)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7496"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,702.24,151.63)"><tspan
+ id="tspan7494"
+ y="0"
+ x="0 7.96068 14.99472 22.113001 25.651079 32.76936">V22.05</tspan></text>
+</g><g
+ id="g7504"
+ clip-path="url(#clipPath4145)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7502"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,756.43,151.63)"><tspan
+ id="tspan7500"
+ y="0"
+ x="0 7.96068 14.99472 22.113001 25.651079 32.76936">V22.08</tspan></text>
+</g><g
+ id="g7510"
+ clip-path="url(#clipPath4157)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7508"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,811.99,151.63)"><tspan
+ id="tspan7506"
+ y="0"
+ x="0 7.96068 14.99472 22.113001 25.651079 32.76936">V22.11</tspan></text>
+</g><g
+ id="g7516"
+ clip-path="url(#clipPath4169)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7514"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,105.82,214.18)"><tspan
+ id="tspan7512"
+ y="0"
+ x="0 6.3460798 13.46436">v20</tspan></text>
+</g><g
+ id="g7522"
+ clip-path="url(#clipPath4181)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7520"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,105.5,247.68)"><tspan
+ id="tspan7518"
+ y="0"
+ x="0 6.3569279 13.445184">v21</tspan></text>
+</g><g
+ id="g7528"
+ clip-path="url(#clipPath4193)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7526"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,228.79,214.51)"><tspan
+ id="tspan7524"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7534"
+ clip-path="url(#clipPath4205)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7532"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,283.8,214.51)"><tspan
+ id="tspan7530"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7540"
+ clip-path="url(#clipPath4217)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7538"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,337.68,214.51)"><tspan
+ id="tspan7536"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7546"
+ clip-path="url(#clipPath4229)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7544"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,611.66,285.79)"><tspan
+ id="tspan7542"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7552"
+ clip-path="url(#clipPath4241)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7550"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,666.65,285.79)"><tspan
+ id="tspan7548"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7558"
+ clip-path="url(#clipPath4253)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7556"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,719.4,285.79)"><tspan
+ id="tspan7554"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7564"
+ clip-path="url(#clipPath4265)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7562"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,775.56,285.79)"><tspan
+ id="tspan7560"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7570"
+ clip-path="url(#clipPath4277)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7568"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,398.54,249.22)"><tspan
+ id="tspan7566"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7576"
+ clip-path="url(#clipPath4289)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7574"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,453.53,249.22)"><tspan
+ id="tspan7572"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7582"
+ clip-path="url(#clipPath4301)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7580"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,507.43,249.22)"><tspan
+ id="tspan7578"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7588"
+ clip-path="url(#clipPath4313)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7586"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,561.05,249.22)"><tspan
+ id="tspan7584"
+ y="0"
+ x="0">√</tspan></text>
+</g><path
+ style="fill:#44546a;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7590"
+ d="m 217.67245,474.73479 v -25.14603 c 0,-1.10664 -0.89331,-1.99995 -1.99995,-1.99995 -1.10664,0 -1.99995,0.89331 -1.99995,1.99995 v 25.14603 c 0,1.09331 0.89331,1.99995 1.99995,1.99995 1.10664,0 1.99995,-0.90664 1.99995,-1.99995 z m 3.9999,-23.14608 -5.99985,-11.9997 -5.99985,11.9997 z" /><g
+ id="g7596"
+ clip-path="url(#clipPath4327)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7594"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,170.83,214.51)"><tspan
+ id="tspan7592"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7602"
+ clip-path="url(#clipPath4339)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-weight:bold;font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7600"
+ font-weight="bold"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,23.4,272.33)"><tspan
+ id="tspan7598"
+ y="0"
+ x="0 8.5227842 16.412687 20.167776">ABI </tspan></text>
+</g><g
+ id="g7608"
+ clip-path="url(#clipPath4351)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-weight:bold;font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7606"
+ font-weight="bold"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,46.68,272.33)"><tspan
+ id="tspan7604"
+ y="0"
+ x="0 7.566432 14.640624 19.563025 25.174561 28.662432 36.228863">Version</tspan></text>
+</g><g
+ id="g7614"
+ clip-path="url(#clipPath4363)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-weight:bold;font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7612"
+ font-weight="bold"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,17.64,255.5)"><tspan
+ id="tspan7610"
+ y="0"
+ x="0 7.4271598 14.98068 26.395201 33.934681 40.80024 45.700199 49.154041 56.7216 60.175442 63.671398 67.125237 72.053284">Compatibility</tspan></text>
+</g><g
+ id="g7620"
+ clip-path="url(#clipPath4375)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7618"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,191.28,116.86)"><tspan
+ id="tspan7616"
+ y="0"
+ x="0 6.3460798 13.46436">v20</tspan></text>
+</g><path
+ style="fill:#44546a;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7622"
+ d="m 511.7451,474.89479 v -25.14604 c 0,-1.10664 -0.89331,-1.99995 -1.99995,-1.99995 -1.10664,0 -1.99995,0.89331 -1.99995,1.99995 v 25.14604 c 0,1.09331 0.89331,1.99995 1.99995,1.99995 1.10664,0 1.99995,-0.90664 1.99995,-1.99995 z m 3.9999,-23.14609 -5.99985,-11.9997 -5.99985,11.9997 z" /><g
+ id="g7628"
+ clip-path="url(#clipPath4389)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7626"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,407.06,115.63)"><tspan
+ id="tspan7624"
+ y="0"
+ x="0 6.3460798 13.46436">v21</tspan></text>
+</g><path
+ style="fill:#44546a;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7630"
+ d="m 804.53778,476.01476 v -25.14604 c 0,-1.10664 -0.89331,-1.99995 -1.99995,-1.99995 -1.10664,0 -1.99995,0.89331 -1.99995,1.99995 v 25.14604 c 0,1.09331 0.89331,1.99995 1.99995,1.99995 1.10664,0 1.99995,-0.90664 1.99995,-1.99995 z m 3.9999,-23.14609 -5.99985,-11.9997 -5.99985,11.9997 z" /><g
+ id="g7636"
+ clip-path="url(#clipPath4403)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7634"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,626.66,114.74)"><tspan
+ id="tspan7632"
+ y="0"
+ x="0 6.3460798 13.46436">v22</tspan></text>
+</g><path
+ style="fill:#44546a;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7638"
+ d="m 1098.2904,479.37468 v -25.14604 c 0,-1.10664 -0.8933,-1.99995 -1.9999,-1.99995 -1.1067,0 -2,0.89331 -2,1.99995 v 25.14604 c 0,1.0933 0.8933,1.99995 2,1.99995 1.1066,0 1.9999,-0.90665 1.9999,-1.99995 z m 3.9999,-23.14609 -5.9998,-11.9997 -5.9999,11.9997 z" /><g
+ id="g7644"
+ clip-path="url(#clipPath4417)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7642"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,846.96,112.22)"><tspan
+ id="tspan7640"
+ y="0"
+ x="0 6.3569279 13.445184">v23</tspan></text>
+</g><g
+ id="g7650"
+ clip-path="url(#clipPath4429)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7648"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,832.87,318.46)"><tspan
+ id="tspan7646"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7656"
+ clip-path="url(#clipPath4441)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7654"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,105.5,285.67)"><tspan
+ id="tspan7652"
+ y="0"
+ x="0 6.3460798 13.46436">v22</tspan></text>
+</g><g
+ id="g7662"
+ clip-path="url(#clipPath4453)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7660"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,104.93,319.87)"><tspan
+ id="tspan7658"
+ y="0"
+ x="0 6.3460798 13.46436">v23</tspan></text>
+</g><path
+ style="fill:none;stroke:#5b9bd5;stroke-width:0.63998401;stroke-miterlimit:10;stroke-dasharray:2.559936, 1.919952"
+ inkscape:connector-curvature="0"
+ id="path7664"
+ stroke-miterlimit="10"
+ d="m 1104.7569,213.75465 -934.60326,0.39999" /><path
+ style="fill:none;stroke:#5b9bd5;stroke-width:0.63998401;stroke-miterlimit:10;stroke-dasharray:2.559936, 1.919952"
+ inkscape:connector-curvature="0"
+ id="path7666"
+ stroke-miterlimit="10"
+ d="M 1105.3969,255.35361 170.79362,255.7536" /><path
+ style="fill:none;stroke:#5b9bd5;stroke-width:0.63998401;stroke-miterlimit:10;stroke-dasharray:2.559936, 1.919952"
+ inkscape:connector-curvature="0"
+ id="path7668"
+ stroke-miterlimit="10"
+ d="M 1105.3969,299.35251 170.79362,299.7525" /><g
+ id="g7674"
+ clip-path="url(#clipPath4477)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#8497b0"
+ id="text7672"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,283.8,251.38)"><tspan
+ id="tspan7670"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7680"
+ clip-path="url(#clipPath4489)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#8497b0"
+ id="text7678"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,339.5,251.95)"><tspan
+ id="tspan7676"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7686"
+ clip-path="url(#clipPath4501)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#d0cece"
+ id="text7684"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,229.8,250.63)"><tspan
+ id="tspan7682"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7692"
+ clip-path="url(#clipPath4513)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#d0cece"
+ id="text7690"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,453.53,286.63)"><tspan
+ id="tspan7688"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7698"
+ clip-path="url(#clipPath4525)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#8497b0"
+ id="text7696"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,507.43,286.63)"><tspan
+ id="tspan7694"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7704"
+ clip-path="url(#clipPath4537)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#8497b0"
+ id="text7702"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,561.05,286.63)"><tspan
+ id="tspan7700"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7710"
+ clip-path="url(#clipPath4549)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#d0cece"
+ id="text7708"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,667.39,318.89)"><tspan
+ id="tspan7706"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7716"
+ clip-path="url(#clipPath4561)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#8497b0"
+ id="text7714"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,720.14,318.89)"><tspan
+ id="tspan7712"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7722"
+ clip-path="url(#clipPath4573)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#8497b0"
+ id="text7720"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,776.3,318.89)"><tspan
+ id="tspan7718"
+ y="0"
+ x="0">√</tspan></text>
+</g><path
+ style="fill:#7030a0;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7724"
+ d="m 211.36594,305.0057 2.18661,-227.154316 c 0.0133,-1.0933 -0.87997,-1.99995 -1.98661,-2.01328 -1.09331,-0.0133 -1.99995,0.87998 -2.01329,1.98662 l -2.18661,227.140986 c -0.0133,1.10663 0.87998,2.01328 1.98662,2.02661 1.10664,0.0133 1.99995,-0.87998 2.01328,-1.98662 z m -7.97313,-2.07994 5.87985,12.06636 6.11985,-11.94637 z" /><path
+ style="fill:#7030a0;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7726"
+ d="M 289.03067,238.94069 V 107.43731 c 0,-1.10664 -0.89331,-1.99995 -1.99995,-1.99995 -1.10664,0 -1.99995,0.89331 -1.99995,1.99995 v 131.50338 c 0,1.09331 0.89331,1.99995 1.99995,1.99995 1.10664,0 1.99995,-0.90664 1.99995,-1.99995 z m -7.9998,-1.99995 5.99985,11.9997 5.99985,-11.9997 z" /><g
+ id="g7732"
+ clip-path="url(#clipPath4589)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7730"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,164.59,422.74)"><tspan
+ id="tspan7728"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 23.75568 31.88484 39.578758 43.06068 46.065239 49.294441 54.784081 57.957119 65.271957 72.263878 78.118561 81.347763 88.072922 92.762283 99.754204 107.04096 110.38248 117.10764 120.33684 123.56604 130.17888 137.50777 144.49968 151.78644 155.12796 165.16656 168.43788 173.14128 180.44208 183.67128 190.01736 197.13564 204.19775 207.77795 214.89624 221.94432 225.17352 229.9752 236.70036">v20 ABI is declared aligned with v19.11 LTS</tspan></text>
+</g><g
+ id="g7738"
+ clip-path="url(#clipPath4601)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7736"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,222.12,398.3)"><tspan
+ id="tspan7734"
+ y="0"
+ x="0 6.3569279 13.445184 20.519377 23.740032 29.014032 35.385025 46.537777 53.851055 61.262783 64.497505 70.038719 73.034355 79.771011 84.440254 91.401939 94.622589 101.35925 108.65846 115.97174 122.93343 130.2467 133.59393 140.3306 147.62981 154.94308 158.16374 164.52068 171.60893 178.68312 181.90378 187.17778 193.54877 204.70152 212.0148 219.42653 222.66125 228.20247 231.32468 238.06133 242.73058 249.69226 252.81447 263.98129 271.39301 278.77661 282.01132 286.30084 289.53555 296.53943 303.82458 307.34061 310.51904 316.0462 323.3595 330.67276 337.98605 345.39777 350.30612 355.01755 358.13977 362.21832 369.63004 374.53839 377.5762 383.93314 391.02139 398.09558 401.2178 409.36084 417.03979 420.51361 423.6358 429.40204 436.81378 444.04266 448.75412 451.98883 459.28806 466.60132 473.56302 479.06204">v21 symbols are added and v20 symbols are modified, support for v20 ABI continues.</tspan></text>
+</g><path
+ style="fill:#7030a0;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7740"
+ d="m 510.78512,258.56686 -0.31999,-126.17017 c 0,-1.09331 0.89331,-1.99995 1.99995,-1.99995 1.09331,0 1.99995,0.89331 1.99995,1.99995 l 0.31999,126.15684 c 0,1.10664 -0.89331,2.01328 -1.99995,2.01328 -1.0933,0 -1.99995,-0.89331 -1.99995,-1.99995 z m 7.9998,-2.01328 -5.97318,12.01303 -6.02652,-11.98636 z" /><g
+ id="g7746"
+ clip-path="url(#clipPath4615)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7744"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,388.51,373.39)"><tspan
+ id="tspan7742"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 23.75568 31.88484 39.578758 43.06068 46.065239 49.294441 54.784081 57.957119 65.271957 72.263878 78.118561 81.347763 88.072922 92.762283 99.754204 107.04096 110.38248 117.10764 120.33684 123.56604 130.17888 137.50777 144.49968 151.78644 155.12796 165.16656 168.43788 173.14128 180.44208 183.67128 190.01736 197.13564 204.19775 207.77795 214.89624 221.94432 225.17352 229.9752 236.70036 243.14471 246.65472 249.78564 254.46095 261.45288 272.58661 279.31177 282.54095 289.86984 293.09903 300.47003 307.02673 310.36823 316.71432 323.83261 330.89471 334.12393 339.40295 345.76309 356.92487 364.23972 371.63879 374.91013 380.39975 383.4324 390.15756 394.83289 401.8248 404.99783 409.71527 416.70721 427.84091 435.23999 441.51587 448.50781 455.79456">v21 ABI is declared aligned with v20.11 LTS, remaining v20 symbols are removed.</tspan></text>
+</g><path
+ style="fill:none;stroke:#7030a0;stroke-width:2.07994795;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path7748"
+ stroke-miterlimit="10"
+ d="M 278.23094,342.95142 H 449.58665 V 261.03347 H 278.23094 Z" /><g
+ id="g7754"
+ clip-path="url(#clipPath4629)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-weight:bold;font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7752"
+ font-weight="bold"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,23.616,114.74)"><tspan
+ id="tspan7750"
+ y="0"
+ x="0 8.5082397 16.4268 20.17548 23.26428 30.817801 37.879921 42.821999 48.423962 51.93396 59.48748 67.026962">ABI Versions</tspan></text>
+</g><g
+ id="g7760"
+ clip-path="url(#clipPath4641)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-weight:bold;font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7758"
+ font-weight="bold"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,20.064,150.17)"><tspan
+ id="tspan7756"
+ y="0"
+ x="0 8.8451996 16.31448 25.159679 32.839561 36.0126 43.67844 50.740559 54.222481 61.284599 68.248444 73.850403 80.954643">DPDK Releases</tspan></text>
+</g><g
+ id="g7766"
+ clip-path="url(#clipPath4653)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7764"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,444,346.1)"><tspan
+ id="tspan7762"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 23.75568 29.034719 35.39484 46.556641 53.871479 61.270561 64.541878 70.031517 73.064163 79.789322 84.464638 91.456558 94.629601 101.35476 108.72576 116.02656 123.01848 130.30524 133.64676 140.37192 147.68677 155.0016 158.2308 164.57687 171.69516 178.75728 181.98648 187.26552 193.62564 204.78745 212.10228 219.50136 222.77267 228.26231 231.43536 238.16052 242.80775 249.79968 252.88847 264.05029 271.44937 278.82037 282.04956 286.33176 289.60309 296.595 303.88177 307.39175 310.56479 316.1106 323.42545 330.74026 338.05511 345.45419 350.39627 355.09967 358.20251 362.28815 369.68723 374.62933 377.63388 383.97995 391.09824 398.16037 401.27725 409.4064 417.10031 420.58224 423.69913 429.45551 436.85461 444.09924 448.80264 452.03183 459.33264 466.64749 473.6394 479.12903 488.81665 492.43896">v22 symbols are added and v21 symbols are modified, support for v21 ABI continues…..</tspan></text>
+</g><path
+ style="fill:#7030a0;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7768"
+ d="m 583.39664,198.26171 -0.13333,-30.49257 c 0,-1.10664 0.89331,-2.01329 1.98662,-2.01329 1.10664,0 2.01328,0.89331 2.01328,1.98662 l 0.13333,30.49257 c 0,1.10664 -0.89331,2.01328 -1.99995,2.01328 -1.0933,0 -1.99995,-0.89331 -1.99995,-1.98661 z m 7.98647,-2.03995 -5.94652,12.02636 -6.05318,-11.97303 z" /><path
+ style="fill:none;stroke:#7030a0;stroke-width:2.07994795;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path7770"
+ stroke-miterlimit="10"
+ d="M 571.18361,299.43251 H 742.37933 V 212.87467 H 571.18361 Z" /><path
+ style="fill:#00b050;fill-rule:evenodd;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7772"
+ d="m 933.01457,30.959224 c 0,-6.22651 4.50655,-11.27972 10.07975,-11.27972 5.57319,0 10.07974,5.05321 10.07974,11.27972 0,6.22651 -4.50655,11.27972 -10.07974,11.27972 -5.5732,0 -10.07975,-5.05321 -10.07975,-11.27972 z" /><path
+ style="fill:#ff0000;fill-rule:evenodd;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7774"
+ d="m 1081.3309,29.759254 c 0,-6.18651 4.4798,-11.19972 9.9997,-11.19972 5.5199,0 9.9998,5.01321 9.9998,11.19972 0,6.18651 -4.4799,11.19972 -9.9998,11.19972 -5.5199,0 -9.9997,-5.01321 -9.9997,-11.19972 z" /><g
+ id="g7780"
+ clip-path="url(#clipPath4673)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7778"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,744.89,439.54)"><tspan
+ id="tspan7776"
+ y="0"
+ x="0 4.8016801 11.52684 17.971201 21.144239 28.5714 35.56332 38.792519 45.728279 52.453442 57.943081">LTS Release</tspan></text>
+</g><g
+ id="g7786"
+ clip-path="url(#clipPath4685)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7784"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,856.06,439.75)"><tspan
+ id="tspan7782"
+ y="0"
+ x="0 12.0042 15.2334 22.562281 29.961361 34.903439 38.020321 45.461521 52.453442 55.68264 62.618401 69.343559 74.833199">Minor Release</tspan></text>
+</g><path
+ style="fill:#44546a;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7788"
+ d="m 779.25841,46.265514 v -25.14604 c 0,-1.10664 -0.89331,-1.99995 -1.99995,-1.99995 -1.10664,0 -1.99995,0.89331 -1.99995,1.99995 v 25.14604 c 0,1.0933 0.89331,1.99995 1.99995,1.99995 1.10664,0 1.99995,-0.90665 1.99995,-1.99995 z m 3.9999,-23.14609 -5.99985,-11.9997 -5.99985,11.9997 z" /><g
+ id="g7794"
+ clip-path="url(#clipPath4699)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7792"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,622.34,439.54)"><tspan
+ id="tspan7790"
+ y="0"
+ x="0 8.1291599 15.82308 19.305 22.309561 29.512079 36.504002 41.151241 46.640881 49.870079 57.339359">ABI Version</tspan></text>
+</g><path
+ style="fill:none;stroke:#002060;stroke-width:1.27996802;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path7796"
+ stroke-miterlimit="10"
+ d="M 763.41881,62.078444 H 1236.847 V 0.63998401 H 763.41881 Z" /></svg>
\ No newline at end of file
diff --git a/doc/guides/contributing/img/what_is_an_abi.svg b/doc/guides/contributing/img/what_is_an_abi.svg
new file mode 100644
index 0000000..fd3d993
--- /dev/null
+++ b/doc/guides/contributing/img/what_is_an_abi.svg
@@ -0,0 +1,382 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="970.69568"
+ height="522.22693"
+ version="1.1"
+ viewBox="0 0 970.69568 522.22693"
+ xml:space="preserve"
+ id="svg8399"
+ sodipodi:docname="what_is_an_abi.svg"
+ inkscape:version="0.92.2 (5c3e80d, 2017-08-06)"><metadata
+ id="metadata8403"><rdf:RDF><cc:Work
+ rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" /></cc:Work></rdf:RDF></metadata><sodipodi:namedview
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1"
+ objecttolerance="10"
+ gridtolerance="10"
+ guidetolerance="10"
+ inkscape:pageopacity="0"
+ inkscape:pageshadow="2"
+ inkscape:window-width="1920"
+ inkscape:window-height="1017"
+ id="namedview8401"
+ showgrid="false"
+ inkscape:zoom="0.62755727"
+ inkscape:cx="820.83951"
+ inkscape:cy="-47.473217"
+ inkscape:window-x="-8"
+ inkscape:window-y="-8"
+ inkscape:window-maximized="1"
+ inkscape:current-layer="svg8399" /><defs
+ id="defs8269"><clipPath
+ id="clipPath26"><path
+ d="M 0,1.2207e-4 H 960 V 540.00012 H 0 Z"
+ id="path8206"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><radialGradient
+ id="radialGradient40"
+ cx="0"
+ cy="0"
+ r="1"
+ gradientTransform="matrix(386.44367,-1.3123672e-5,-1.3123672e-5,-386.44367,470.30824,246.15384)"
+ gradientUnits="userSpaceOnUse"><stop
+ stop-color="#f9d8e2"
+ offset="0"
+ id="stop8209" /><stop
+ stop-color="#fff"
+ offset=".74"
+ id="stop8211" /><stop
+ stop-color="#fff"
+ offset=".83"
+ id="stop8213" /><stop
+ stop-color="#fff"
+ offset="1"
+ id="stop8215" /></radialGradient><clipPath
+ id="clipPath56"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8218"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath68"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8221"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath82"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8224"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath96"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8227"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath108"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8230"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath120"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8233"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath132"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8236"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath144"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8239"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath156"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8242"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath168"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8245"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath180"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8248"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath192"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8251"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath204"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8254"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath216"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8257"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath228"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8260"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath240"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8263"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath260"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8266"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath></defs><path
+ inkscape:connector-curvature="0"
+ style="fill:url(#radialGradient40);fill-rule:evenodd;stroke-width:1.33329999"
+ id="path8275"
+ d="m 116.15709,143.06309 c 0,-28.46596 23.07942,-51.545378 51.54538,-51.545378 h 605.21154 c 28.46595,0 51.54537,23.079418 51.54537,51.545378 V 349.2446 c 0,28.46595 -23.07942,51.54538 -51.54537,51.54538 H 167.70247 c -28.46595,0 -51.54538,-23.07943 -51.54538,-51.54538 z" /><path
+ style="fill:#00b050;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path8277"
+ d="m 478.70803,73.758152 0.58665,373.057338 c 0,1.67996 -1.35997,3.03993 -3.03992,3.03993 -1.67996,0.0133 -3.03993,-1.34663 -3.03993,-3.02659 L 472.62818,73.758152 c 0,-1.67995 1.35997,-3.03992 3.03992,-3.03992 1.67996,0 3.03993,1.35997 3.03993,3.03992 z m 6.65317,370.004088 -9.09311,18.25287 -9.14644,-18.22621 z" /><path
+ style="fill:none;stroke:#7030a0;stroke-width:6.07984781;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path8279"
+ stroke-miterlimit="10"
+ d="m 3.0399239,186.92866 c 0,-36.70575 29.7459201,-66.45167 66.4516701,-66.45167 H 778.00721 c 36.70575,0 66.45167,29.74592 66.45167,66.45167 v 265.80669 c 0,36.70574 -29.74592,66.45167 -66.45167,66.45167 H 69.491594 c -36.70575,0 -66.4516701,-29.74593 -66.4516701,-66.45167 z" /><path
+ style="fill:none;stroke:#3b3059;stroke-width:6.07984781;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path8281"
+ stroke-miterlimit="10"
+ d="m 101.27746,71.464882 c 0,-37.78572 30.63924,-68.4249581 68.42496,-68.4249581 h 729.52846 c 37.7857,0 68.4249,30.6392381 68.4249,68.4249581 V 345.1647 c 0,37.78572 -30.6392,68.42496 -68.4249,68.42496 H 169.70242 c -37.78572,0 -68.42496,-30.63924 -68.42496,-68.42496 z" /><g
+ id="g8287"
+ clip-path="url(#clipPath56)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:32.06399918px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8285"
+ font-size="32.064px"
+ transform="matrix(1,0,0,-1,409.78,93.312)"><tspan
+ id="tspan8283"
+ y="0"
+ x="0 23.855616 42.837505 66.693123">DPDK</tspan></text>
+</g><g
+ id="g8293"
+ clip-path="url(#clipPath68)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:32.06399918px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8291"
+ font-size="32.064px"
+ transform="matrix(1,0,0,-1,358.03,435.43)"><tspan
+ id="tspan8289"
+ y="0"
+ x="0 23.72736 45.595009 67.462654 73.875458 80.160004 100.90541 122.80512 133.54655 139.95937 160.96127">Application</tspan></text>
+</g><path
+ style="fill:#f9d8e2;fill-opacity:0.70196001;fill-rule:evenodd;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path8295"
+ d="M 424.30939,345.59136 H 531.18672 V 277.91305 H 424.30939 Z" /><g
+ id="g8301"
+ clip-path="url(#clipPath82)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:32.04000092px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8299"
+ font-size="32.04px"
+ transform="matrix(1,0,0,-1,432.96,231.41)"><tspan
+ id="tspan8297"
+ y="0"
+ x="0 23.7096 42.67728">API</tspan></text>
+</g><path
+ style="fill:#f9d8e2;fill-opacity:0.70196001;fill-rule:evenodd;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path8303"
+ d="m 422.38944,213.91465 h 107.19732 v -67.8383 H 422.38944 Z" /><g
+ id="g8309"
+ clip-path="url(#clipPath96)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:32.04000092px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8307"
+ font-size="32.04px"
+ transform="matrix(1,0,0,-1,431.54,330.29)"><tspan
+ id="tspan8305"
+ y="0"
+ x="0 23.7096 42.100559">ABI</tspan></text>
+</g><g
+ id="g8315"
+ clip-path="url(#clipPath108)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8313"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,221.78,293.23)"><tspan
+ id="tspan8311"
+ y="0"
+ x="0 9.4483204 14.25228 24.706079 35.447159 40.203239 51.10392 66.106323 81.076797 84.332642 94.068237">Programming</tspan></text>
+</g><g
+ id="g8321"
+ clip-path="url(#clipPath120)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.98400021px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8319"
+ font-size="15.984px"
+ transform="matrix(1,0,0,-1,221.78,274.03)"><tspan
+ id="tspan8317"
+ y="0"
+ x="0 7.320672 18.237743 27.987984 38.633327 48.351601 59.268673 69.945984">Language</tspan></text>
+</g><g
+ id="g8327"
+ clip-path="url(#clipPath132)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8325"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,221.78,254.81)"><tspan
+ id="tspan8323"
+ y="0"
+ x="0 7.6767602 17.38044 27.116039 37.442162 42.708961 45.93288 56.386681 66.122276">Functions</tspan></text>
+</g><g
+ id="g8333"
+ clip-path="url(#clipPath144)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8331"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,221.78,235.61)"><tspan
+ id="tspan8329"
+ y="0"
+ x="0 11.87424 22.77492 28.073641 38.974319 44.273041 52.891441 63.776161 74.150162">Datatypes</tspan></text>
+</g><g
+ id="g8339"
+ clip-path="url(#clipPath156)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8337"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,221.78,216.41)"><tspan
+ id="tspan8335"
+ y="0"
+ x="0 9.6877203 20.06172 25.312559 35.016239 39.820202 49.555801 54.216122 60.823559 69.441963 80.326683 90.700684">Return Types</tspan></text>
+</g><g
+ id="g8345"
+ clip-path="url(#clipPath168)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8343"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,221.78,197.21)"><tspan
+ id="tspan8341"
+ y="0"
+ x="0 12.97548 23.429279 33.164879 39.357361 44.640121 55.540798 65.276398 70.559158">Constants</tspan></text>
+</g><g
+ id="g8351"
+ clip-path="url(#clipPath180)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8349"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,221.78,178.01)"><tspan
+ id="tspan8347"
+ y="0"
+ x="0">…</tspan></text>
+</g><g
+ id="g8357"
+ clip-path="url(#clipPath192)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8355"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,546.38,354.12)"><tspan
+ id="tspan8353"
+ y="0"
+ x="0 3.8304 13.566 19.75848 25.07316 29.877119 39.580799 49.906921 55.189678 58.413601 68.867401 78.602997 83.2314 89.423882 99.797882">Instruction set</tspan></text>
+</g><g
+ id="g8363"
+ clip-path="url(#clipPath204)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.98400021px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8361"
+ font-size="15.984px"
+ transform="matrix(1,0,0,-1,546.38,332.88)"><tspan
+ id="tspan8359"
+ y="0"
+ x="0 8.5674238 16.239744 26.517456 36.859104 46.577377 51.836113 62.753185 73.654274 77.026894 87.352562 91.892014 103.99191 108.33955 115.66022 118.85703 128.60727 136.63123 147.02083">Executable & Linker</tspan></text>
+</g><g
+ id="g8369"
+ clip-path="url(#clipPath216)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8367"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,546.38,313.66)"><tspan
+ id="tspan8365"
+ y="0"
+ x="0 7.6767602 18.13056 22.934521 37.904999 48.805679">Format</tspan></text>
+</g><g
+ id="g8375"
+ clip-path="url(#clipPath228)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8373"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,546.38,292.42)"><tspan
+ id="tspan8371"
+ y="0"
+ x="0 12.97548 23.87616 27.22776 30.579359 33.80328 43.538879 54.200161 58.39764 71.373123 81.82692 91.562523 100.6278 110.95392 120.68952 125.95632 129.18024 139.63403 149.36964 155.56212">Calling Conventions.</tspan></text>
+</g><g
+ id="g8381"
+ clip-path="url(#clipPath240)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8379"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,546.38,271.3)"><tspan
+ id="tspan8377"
+ y="0"
+ x="0">…</tspan></text>
+</g><path
+ style="fill:none;stroke:#ffffff;stroke-width:6.07984781;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:18.239544, 24.319392"
+ inkscape:connector-curvature="0"
+ id="path8383"
+ stroke-miterlimit="10"
+ d="M 122.71693,120.47699 H 782.84709" /><path
+ style="fill:none;stroke:#ffffff;stroke-width:6.07984781;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:18.239544, 24.319392"
+ inkscape:connector-curvature="0"
+ id="path8385"
+ stroke-miterlimit="10"
+ d="M 177.27556,413.58966 H 837.40573" /><g
+ id="g8391"
+ clip-path="url(#clipPath260)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-style:italic;font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8389"
+ font-style="italic"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,483.19,405.82)"><tspan
+ id="tspan8387"
+ y="0"
+ x="0 5.0114398 14.71512 24.45072 34.77684 40.299 43.522919 53.976719 63.712318 68.13324 78.459358 89.360039 92.583961 95.807877">function calls</tspan></text>
+</g><path
+ style="fill:none;stroke:#3b3059;stroke-width:0.95997602;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path8393"
+ stroke-miterlimit="10"
+ d="m 574.38564,303.03242 c -11.93304,0 -21.59946,-1.61329 -21.59946,-3.59991 V 164.62255 c 0,-1.98662 -9.66643,-3.59991 -21.59946,-3.59991 11.93303,0 21.59946,-1.61329 21.59946,-3.59991 v -18.30621 c 0,-1.98662 9.66642,-3.59991 21.59946,-3.59991" /><path
+ style="fill:none;stroke:#3b3059;stroke-width:0.95997602;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path8395"
+ stroke-miterlimit="10"
+ d="m 372.63068,389.43026 c 13.293,0 24.0794,-1.79995 24.0794,-4.01323 v -91.53105 c 0,-2.21327 10.78639,-4.01323 24.0794,-4.01323 -13.29301,0 -24.0794,-1.79995 -24.0794,-4.01323 v -65.3717 c 0,-2.21328 -10.7864,-4.01323 -24.0794,-4.01323" /></svg>
\ No newline at end of file
diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing/stable.rst
index 6a5eee9..4d38bb8 100644
--- a/doc/guides/contributing/stable.rst
+++ b/doc/guides/contributing/stable.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: BSD-3-Clause
Copyright 2018 The DPDK contributors
-.. stable_lts_releases:
+.. _stable_lts_releases:
DPDK Stable Releases and Long Term Support
==========================================
@@ -53,6 +53,9 @@ year's November (X.11) release will be maintained as an LTS for 2 years.
After the X.11 release, an LTS branch will be created for it at
http://git.dpdk.org/dpdk-stable where bugfixes will be backported to.
+A LTS release may align with the declaration of a new major ABI version,
+please read the :doc:`abi_policy` for more information.
+
It is anticipated that there will be at least 4 releases per year of the LTS
or approximately 1 every 3 months. However, the cadence can be shorter or
longer depending on the number and criticality of the backported
@@ -119,10 +122,3 @@ A Stable Release will be released by:
list.
Stable releases are available on the `dpdk.org download page <http://core.dpdk.org/download/>`_.
-
-
-ABI
----
-
-The Stable Release should not be seen as a way of breaking or circumventing
-the DPDK ABI policy.
--
2.7.4
^ permalink raw reply [relevance 23%]
* [dpdk-dev] [PATCH v9 0/4] doc: changes to abi policy introducing major abi versions
@ 2019-11-08 12:46 10% Ray Kinsella
2019-11-08 12:46 18% ` [dpdk-dev] [PATCH v9 1/4] doc: separate versioning.rst into version and policy Ray Kinsella
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: Ray Kinsella @ 2019-11-08 12:46 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, john.mcnamara, marko.kovacevic, hemant.agrawal,
ktraynor, aconole
TL;DR abbreviation:
A major ABI version that all DPDK releases during an agreed period support. ABI
versioning is managed at a project-level, in place of library-level management.
ABI changes to add new features are permitted, as long as ABI compatibility with
the major ABI version is maintained.
Detail:
This patch introduces major ABI versions, initally released aligned with the LTS
release and maintained for one year through subsequent releases. The intention
is that the one year abi support period, will then be reviewed after the initial
year with the intention of lengthening the period for the next ABI version and
declaring new major ABI versions less frequently.
ABI changes that preserve ABI compatibility with the major ABI version are
permitted in subsequent releases. ABI changes, follow similar approval rules as
before with the additional gate of now requiring technical board approval. The
merging and release of ABI breaking changes would now be pushed to the
declaration of the next major ABI version.
This change encourages developers to maintain ABI compatibility with the major
ABI version, by promoting a permissive culture around those changes that
preserve ABI compatibility. This approach begins to align DPDK with those
projects that declare major ABI versions (e.g. version 2.x, 3.x) and support
those versions for some period, typically two years or more.
To provide an example of how this might work in practice:
* DPDK v20 is declared as the supported ABI version for one year, aligned with
the DPDK v19.11 (LTS) release. All library sonames are updated to reflect the
new ABI version, e.g. librte_eal.so.20, librte_acl.so.20...
* DPDK v20.02 .. v20.08 releases are ABI compatible with the DPDK v20 ABI. ABI
changes are permitted from DPDK v20.02 onwards, with the condition that ABI
compatibility with DPDK v20 is preserved.
* DPDK v21 is declared as the new supported ABI version for two years, aligned
with the DPDK v20.11 (LTS) release. The DPDK v20 ABI is now depreciated,
library sonames are updated to v21 and ABI compatibility breaking changes may
be introduced.
v9
* Loosened up word around when new major ABI's are declared.
(as suggested by Thomas Monjalon and agreed at the Techboard)
v8
* Fixed intermediate build warnings, figure annotations and typo's.
(as suggested by John McNamara).
v7
* PNGs are now SVG. Some additional clarifications. Fixed typos and grammatical
errors. (as suggested by Thomas Monjalon and David Marchand)
v6
* Added figure to abi_policy.rst, comparing and contrasting the DPDK abi and
api. (as suggested by Aaron Conole)
v5
* Added figure to abi_policy.rst, mapping abi versions and abi compatibility to
DPDK releases. (as suggested by Neil Horman)
v4
* Removed changes to stable.rst, fixed typos and clarified the ABI policy
"warning".
v3
* Added myself as the maintainer of the ABI policy.
* Updated the policy and versioning guides to use the year of the LTS+1 (e.g.
v20), as the abi major version number.
v2
* Restructured the patch into 3 patches:
1. Splits the original versioning document into an ABI policy document
and ABI versioning document.
2. Add changes to the policy document introducing major ABI versions.
3. Fixes up the versioning document in light of major ABI versioning.
* Reduces the initial ABI stability from two years to one year, with a review
after the first year.
* Adds detail around ABI version handling for experimental libraries.
* Adds detail around chain of responsility for removing deprecated symbols.
Ray Kinsella (4):
doc: separate versioning.rst into version and policy
doc: changes to abi policy introducing major abi versions
doc: updates to versioning guide for abi versions
doc: add maintainer for abi policy
MAINTAINERS | 4 +
doc/guides/contributing/abi_policy.rst | 326 ++++++
doc/guides/contributing/abi_versioning.rst | 515 ++++++++++
.../contributing/img/abi_stability_policy.svg | 1059 ++++++++++++++++++++
doc/guides/contributing/img/what_is_an_abi.svg | 382 +++++++
doc/guides/contributing/index.rst | 3 +-
doc/guides/contributing/patches.rst | 6 +-
doc/guides/contributing/stable.rst | 12 +-
doc/guides/contributing/versioning.rst | 591 -----------
doc/guides/rel_notes/deprecation.rst | 6 +-
10 files changed, 2298 insertions(+), 606 deletions(-)
create mode 100644 doc/guides/contributing/abi_policy.rst
create mode 100644 doc/guides/contributing/abi_versioning.rst
create mode 100644 doc/guides/contributing/img/abi_stability_policy.svg
create mode 100644 doc/guides/contributing/img/what_is_an_abi.svg
delete mode 100644 doc/guides/contributing/versioning.rst
--
2.7.4
^ permalink raw reply [relevance 10%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
2019-11-08 11:37 0% ` Ferruh Yigit
@ 2019-11-08 11:56 0% ` Matan Azrad
2019-11-08 12:51 0% ` Ferruh Yigit
2019-11-08 13:11 0% ` Ananyev, Konstantin
0 siblings, 2 replies; 200+ results
From: Matan Azrad @ 2019-11-08 11:56 UTC (permalink / raw)
To: Ferruh Yigit, Dekel Peled, john.mcnamara, marko.kovacevic,
nhorman, ajit.khaparde, somnath.kotur, anatoly.burakov,
xuanziyang2, cloud.wangxiaoyun, zhouguoyang, wenzhuo.lu,
konstantin.ananyev, Shahaf Shuler, Slava Ovsiienko, rmody,
shshaikh, maxime.coquelin, tiwei.bie, zhihong.wang, yongwang,
Thomas Monjalon, arybchenko, jingjing.wu, bernard.iremonger
Cc: dev
From: Ferruh Yigit
> On 11/8/2019 10:10 AM, Matan Azrad wrote:
> >
> >
> > From: Ferruh Yigit
> >> On 11/8/2019 6:54 AM, Matan Azrad wrote:
> >>> Hi
> >>>
> >>> From: Ferruh Yigit
> >>>> On 11/7/2019 12:35 PM, Dekel Peled wrote:
> >>>>> @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
> >>>>>
> >>>> RTE_ETHER_MAX_LEN;
> >>>>> }
> >>>>>
> >>>>> + /*
> >>>>> + * If LRO is enabled, check that the maximum aggregated
> packet
> >>>>> + * size is supported by the configured device.
> >>>>> + */
> >>>>> + if (dev_conf->rxmode.offloads &
> DEV_RX_OFFLOAD_TCP_LRO) {
> >>>>> + ret = check_lro_pkt_size(
> >>>>> + port_id, dev_conf-
> >>>>> rxmode.max_lro_pkt_size,
> >>>>> + dev_info.max_lro_pkt_size);
> >>>>> + if (ret != 0)
> >>>>> + goto rollback;
> >>>>> + }
> >>>>> +
> >>>>
> >>>> This check forces applications that enable LRO to provide
> >> 'max_lro_pkt_size'
> >>>> config value.
> >>>
> >>> Yes.(we can break an API, we noticed it)
> >>
> >> I am not talking about API/ABI breakage, that part is OK.
> >> With this check, if the application requested LRO offload but not
> >> provided 'max_lro_pkt_size' value, device configuration will fail.
> >>
> > Yes
> >> Can there be a case application is good with whatever the PMD can
> >> support as max?
> > Yes can be - you know, we can do everything we want but it is better to be
> consistent:
> > Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
> lro pkt len should be mandatory for LRO offload.
> >
> > So your question is actually why both, non-lro packets and LRO packets max
> size are mandatory...
> >
> >
> > I think it should be important values for net applications management.
> > Also good for mbuf size managements.
> >
> >>>
> >>>> - Why it is mandatory now, how it was working before if it is
> >>>> mandatory value?
> >>>
> >>> It is the same as max_rx_pkt_len which is mandatory for jumbo frame
> >> offload.
> >>> So now, when the user configures a LRO offload he must to set max
> >>> lro pkt
> >> len.
> >>> We don't want to confuse the user here with the max rx pkt len
> >> configurations and behaviors, they should be with same logic.
> >>>
> >>> This parameter defines well the LRO behavior.
> >>> Before this, each PMD took its own interpretation to what should be
> >>> the
> >> maximum size for LRO aggregated packets.
> >>> Now, the user must say what is his intension, and the ethdev can
> >>> limit it
> >> according to the device capability.
> >>> By this way, also, the PMD can organize\optimize its data-path more.
> >>> Also, the application can create different mempools for LRO queues
> >>> to
> >> allow bigger packet receiving for LRO traffic.
> >>>
> >>>> - What happens if PMD doesn't provide 'max_lro_pkt_size', so it is '0'?
> >>> Yes, you can see the feature description Dekel added.
> >>> This patch also updates all the PMDs support an LRO for non-0 value.
> >>
> >> Of course I can see the updates Matan, my point is "What happens if
> >> PMD doesn't provide 'max_lro_pkt_size'",
> >> 1) There is no check for it right, so it is acceptable?
> >
> > There is check.
> > If the capability is 0, any non-zero configuration will fail.
> >
> >> 2) Are we making this filed mandatory to provide for PMDs, it is easy
> >> to make new fields mandatory for PMDs but is this really necessary?
> >
> > Yes, for consistence.
> >
> >>>
> >>> as same as max rx pkt len, no?
> >>>
> >>>> - What do you think setting 'max_lro_pkt_size' config value to what
> >>>> PMD provided if application doesn't provide it?
> >>> Same answers as above.
> >>>
> >>
> >> If application doesn't care the value, as it has been till now, and
> >> not provided explicit 'max_lro_pkt_size', why not ethdev level use
> >> the value provided by PMD instead of failing?
> >
> > Again, same question we can ask on max rx pkt len.
> >
> > Looks like the packet size is very important value which should be set by
> the application.
> >
> > Previous applications have no option to configure it, so they haven't
> configure it, (probably cover it somehow) I think it is our miss to supply this
> info.
> >
> > Let's do it in same way as we do max rx pkt len (as this patch main idea).
> > Later, we can change both to other meaning.
> >
>
> I think it is not a good reason to introduce a new mandatory config option for
> application because of 'max_rx_pkt_len' does it.
It is mandatory only if LRO offload is configured.
> Will it work, if:
> - If application doesn't provide this value, use the PMD max
May cause a problem if the mbuf size is not enough for the PMD maximum.
> - If both application and PMD doesn't provide this value, fail on configure()?
It will work.
In my opinion - not ideal.
Matan
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
2019-11-08 10:10 0% ` Matan Azrad
@ 2019-11-08 11:37 0% ` Ferruh Yigit
2019-11-08 11:56 0% ` Matan Azrad
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-11-08 11:37 UTC (permalink / raw)
To: Matan Azrad, Dekel Peled, john.mcnamara, marko.kovacevic,
nhorman, ajit.khaparde, somnath.kotur, anatoly.burakov,
xuanziyang2, cloud.wangxiaoyun, zhouguoyang, wenzhuo.lu,
konstantin.ananyev, Shahaf Shuler, Slava Ovsiienko, rmody,
shshaikh, maxime.coquelin, tiwei.bie, zhihong.wang, yongwang,
Thomas Monjalon, arybchenko, jingjing.wu, bernard.iremonger
Cc: dev
On 11/8/2019 10:10 AM, Matan Azrad wrote:
>
>
> From: Ferruh Yigit
>> On 11/8/2019 6:54 AM, Matan Azrad wrote:
>>> Hi
>>>
>>> From: Ferruh Yigit
>>>> On 11/7/2019 12:35 PM, Dekel Peled wrote:
>>>>> @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
>>>>>
>>>> RTE_ETHER_MAX_LEN;
>>>>> }
>>>>>
>>>>> + /*
>>>>> + * If LRO is enabled, check that the maximum aggregated packet
>>>>> + * size is supported by the configured device.
>>>>> + */
>>>>> + if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
>>>>> + ret = check_lro_pkt_size(
>>>>> + port_id, dev_conf-
>>>>> rxmode.max_lro_pkt_size,
>>>>> + dev_info.max_lro_pkt_size);
>>>>> + if (ret != 0)
>>>>> + goto rollback;
>>>>> + }
>>>>> +
>>>>
>>>> This check forces applications that enable LRO to provide
>> 'max_lro_pkt_size'
>>>> config value.
>>>
>>> Yes.(we can break an API, we noticed it)
>>
>> I am not talking about API/ABI breakage, that part is OK.
>> With this check, if the application requested LRO offload but not provided
>> 'max_lro_pkt_size' value, device configuration will fail.
>>
> Yes
>> Can there be a case application is good with whatever the PMD can support
>> as max?
> Yes can be - you know, we can do everything we want but it is better to be consistent:
> Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max lro pkt len should be mandatory for LRO offload.
>
> So your question is actually why both, non-lro packets and LRO packets max size are mandatory...
>
>
> I think it should be important values for net applications management.
> Also good for mbuf size managements.
>
>>>
>>>> - Why it is mandatory now, how it was working before if it is
>>>> mandatory value?
>>>
>>> It is the same as max_rx_pkt_len which is mandatory for jumbo frame
>> offload.
>>> So now, when the user configures a LRO offload he must to set max lro pkt
>> len.
>>> We don't want to confuse the user here with the max rx pkt len
>> configurations and behaviors, they should be with same logic.
>>>
>>> This parameter defines well the LRO behavior.
>>> Before this, each PMD took its own interpretation to what should be the
>> maximum size for LRO aggregated packets.
>>> Now, the user must say what is his intension, and the ethdev can limit it
>> according to the device capability.
>>> By this way, also, the PMD can organize\optimize its data-path more.
>>> Also, the application can create different mempools for LRO queues to
>> allow bigger packet receiving for LRO traffic.
>>>
>>>> - What happens if PMD doesn't provide 'max_lro_pkt_size', so it is '0'?
>>> Yes, you can see the feature description Dekel added.
>>> This patch also updates all the PMDs support an LRO for non-0 value.
>>
>> Of course I can see the updates Matan, my point is "What happens if PMD
>> doesn't provide 'max_lro_pkt_size'",
>> 1) There is no check for it right, so it is acceptable?
>
> There is check.
> If the capability is 0, any non-zero configuration will fail.
>
>> 2) Are we making this filed mandatory to provide for PMDs, it is easy to make
>> new fields mandatory for PMDs but is this really necessary?
>
> Yes, for consistence.
>
>>>
>>> as same as max rx pkt len, no?
>>>
>>>> - What do you think setting 'max_lro_pkt_size' config value to what
>>>> PMD provided if application doesn't provide it?
>>> Same answers as above.
>>>
>>
>> If application doesn't care the value, as it has been till now, and not provided
>> explicit 'max_lro_pkt_size', why not ethdev level use the value provided by
>> PMD instead of failing?
>
> Again, same question we can ask on max rx pkt len.
>
> Looks like the packet size is very important value which should be set by the application.
>
> Previous applications have no option to configure it, so they haven't configure it, (probably cover it somehow) I think it is our miss to supply this info.
>
> Let's do it in same way as we do max rx pkt len (as this patch main idea).
> Later, we can change both to other meaning.
>
I think it is not a good reason to introduce a new mandatory config option for
application because of 'max_rx_pkt_len' does it.
Will it work, if:
- If application doesn't provide this value, use the PMD max
- If both application and PMD doesn't provide this value, fail on configure()?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: reserve space in main structs for extension
2019-11-08 9:57 0% ` Ferruh Yigit
@ 2019-11-08 10:52 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2019-11-08 10:52 UTC (permalink / raw)
To: Ferruh Yigit, Thomas Monjalon; +Cc: dev
On 11/8/19 12:57 PM, Ferruh Yigit wrote:
> On 11/7/2019 10:15 PM, Thomas Monjalon wrote:
>> The struct rte_eth_dev and rte_eth_dev_data are supposed
>> to be used internally only, but there is a chance that
>> increasing their size would break ABI for some applications.
>> In order to allow smooth addition of features without breaking
>> ABI compatibility, some space is reserved.
>>
>> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
2019-11-08 9:19 3% ` Ferruh Yigit
@ 2019-11-08 10:10 0% ` Matan Azrad
2019-11-08 11:37 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Matan Azrad @ 2019-11-08 10:10 UTC (permalink / raw)
To: Ferruh Yigit, Dekel Peled, john.mcnamara, marko.kovacevic,
nhorman, ajit.khaparde, somnath.kotur, anatoly.burakov,
xuanziyang2, cloud.wangxiaoyun, zhouguoyang, wenzhuo.lu,
konstantin.ananyev, Shahaf Shuler, Slava Ovsiienko, rmody,
shshaikh, maxime.coquelin, tiwei.bie, zhihong.wang, yongwang,
Thomas Monjalon, arybchenko, jingjing.wu, bernard.iremonger
Cc: dev
From: Ferruh Yigit
> On 11/8/2019 6:54 AM, Matan Azrad wrote:
> > Hi
> >
> > From: Ferruh Yigit
> >> On 11/7/2019 12:35 PM, Dekel Peled wrote:
> >>> @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
> >>>
> >> RTE_ETHER_MAX_LEN;
> >>> }
> >>>
> >>> + /*
> >>> + * If LRO is enabled, check that the maximum aggregated packet
> >>> + * size is supported by the configured device.
> >>> + */
> >>> + if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
> >>> + ret = check_lro_pkt_size(
> >>> + port_id, dev_conf-
> >>> rxmode.max_lro_pkt_size,
> >>> + dev_info.max_lro_pkt_size);
> >>> + if (ret != 0)
> >>> + goto rollback;
> >>> + }
> >>> +
> >>
> >> This check forces applications that enable LRO to provide
> 'max_lro_pkt_size'
> >> config value.
> >
> > Yes.(we can break an API, we noticed it)
>
> I am not talking about API/ABI breakage, that part is OK.
> With this check, if the application requested LRO offload but not provided
> 'max_lro_pkt_size' value, device configuration will fail.
>
Yes
> Can there be a case application is good with whatever the PMD can support
> as max?
Yes can be - you know, we can do everything we want but it is better to be consistent:
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max lro pkt len should be mandatory for LRO offload.
So your question is actually why both, non-lro packets and LRO packets max size are mandatory...
I think it should be important values for net applications management.
Also good for mbuf size managements.
> >
> >> - Why it is mandatory now, how it was working before if it is
> >> mandatory value?
> >
> > It is the same as max_rx_pkt_len which is mandatory for jumbo frame
> offload.
> > So now, when the user configures a LRO offload he must to set max lro pkt
> len.
> > We don't want to confuse the user here with the max rx pkt len
> configurations and behaviors, they should be with same logic.
> >
> > This parameter defines well the LRO behavior.
> > Before this, each PMD took its own interpretation to what should be the
> maximum size for LRO aggregated packets.
> > Now, the user must say what is his intension, and the ethdev can limit it
> according to the device capability.
> > By this way, also, the PMD can organize\optimize its data-path more.
> > Also, the application can create different mempools for LRO queues to
> allow bigger packet receiving for LRO traffic.
> >
> >> - What happens if PMD doesn't provide 'max_lro_pkt_size', so it is '0'?
> > Yes, you can see the feature description Dekel added.
> > This patch also updates all the PMDs support an LRO for non-0 value.
>
> Of course I can see the updates Matan, my point is "What happens if PMD
> doesn't provide 'max_lro_pkt_size'",
> 1) There is no check for it right, so it is acceptable?
There is check.
If the capability is 0, any non-zero configuration will fail.
> 2) Are we making this filed mandatory to provide for PMDs, it is easy to make
> new fields mandatory for PMDs but is this really necessary?
Yes, for consistence.
> >
> > as same as max rx pkt len, no?
> >
> >> - What do you think setting 'max_lro_pkt_size' config value to what
> >> PMD provided if application doesn't provide it?
> > Same answers as above.
> >
>
> If application doesn't care the value, as it has been till now, and not provided
> explicit 'max_lro_pkt_size', why not ethdev level use the value provided by
> PMD instead of failing?
Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by the application.
Previous applications have no option to configure it, so they haven't configure it, (probably cover it somehow) I think it is our miss to supply this info.
Let's do it in same way as we do max rx pkt len (as this patch main idea).
Later, we can change both to other meaning.
Matan
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: reserve space in main structs for extension
2019-11-07 22:15 4% [dpdk-dev] [PATCH] ethdev: reserve space in main structs for extension Thomas Monjalon
2019-11-08 3:41 0% ` Stephen Hemminger
@ 2019-11-08 9:57 0% ` Ferruh Yigit
2019-11-08 10:52 0% ` Andrew Rybchenko
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-11-08 9:57 UTC (permalink / raw)
To: Thomas Monjalon, Andrew Rybchenko; +Cc: dev
On 11/7/2019 10:15 PM, Thomas Monjalon wrote:
> The struct rte_eth_dev and rte_eth_dev_data are supposed
> to be used internally only, but there is a chance that
> increasing their size would break ABI for some applications.
> In order to allow smooth addition of features without breaking
> ABI compatibility, some space is reserved.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: reserve space in main structs for extension
2019-11-08 3:41 0% ` Stephen Hemminger
@ 2019-11-08 9:40 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-11-08 9:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Ferruh Yigit, Andrew Rybchenko, dev
08/11/2019 04:41, Stephen Hemminger:
> On Thu, 7 Nov 2019 23:15:24 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > The struct rte_eth_dev and rte_eth_dev_data are supposed
> > to be used internally only, but there is a chance that
> > increasing their size would break ABI for some applications.
> > In order to allow smooth addition of features without breaking
> > ABI compatibility, some space is reserved.
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > ---
> > @@ -764,6 +767,9 @@ struct rte_eth_dev_data {
> > +
> > + uint64_t reserved_64s[4]; /**< Reserved for future fields */
> > + void *reserved_ptrs[4]; /**< Reserved for future fields */
> > } __rte_cache_aligned;
>
> Void * is 32 bits on 32 bit architectures is that helpful or not?
That's why I reserved separately uint and pointers.
If we need to add a pointer, we decrease the size of the pointer array
to keep the same struct size on all archs.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
@ 2019-11-08 9:19 3% ` Ferruh Yigit
2019-11-08 10:10 0% ` Matan Azrad
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-11-08 9:19 UTC (permalink / raw)
To: Matan Azrad, Dekel Peled, john.mcnamara, marko.kovacevic,
nhorman, ajit.khaparde, somnath.kotur, anatoly.burakov,
xuanziyang2, cloud.wangxiaoyun, zhouguoyang, wenzhuo.lu,
konstantin.ananyev, Shahaf Shuler, Slava Ovsiienko, rmody,
shshaikh, maxime.coquelin, tiwei.bie, zhihong.wang, yongwang,
Thomas Monjalon, arybchenko, jingjing.wu, bernard.iremonger
Cc: dev
On 11/8/2019 6:54 AM, Matan Azrad wrote:
> Hi
>
> From: Ferruh Yigit
>> On 11/7/2019 12:35 PM, Dekel Peled wrote:
>>> @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
>>>
>> RTE_ETHER_MAX_LEN;
>>> }
>>>
>>> + /*
>>> + * If LRO is enabled, check that the maximum aggregated packet
>>> + * size is supported by the configured device.
>>> + */
>>> + if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
>>> + ret = check_lro_pkt_size(
>>> + port_id, dev_conf-
>>> rxmode.max_lro_pkt_size,
>>> + dev_info.max_lro_pkt_size);
>>> + if (ret != 0)
>>> + goto rollback;
>>> + }
>>> +
>>
>> This check forces applications that enable LRO to provide 'max_lro_pkt_size'
>> config value.
>
> Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK.
With this check, if the application requested LRO offload but not provided
'max_lro_pkt_size' value, device configuration will fail.
Can there be a case application is good with whatever the PMD can support as max?
>
>> - Why it is mandatory now, how it was working before if it is mandatory
>> value?
>
> It is the same as max_rx_pkt_len which is mandatory for jumbo frame offload.
> So now, when the user configures a LRO offload he must to set max lro pkt len.
> We don't want to confuse the user here with the max rx pkt len configurations and behaviors, they should be with same logic.
>
> This parameter defines well the LRO behavior.
> Before this, each PMD took its own interpretation to what should be the maximum size for LRO aggregated packets.
> Now, the user must say what is his intension, and the ethdev can limit it according to the device capability.
> By this way, also, the PMD can organize\optimize its data-path more.
> Also, the application can create different mempools for LRO queues to allow bigger packet receiving for LRO traffic.
>
>> - What happens if PMD doesn't provide 'max_lro_pkt_size', so it is '0'?
> Yes, you can see the feature description Dekel added.
> This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't
provide 'max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?
2) Are we making this filed mandatory to provide for PMDs, it is easy to make
new fields mandatory for PMDs but is this really necessary?
>
> as same as max rx pkt len, no?
>
>> - What do you think setting 'max_lro_pkt_size' config value to what PMD
>> provided if application doesn't provide it?
> Same answers as above.
>
If application doesn't care the value, as it has been till now, and not provided
explicit 'max_lro_pkt_size', why not ethdev level use the value provided by PMD
instead of failing?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ethdev: reserve space in main structs for extension
2019-11-07 22:15 4% [dpdk-dev] [PATCH] ethdev: reserve space in main structs for extension Thomas Monjalon
@ 2019-11-08 3:41 0% ` Stephen Hemminger
2019-11-08 9:40 0% ` Thomas Monjalon
2019-11-08 9:57 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-11-08 3:41 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Ferruh Yigit, Andrew Rybchenko, dev
On Thu, 7 Nov 2019 23:15:24 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:
> The struct rte_eth_dev and rte_eth_dev_data are supposed
> to be used internally only, but there is a chance that
> increasing their size would break ABI for some applications.
> In order to allow smooth addition of features without breaking
> ABI compatibility, some space is reserved.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> lib/librte_ethdev/rte_ethdev_core.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/lib/librte_ethdev/rte_ethdev_core.h b/lib/librte_ethdev/rte_ethdev_core.h
> index 392aea8e6b..ea8dd1d9ba 100644
> --- a/lib/librte_ethdev/rte_ethdev_core.h
> +++ b/lib/librte_ethdev/rte_ethdev_core.h
> @@ -698,6 +698,9 @@ struct rte_eth_dev {
> struct rte_eth_rxtx_callback *pre_tx_burst_cbs[RTE_MAX_QUEUES_PER_PORT];
> enum rte_eth_dev_state state; /**< Flag indicating the port state */
> void *security_ctx; /**< Context for security ops */
> +
> + uint64_t reserved_64s[4]; /**< Reserved for future fields */
> + void *reserved_ptrs[4]; /**< Reserved for future fields */
> } __rte_cache_aligned;
>
> struct rte_eth_dev_sriov;
> @@ -764,6 +767,9 @@ struct rte_eth_dev_data {
> /**< Switch-specific identifier.
> * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
> */
> +
> + uint64_t reserved_64s[4]; /**< Reserved for future fields */
> + void *reserved_ptrs[4]; /**< Reserved for future fields */
> } __rte_cache_aligned;
>
> /**
Void * is 32 bits on 32 bit architectures is that helpful or not?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 1/1] fbarray: fix duplicated fbarray file in secondary
2019-11-06 10:37 0% ` Burakov, Anatoly
@ 2019-11-08 3:19 3% ` Yasufumi Ogawa
0 siblings, 0 replies; 200+ results
From: Yasufumi Ogawa @ 2019-11-08 3:19 UTC (permalink / raw)
To: Burakov, Anatoly, Ananyev, Konstantin, David Marchand
Cc: dev, dpdk stable, Yasufumi Ogawa
>>> -----Original Message-----
>>> From: Burakov, Anatoly <anatoly.burakov@intel.com>
>>> Sent: Tuesday, November 5, 2019 11:31 AM
>>> To: David Marchand <david.marchand@redhat.com>; Yasufumi Ogawa
>>> <yasufum.o@gmail.com>
>>> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev
>>> <dev@dpdk.org>; dpdk stable <stable@dpdk.org>; Yasufumi Ogawa
>>> <ogawa.yasufumi@lab.ntt.co.jp>
>>> Subject: Re: [PATCH v6 1/1] fbarray: fix duplicated fbarray file in
>>> secondary
>>>
>>> On 05-Nov-19 10:13 AM, David Marchand wrote:
>>>> Hello Anatoly, Yasufumi,
>>>>
>>>> On Mon, Nov 4, 2019 at 11:20 AM Burakov, Anatoly
>>>> <anatoly.burakov@intel.com> wrote:
>>>>>
>>>>> On 01-Nov-19 9:04 AM, yasufum.o@gmail.com wrote:
>>>>>> From: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp>
>>>>>>
>>>>>> In secondary_msl_create_walk(), it creates a file for fbarrays
>>>>>> with its
>>>>>> PID for reserving unique name among secondary processes. However, it
>>>>>> does not work if several secondaries run as app containers because
>>>>>> each
>>>>>> of containerized secondary has PID 1, and failed to reserve unique
>>>>>> name
>>>>>> other than first one. To reserve unique name in each of
>>>>>> containers, use
>>>>>> hostname in addition to PID.
>>>>>>
>>>>>> Cc: stable@dpdk.org
>>>>
>>>> We can't backport this as is, see below.
>>>>
>>>>
>>>>>>
>>>>>> Signed-off-by: Yasufumi Ogawa <yasufum.o@gmail.com>
>>>>>> ---
>>>>>> lib/librte_eal/common/include/rte_fbarray.h | 2 +-
>>>>>> lib/librte_eal/linux/eal/eal_memalloc.c | 11 ++++++++---
>>>>>> 2 files changed, 9 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/lib/librte_eal/common/include/rte_fbarray.h
>>>>>> b/lib/librte_eal/common/include/rte_fbarray.h
>>>>>> index 6dccdbec9..5c2815093 100644
>>>>>> --- a/lib/librte_eal/common/include/rte_fbarray.h
>>>>>> +++ b/lib/librte_eal/common/include/rte_fbarray.h
>>>>>> @@ -39,7 +39,7 @@ extern "C" {
>>>>>> #include <rte_compat.h>
>>>>>> #include <rte_rwlock.h>
>>>>>>
>>>>>> -#define RTE_FBARRAY_NAME_LEN 64
>>>>>> +#define RTE_FBARRAY_NAME_LEN NAME_MAX
>>>>
>>>> The change on RTE_FBARRAY_NAME_LEN breaks the ABI, so we cannot
>>>> backport this as is.
>>>> For 19.11, we can allow this breakage, but we need an update of the
>>>> release notes.
OK. I wasn't careful for the ABI change. I think RTE_FBARRAY_NAME_LEN 64
is enough without using hostname as a part of fbarray. So I would like
to discard this change.
>>>>
>>>> Besides, what is the impact in terms of memory consumption?
>>>>
>>>>
>>>>>>
>>>>>> struct rte_fbarray {
>>>>>> char name[RTE_FBARRAY_NAME_LEN]; /**< name associated with
>>>>>> an array */
>>>>>> diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c
>>>>>> b/lib/librte_eal/linux/eal/eal_memalloc.c
>>>>>> index af6d0d023..24f0275c9 100644
>>>>>> --- a/lib/librte_eal/linux/eal/eal_memalloc.c
>>>>>> +++ b/lib/librte_eal/linux/eal/eal_memalloc.c
>>>>>> @@ -1365,6 +1365,7 @@ secondary_msl_create_walk(const struct
>>>>>> rte_memseg_list *msl,
>>>>>> struct rte_memseg_list *primary_msl, *local_msl;
>>>>>> char name[PATH_MAX];
>>>>>> int msl_idx, ret;
>>>>>> + char hostname[HOST_NAME_MAX] = { 0 };
>>>>>>
>>>>>> if (msl->external)
>>>>>> return 0;
>>>>>> @@ -1373,9 +1374,13 @@ secondary_msl_create_walk(const struct
>>>>>> rte_memseg_list *msl,
>>>>>> primary_msl = &mcfg->memsegs[msl_idx];
>>>>>> local_msl = &local_memsegs[msl_idx];
>>>>>>
>>>>>> - /* create distinct fbarrays for each secondary */
>>>>>> - snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%i",
>>>>>> - primary_msl->memseg_arr.name, getpid());
>>>>>> + /* Create distinct fbarrays for each secondary by using PID and
>>>>>> + * hostname. The reason why using hostname is because PID
>>>>>> could be
>>>>>> + * duplicated among secondaries if it is launched in a
>>>>>> container.
>>>>>> + */
>>>>>> + gethostname(hostname, HOST_NAME_MAX);
>>>>
>>>> Personal preference, s/HOST_NAME_MAX/sizeof(hostname)/.
>>>>
>>>>
>>>> hostname[] is HOST_NAME_MAX bytes long.
>>>> In the worst case, we can get a non NULL terminated hostname string.
>>>> "
>>>> gethostname() returns the null-terminated hostname in the
>>>> character array name, which has a length of len bytes. If the
>>>> null-terminated hostname is too large to fit, then the name is
>>>> truncated, and
>>>> no error is returned (but see NOTES below). POSIX.1-2001 says
>>>> that if such truncation occurs, then it is unspecified whether the
>>>> returned buffer includes a terminating null byte.
>>>> ...
>>>> NOTES
>>>> SUSv2 guarantees that "Host names are limited to 255 bytes".
>>>> POSIX.1-2001 guarantees that "Host names (not including the
>>>> terminating null byte) are limited to HOST_NAME_MAX bytes". On
>>>> Linux,
>>>> HOST_NAME_MAX is defined with the value 64, which has been the
>>>> limit since Linux 1.0 (earlier kernels imposed a limit of 8 bytes).
>>>> "
>>>>
>>>> How about making hostname[] HOST_NAME_MAX+1 bytes long?
>>>>
>>>>>> + snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%s_%d",
>>>>>> + primary_msl->memseg_arr.name, hostname,
>>>>>> (int)getpid());
>>>>>>
>>>>>> ret = rte_fbarray_init(&local_msl->memseg_arr, name,
>>>>>> primary_msl->memseg_arr.len,
>>>>>>
>>>>>
>>>>> I think the order should be reversed. Both containers and
>>>>> non-containers
>>>>> can have their hostname set, and RTE_FBARRAY_NAME_LEN is of fairly
>>>>> limited length, so if the hostname is long enough, the PID never gets
>>>>> into the name string, resulting in duplicates. It is better have
>>>>> pid first.
>>>>
>>>> Anatoly,
>>>>
>>>> On the principle, it seems better, yes.
>>>> Just the comment on RTE_FBARRAY_NAME_LEN indicates that you missed the
>>>> change at the top of the patch.
>>>> What do you think of this change?
>>>>
>>>
>>> Yes, i did miss that, apologies.
>>>
>>> I don't have a strong opinion on this change, however the above comment
>>> would still be true if we make fbarray size to be hostname_max + 1 - we
>>> still potentially get no space for a pid. So if we're going to have pid
>>> in there as well, it should be hostname_max + pid_max (5 digits?) +
>>> whatever underscores we have + null terminator, to ensure it fits under
>>> any and all circumstances.#
In "man 5 proc", it says the default value of pid_max is 32768, but can
be set up to 2^22 (=4194304) on 64-bit systems. So, I think it is safer
to consider pid_max is 7 digits.
I can find secondary's fbarray file named as
$ sudo ls /var/run/dpdk/rte/
...
fbarray_memseg-1048576k-0-0_24118
fbarray_memseg-1048576k-0-0_24191
fbarray_memseg-1048576k-0-0_24199
...
It consists of [prefix]-[hugepage size]-[numa node?]-[memchan?]_[PID]",
and size of the name before PID is totally 28 digits. If another
underscore and hostname are included in the name, the max size of
fbarray file name is
28 + 7(PID) + 1(underscore) + HOST_NAME_MAX+1(null terminator)
Considering 28 can be larger, how about using 32 as following?
+ int fbarray_sec_name_len = 32 + 7 + 1 + HOST_NAME_MAX + 1;
+ snprintf(name, fbarray_sec_name_len, "%s_%d_%s",
+ primary_msl->memseg_arr.name, getpid(), hostname);
>>
>> I think that at least on linux we have more than enough space here:
>>
>> $ find /usr/include -type f | xargs grep ' NAME_MAX' | grep define
>> /usr/include/linux/limits.h:#define NAME_MAX 255 /* #
>> chars in a file name */
>>
>> $ find /usr/include -type f | xargs grep ' HOST_NAME_MAX' | grep define
>> /usr/include/i386-linux-gnu/bits/local_lim.h:#define
>> HOST_NAME_MAX 64
>> /usr/include/x86_64-linux-gnu/bits/local_lim.h:#define
>> HOST_NAME_MAX 64
>>
>
> Okay, works for me :)
Thanks,
Yasufumi
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] ethdev: reserve space in main structs for extension
@ 2019-11-07 22:15 4% Thomas Monjalon
2019-11-08 3:41 0% ` Stephen Hemminger
2019-11-08 9:57 0% ` Ferruh Yigit
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-11-07 22:15 UTC (permalink / raw)
To: Ferruh Yigit, Andrew Rybchenko; +Cc: dev
The struct rte_eth_dev and rte_eth_dev_data are supposed
to be used internally only, but there is a chance that
increasing their size would break ABI for some applications.
In order to allow smooth addition of features without breaking
ABI compatibility, some space is reserved.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
lib/librte_ethdev/rte_ethdev_core.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/lib/librte_ethdev/rte_ethdev_core.h b/lib/librte_ethdev/rte_ethdev_core.h
index 392aea8e6b..ea8dd1d9ba 100644
--- a/lib/librte_ethdev/rte_ethdev_core.h
+++ b/lib/librte_ethdev/rte_ethdev_core.h
@@ -698,6 +698,9 @@ struct rte_eth_dev {
struct rte_eth_rxtx_callback *pre_tx_burst_cbs[RTE_MAX_QUEUES_PER_PORT];
enum rte_eth_dev_state state; /**< Flag indicating the port state */
void *security_ctx; /**< Context for security ops */
+
+ uint64_t reserved_64s[4]; /**< Reserved for future fields */
+ void *reserved_ptrs[4]; /**< Reserved for future fields */
} __rte_cache_aligned;
struct rte_eth_dev_sriov;
@@ -764,6 +767,9 @@ struct rte_eth_dev_data {
/**< Switch-specific identifier.
* Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
*/
+
+ uint64_t reserved_64s[4]; /**< Reserved for future fields */
+ void *reserved_ptrs[4]; /**< Reserved for future fields */
} __rte_cache_aligned;
/**
--
2.23.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps
2019-11-05 15:15 2% [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps Anatoly Burakov
` (2 preceding siblings ...)
2019-11-07 6:35 0% ` Rajesh Ravi
@ 2019-11-07 15:35 0% ` David Marchand
3 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-11-07 15:35 UTC (permalink / raw)
To: Anatoly Burakov
Cc: dev, Bruce Richardson, Rajesh Ravi, Ajit Khaparde,
Jonathan Richardson, Scott Branden, Vikram Mysore Prakash,
Srinath Mannam, Thomas Monjalon, dpdk stable
On Tue, Nov 5, 2019 at 4:15 PM Anatoly Burakov
<anatoly.burakov@intel.com> wrote:
>
> Currently, externally created heaps are supposed to be automatically
> mapped for VFIO DMA by EAL, however they only do so if, at the time of
> heap creation, VFIO is initialized and has at least one device
> available. If no devices are available at the time of heap creation (or
> if devices were available, but were since hot-unplugged, thus dropping
> all VFIO container mappings), then VFIO mapping code would have skipped
> over externally allocated heaps.
>
> The fix is two-fold. First, we allow externally allocated memory
> segments to be marked as "heap" segments. This allows us to distinguish
> between external memory segments that were created via heap API, from
> those that were created via rte_extmem_register() API.
>
> Then, we fix the VFIO code to only skip non-heap external segments.
> Also, since external heaps are not guaranteed to have valid IOVA
> addresses, we will skip those which have invalid IOVA addresses as well.
>
> Fixes: 0f526d674f8e ("malloc: separate creating memseg list and malloc heap")
Cc: stable@dpdk.org
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Tested-by: Rajesh Ravi <rajesh.ravi@broadcom.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
> ---
>
> Notes:
> This cannot be backported to older releases as it breaks the
> API and ABI. A separate fix is in the works for stable.
>
Applied, thanks.
--
David Marchand
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v7 02/12] build: annotate versioned symbols with __vsym macro
2019-11-07 15:03 3% ` [dpdk-dev] [PATCH v7 01/12] doc: fix description of versioning macros Andrzej Ostruszka
@ 2019-11-07 15:03 2% ` Andrzej Ostruszka
1 sibling, 0 replies; 200+ results
From: Andrzej Ostruszka @ 2019-11-07 15:03 UTC (permalink / raw)
To: dev, John McNamara, Marko Kovacevic, David Hunt, Neil Horman,
Bruce Richardson, Vladimir Medvedkin, Robert Sanford,
Erik Gabriel Carrillo
Cc: mattias.ronnblom, stephen
Every implementation of a particular version of given symbol needs to be
marked in its declaration as such (using `__vsym` macro). This patch
fixes this and also clarifies the documentation about that.
Signed-off-by: Andrzej Ostruszka <aostruszka@marvell.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
doc/guides/contributing/versioning.rst | 14 +++++++---
lib/librte_distributor/rte_distributor.c | 18 ++++++------
lib/librte_distributor/rte_distributor_v20.c | 18 ++++++------
.../common/include/rte_function_versioning.h | 7 +++++
lib/librte_lpm/rte_lpm.c | 28 +++++++++----------
lib/librte_lpm/rte_lpm6.c | 16 +++++------
lib/librte_timer/rte_timer.c | 20 ++++++-------
7 files changed, 67 insertions(+), 54 deletions(-)
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 8a38928c0..fcd2d50f1 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -225,6 +225,10 @@ The macros exported are:
fully qualified function ``p``, so that if a symbol becomes versioned, it
can still be mapped back to the public symbol name.
+* ``__vsym``: Annotation to be used in a declaration of the internal symbol
+ ``be`` to signal that it is being used as an implementation of a particular
+ version of symbol ``b``.
+
Examples of ABI Macro use
^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -345,8 +349,9 @@ with the public symbol name
.. code-block:: c
- struct rte_acl_ctx *
+ -struct rte_acl_ctx *
-rte_acl_create(const struct rte_acl_param *param)
+ +struct rte_acl_ctx * __vsym
+rte_acl_create_v20(const struct rte_acl_param *param)
{
size_t sz;
@@ -354,7 +359,8 @@ with the public symbol name
...
Note that the base name of the symbol was kept intact, as this is conducive to
-the macros used for versioning symbols. That is our next step, mapping this new
+the macros used for versioning symbols and we have annotated the function as an
+implementation of versioned symbol. That is our next step, mapping this new
symbol name to the initial symbol name at version node 2.0. Immediately after
the function, we add this line of code
@@ -374,7 +380,7 @@ name, with a different suffix, and implement it appropriately
.. code-block:: c
- struct rte_acl_ctx *
+ struct rte_acl_ctx * __vsym
rte_acl_create_v21(const struct rte_acl_param *param, int debug);
{
struct rte_acl_ctx *ctx = rte_acl_create_v20(param);
@@ -423,7 +429,7 @@ defined, we add this
.. code-block:: c
- struct rte_acl_ctx *
+ struct rte_acl_ctx * __vsym
rte_acl_create_v21(const struct rte_acl_param *param, int debug)
{
...
diff --git a/lib/librte_distributor/rte_distributor.c b/lib/librte_distributor/rte_distributor.c
index 7df97df92..2cc32ddba 100644
--- a/lib/librte_distributor/rte_distributor.c
+++ b/lib/librte_distributor/rte_distributor.c
@@ -32,7 +32,7 @@ EAL_REGISTER_TAILQ(rte_dist_burst_tailq)
/**** Burst Packet APIs called by workers ****/
-void
+void __vsym
rte_distributor_request_pkt_v1705(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **oldpkt,
unsigned int count)
@@ -89,7 +89,7 @@ MAP_STATIC_SYMBOL(void rte_distributor_request_pkt(struct rte_distributor *d,
unsigned int count),
rte_distributor_request_pkt_v1705);
-int
+int __vsym
rte_distributor_poll_pkt_v1705(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **pkts)
{
@@ -134,7 +134,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_poll_pkt(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **pkts),
rte_distributor_poll_pkt_v1705);
-int
+int __vsym
rte_distributor_get_pkt_v1705(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **pkts,
struct rte_mbuf **oldpkt, unsigned int return_count)
@@ -169,7 +169,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_get_pkt(struct rte_distributor *d,
struct rte_mbuf **oldpkt, unsigned int return_count),
rte_distributor_get_pkt_v1705);
-int
+int __vsym
rte_distributor_return_pkt_v1705(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **oldpkt, int num)
{
@@ -359,7 +359,7 @@ release(struct rte_distributor *d, unsigned int wkr)
/* process a set of packets to distribute them to workers */
-int
+int __vsym
rte_distributor_process_v1705(struct rte_distributor *d,
struct rte_mbuf **mbufs, unsigned int num_mbufs)
{
@@ -506,7 +506,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_process(struct rte_distributor *d,
rte_distributor_process_v1705);
/* return to the caller, packets returned from workers */
-int
+int __vsym
rte_distributor_returned_pkts_v1705(struct rte_distributor *d,
struct rte_mbuf **mbufs, unsigned int max_mbufs)
{
@@ -556,7 +556,7 @@ total_outstanding(const struct rte_distributor *d)
* Flush the distributor, so that there are no outstanding packets in flight or
* queued up.
*/
-int
+int __vsym
rte_distributor_flush_v1705(struct rte_distributor *d)
{
unsigned int flushed;
@@ -591,7 +591,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_flush(struct rte_distributor *d),
rte_distributor_flush_v1705);
/* clears the internal returns array in the distributor */
-void
+void __vsym
rte_distributor_clear_returns_v1705(struct rte_distributor *d)
{
unsigned int wkr;
@@ -613,7 +613,7 @@ MAP_STATIC_SYMBOL(void rte_distributor_clear_returns(struct rte_distributor *d),
rte_distributor_clear_returns_v1705);
/* creates a distributor instance */
-struct rte_distributor *
+struct rte_distributor * __vsym
rte_distributor_create_v1705(const char *name,
unsigned int socket_id,
unsigned int num_workers,
diff --git a/lib/librte_distributor/rte_distributor_v20.c b/lib/librte_distributor/rte_distributor_v20.c
index db6c49258..7a6fddf55 100644
--- a/lib/librte_distributor/rte_distributor_v20.c
+++ b/lib/librte_distributor/rte_distributor_v20.c
@@ -27,7 +27,7 @@ EAL_REGISTER_TAILQ(rte_distributor_tailq)
/**** APIs called by workers ****/
-void
+void __vsym
rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
@@ -43,7 +43,7 @@ rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
}
VERSION_SYMBOL(rte_distributor_request_pkt, _v20, 2.0);
-struct rte_mbuf *
+struct rte_mbuf * __vsym
rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
unsigned worker_id)
{
@@ -59,7 +59,7 @@ rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
}
VERSION_SYMBOL(rte_distributor_poll_pkt, _v20, 2.0);
-struct rte_mbuf *
+struct rte_mbuf * __vsym
rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
@@ -71,7 +71,7 @@ rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
}
VERSION_SYMBOL(rte_distributor_get_pkt, _v20, 2.0);
-int
+int __vsym
rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
@@ -204,7 +204,7 @@ process_returns(struct rte_distributor_v20 *d)
}
/* process a set of packets to distribute them to workers */
-int
+int __vsym
rte_distributor_process_v20(struct rte_distributor_v20 *d,
struct rte_mbuf **mbufs, unsigned num_mbufs)
{
@@ -321,7 +321,7 @@ rte_distributor_process_v20(struct rte_distributor_v20 *d,
VERSION_SYMBOL(rte_distributor_process, _v20, 2.0);
/* return to the caller, packets returned from workers */
-int
+int __vsym
rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
struct rte_mbuf **mbufs, unsigned max_mbufs)
{
@@ -359,7 +359,7 @@ total_outstanding(const struct rte_distributor_v20 *d)
/* flush the distributor, so that there are no outstanding packets in flight or
* queued up. */
-int
+int __vsym
rte_distributor_flush_v20(struct rte_distributor_v20 *d)
{
const unsigned flushed = total_outstanding(d);
@@ -372,7 +372,7 @@ rte_distributor_flush_v20(struct rte_distributor_v20 *d)
VERSION_SYMBOL(rte_distributor_flush, _v20, 2.0);
/* clears the internal returns array in the distributor */
-void
+void __vsym
rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
{
d->returns.start = d->returns.count = 0;
@@ -383,7 +383,7 @@ rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
VERSION_SYMBOL(rte_distributor_clear_returns, _v20, 2.0);
/* creates a distributor instance */
-struct rte_distributor_v20 *
+struct rte_distributor_v20 * __vsym
rte_distributor_create_v20(const char *name,
unsigned socket_id,
unsigned num_workers)
diff --git a/lib/librte_eal/common/include/rte_function_versioning.h b/lib/librte_eal/common/include/rte_function_versioning.h
index eae619d60..c924351d5 100644
--- a/lib/librte_eal/common/include/rte_function_versioning.h
+++ b/lib/librte_eal/common/include/rte_function_versioning.h
@@ -52,6 +52,13 @@
* symbol <b> to the internal symbol <b><e>
*/
#define BIND_DEFAULT_SYMBOL(b, e, n) __asm__(".symver " RTE_STR(b) RTE_STR(e) ", " RTE_STR(b) "@@DPDK_" RTE_STR(n))
+
+/*
+ * __vsym
+ * Annotation to be used in declaration of the internal symbol <b><e> to signal
+ * that it is being used as an implementation of a particular version of symbol
+ * <b>.
+ */
#define __vsym __attribute__((used))
/*
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index c96395e26..106916dc8 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -90,7 +90,7 @@ depth_to_range(uint8_t depth)
/*
* Find an existing lpm table and return a pointer to it.
*/
-struct rte_lpm_v20 *
+struct rte_lpm_v20 * __vsym
rte_lpm_find_existing_v20(const char *name)
{
struct rte_lpm_v20 *l = NULL;
@@ -116,7 +116,7 @@ rte_lpm_find_existing_v20(const char *name)
}
VERSION_SYMBOL(rte_lpm_find_existing, _v20, 2.0);
-struct rte_lpm *
+struct rte_lpm * __vsym
rte_lpm_find_existing_v1604(const char *name)
{
struct rte_lpm *l = NULL;
@@ -147,7 +147,7 @@ MAP_STATIC_SYMBOL(struct rte_lpm *rte_lpm_find_existing(const char *name),
/*
* Allocates memory for LPM object
*/
-struct rte_lpm_v20 *
+struct rte_lpm_v20 * __vsym
rte_lpm_create_v20(const char *name, int socket_id, int max_rules,
__rte_unused int flags)
{
@@ -220,7 +220,7 @@ rte_lpm_create_v20(const char *name, int socket_id, int max_rules,
}
VERSION_SYMBOL(rte_lpm_create, _v20, 2.0);
-struct rte_lpm *
+struct rte_lpm * __vsym
rte_lpm_create_v1604(const char *name, int socket_id,
const struct rte_lpm_config *config)
{
@@ -329,7 +329,7 @@ MAP_STATIC_SYMBOL(
/*
* Deallocates memory for given LPM table.
*/
-void
+void __vsym
rte_lpm_free_v20(struct rte_lpm_v20 *lpm)
{
struct rte_lpm_list *lpm_list;
@@ -358,7 +358,7 @@ rte_lpm_free_v20(struct rte_lpm_v20 *lpm)
}
VERSION_SYMBOL(rte_lpm_free, _v20, 2.0);
-void
+void __vsym
rte_lpm_free_v1604(struct rte_lpm *lpm)
{
struct rte_lpm_list *lpm_list;
@@ -1177,7 +1177,7 @@ add_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
/*
* Add a route
*/
-int
+int __vsym
rte_lpm_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
uint8_t next_hop)
{
@@ -1218,7 +1218,7 @@ rte_lpm_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
}
VERSION_SYMBOL(rte_lpm_add, _v20, 2.0);
-int
+int __vsym
rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t next_hop)
{
@@ -1264,7 +1264,7 @@ MAP_STATIC_SYMBOL(int rte_lpm_add(struct rte_lpm *lpm, uint32_t ip,
/*
* Look for a rule in the high-level rules table
*/
-int
+int __vsym
rte_lpm_is_rule_present_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
uint8_t *next_hop)
{
@@ -1291,7 +1291,7 @@ uint8_t *next_hop)
}
VERSION_SYMBOL(rte_lpm_is_rule_present, _v20, 2.0);
-int
+int __vsym
rte_lpm_is_rule_present_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t *next_hop)
{
@@ -1844,7 +1844,7 @@ delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
/*
* Deletes a rule
*/
-int
+int __vsym
rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
{
int32_t rule_to_delete_index, sub_rule_index;
@@ -1898,7 +1898,7 @@ rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
}
VERSION_SYMBOL(rte_lpm_delete, _v20, 2.0);
-int
+int __vsym
rte_lpm_delete_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
{
int32_t rule_to_delete_index, sub_rule_index;
@@ -1957,7 +1957,7 @@ MAP_STATIC_SYMBOL(int rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip,
/*
* Delete all rules from the LPM table.
*/
-void
+void __vsym
rte_lpm_delete_all_v20(struct rte_lpm_v20 *lpm)
{
/* Zero rule information. */
@@ -1974,7 +1974,7 @@ rte_lpm_delete_all_v20(struct rte_lpm_v20 *lpm)
}
VERSION_SYMBOL(rte_lpm_delete_all, _v20, 2.0);
-void
+void __vsym
rte_lpm_delete_all_v1604(struct rte_lpm *lpm)
{
/* Zero rule information. */
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index e20f82460..0d161dc32 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -812,7 +812,7 @@ add_step(struct rte_lpm6 *lpm, struct rte_lpm6_tbl_entry *tbl,
/*
* Add a route
*/
-int
+int __vsym
rte_lpm6_add_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint8_t next_hop)
{
@@ -862,7 +862,7 @@ simulate_add(struct rte_lpm6 *lpm, const uint8_t *masked_ip, uint8_t depth)
return 0;
}
-int
+int __vsym
rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint32_t next_hop)
{
@@ -955,7 +955,7 @@ lookup_step(const struct rte_lpm6 *lpm, const struct rte_lpm6_tbl_entry *tbl,
/*
* Looks up an IP
*/
-int
+int __vsym
rte_lpm6_lookup_v20(const struct rte_lpm6 *lpm, uint8_t *ip, uint8_t *next_hop)
{
uint32_t next_hop32 = 0;
@@ -973,7 +973,7 @@ rte_lpm6_lookup_v20(const struct rte_lpm6 *lpm, uint8_t *ip, uint8_t *next_hop)
}
VERSION_SYMBOL(rte_lpm6_lookup, _v20, 2.0);
-int
+int __vsym
rte_lpm6_lookup_v1705(const struct rte_lpm6 *lpm, uint8_t *ip,
uint32_t *next_hop)
{
@@ -1008,7 +1008,7 @@ MAP_STATIC_SYMBOL(int rte_lpm6_lookup(const struct rte_lpm6 *lpm, uint8_t *ip,
/*
* Looks up a group of IP addresses
*/
-int
+int __vsym
rte_lpm6_lookup_bulk_func_v20(const struct rte_lpm6 *lpm,
uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
int16_t * next_hops, unsigned n)
@@ -1049,7 +1049,7 @@ rte_lpm6_lookup_bulk_func_v20(const struct rte_lpm6 *lpm,
}
VERSION_SYMBOL(rte_lpm6_lookup_bulk_func, _v20, 2.0);
-int
+int __vsym
rte_lpm6_lookup_bulk_func_v1705(const struct rte_lpm6 *lpm,
uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
int32_t *next_hops, unsigned int n)
@@ -1099,7 +1099,7 @@ MAP_STATIC_SYMBOL(int rte_lpm6_lookup_bulk_func(const struct rte_lpm6 *lpm,
/*
* Look for a rule in the high-level rules table
*/
-int
+int __vsym
rte_lpm6_is_rule_present_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint8_t *next_hop)
{
@@ -1119,7 +1119,7 @@ rte_lpm6_is_rule_present_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
}
VERSION_SYMBOL(rte_lpm6_is_rule_present, _v20, 2.0);
-int
+int __vsym
rte_lpm6_is_rule_present_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint32_t *next_hop)
{
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 3834c9473..381a9f43f 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -131,7 +131,7 @@ rte_timer_data_dealloc(uint32_t id)
return 0;
}
-void
+void __vsym
rte_timer_subsystem_init_v20(void)
{
unsigned lcore_id;
@@ -153,7 +153,7 @@ VERSION_SYMBOL(rte_timer_subsystem_init, _v20, 2.0);
* secondary processes should be empty, the zeroth entry can be shared by
* multiple processes.
*/
-int
+int __vsym
rte_timer_subsystem_init_v1905(void)
{
const struct rte_memzone *mz;
@@ -551,7 +551,7 @@ __rte_timer_reset(struct rte_timer *tim, uint64_t expire,
}
/* Reset and start the timer associated with the timer handle tim */
-int
+int __vsym
rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
enum rte_timer_type type, unsigned int tim_lcore,
rte_timer_cb_t fct, void *arg)
@@ -574,7 +574,7 @@ rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
}
VERSION_SYMBOL(rte_timer_reset, _v20, 2.0);
-int
+int __vsym
rte_timer_reset_v1905(struct rte_timer *tim, uint64_t ticks,
enum rte_timer_type type, unsigned int tim_lcore,
rte_timer_cb_t fct, void *arg)
@@ -657,14 +657,14 @@ __rte_timer_stop(struct rte_timer *tim, int local_is_locked,
}
/* Stop the timer associated with the timer handle tim */
-int
+int __vsym
rte_timer_stop_v20(struct rte_timer *tim)
{
return __rte_timer_stop(tim, 0, &default_timer_data);
}
VERSION_SYMBOL(rte_timer_stop, _v20, 2.0);
-int
+int __vsym
rte_timer_stop_v1905(struct rte_timer *tim)
{
return rte_timer_alt_stop(default_data_id, tim);
@@ -817,14 +817,14 @@ __rte_timer_manage(struct rte_timer_data *timer_data)
priv_timer[lcore_id].running_tim = NULL;
}
-void
+void __vsym
rte_timer_manage_v20(void)
{
__rte_timer_manage(&default_timer_data);
}
VERSION_SYMBOL(rte_timer_manage, _v20, 2.0);
-int
+int __vsym
rte_timer_manage_v1905(void)
{
struct rte_timer_data *timer_data;
@@ -1074,14 +1074,14 @@ __rte_timer_dump_stats(struct rte_timer_data *timer_data __rte_unused, FILE *f)
#endif
}
-void
+void __vsym
rte_timer_dump_stats_v20(FILE *f)
{
__rte_timer_dump_stats(&default_timer_data, f);
}
VERSION_SYMBOL(rte_timer_dump_stats, _v20, 2.0);
-int
+int __vsym
rte_timer_dump_stats_v1905(FILE *f)
{
return rte_timer_alt_dump_stats(default_data_id, f);
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v7 01/12] doc: fix description of versioning macros
@ 2019-11-07 15:03 3% ` Andrzej Ostruszka
2019-11-07 15:03 2% ` [dpdk-dev] [PATCH v7 02/12] build: annotate versioned symbols with __vsym macro Andrzej Ostruszka
1 sibling, 0 replies; 200+ results
From: Andrzej Ostruszka @ 2019-11-07 15:03 UTC (permalink / raw)
To: dev, John McNamara, Marko Kovacevic, Neil Horman
Cc: mattias.ronnblom, stephen
This patch fixes documentation of versioning macros so that they are
aligned with their implementation (no underscore is added by macros).
Signed-off-by: Andrzej Ostruszka <aostruszka@marvell.com>
Fixes: f1ef9794f9bd ("doc: add ABI guidelines")
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
doc/guides/contributing/versioning.rst | 4 ++--
lib/librte_eal/common/include/rte_function_versioning.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 64984c54e..8a38928c0 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -215,11 +215,11 @@ library so that older binaries need not be immediately recompiled.
The macros exported are:
* ``VERSION_SYMBOL(b, e, n)``: Creates a symbol version table entry binding
- versioned symbol ``b@DPDK_n`` to the internal function ``b_e``.
+ versioned symbol ``b@DPDK_n`` to the internal function ``be``.
* ``BIND_DEFAULT_SYMBOL(b, e, n)``: Creates a symbol version entry instructing
the linker to bind references to symbol ``b`` to the internal symbol
- ``b_e``.
+ ``be``.
* ``MAP_STATIC_SYMBOL(f, p)``: Declare the prototype ``f``, and map it to the
fully qualified function ``p``, so that if a symbol becomes versioned, it
diff --git a/lib/librte_eal/common/include/rte_function_versioning.h b/lib/librte_eal/common/include/rte_function_versioning.h
index 55e88ffae..eae619d60 100644
--- a/lib/librte_eal/common/include/rte_function_versioning.h
+++ b/lib/librte_eal/common/include/rte_function_versioning.h
@@ -42,14 +42,14 @@
/*
* VERSION_SYMBOL
* Creates a symbol version table entry binding symbol <b>@DPDK_<n> to the internal
- * function name <b>_<e>
+ * function name <b><e>
*/
#define VERSION_SYMBOL(b, e, n) __asm__(".symver " RTE_STR(b) RTE_STR(e) ", " RTE_STR(b) "@DPDK_" RTE_STR(n))
/*
* BIND_DEFAULT_SYMBOL
* Creates a symbol version entry instructing the linker to bind references to
- * symbol <b> to the internal symbol <b>_<e>
+ * symbol <b> to the internal symbol <b><e>
*/
#define BIND_DEFAULT_SYMBOL(b, e, n) __asm__(".symver " RTE_STR(b) RTE_STR(e) ", " RTE_STR(b) "@@DPDK_" RTE_STR(n))
#define __vsym __attribute__((used))
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] DPDK Release Status Meeting 7/11/2019
@ 2019-11-07 15:01 4% Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-11-07 15:01 UTC (permalink / raw)
To: dpdk-dev; +Cc: Thomas Monjalon
Minutes 7 November 2019
-----------------------
Agenda:
* Release Dates
* Subtrees
* OvS
* Conferences
* Opens
Participants:
* Debian/Microsoft
* Intel
* Mellanox
* NXP
* Red Hat
Release Dates
-------------
* v19.11 dates:
* RC1 is released on Sunday 27 October
* https://mails.dpdk.org/archives/announce/2019-October/000284.html
* RC2 Friday 8 November
* RC3 Friday 15 November
* Release Friday 22 November
* Proposed dates for 20.02 :
* Proposal/V1: Friday 6 December 2019
* Integration/Merge/RC1: Wednesday 15 January 2020
* Release: Friday 14 February 2020
Subtrees
--------
* main
* ABI/API patches, and tooling reviews are going on, more review welcome
* ABI policy:
v8: https://patches.dpdk.org/project/dpdk/list/?series=7255&state=*
* tooling
v6: https://patches.dpdk.org/project/dpdk/list/?series=7299&state=*
https://patches.dpdk.org/project/dpdk/list/?series=7004
* WFE under review
v12: https://patches.dpdk.org/project/dpdk/list/?series=7224&state=*
* LTO series in the queue
v6: https://patches.dpdk.org/project/dpdk/list/?series=7128&state=*
* vfio fixes may be pushed today
* new arm target patch under review
* mempool patch applied, KNI iova=va patch can go in after review
* Windows series can go in rc3
* next-net
* There are more ethdev patches that will be included in rc2
* configure SR-IOV VF from host patch will be deferred to next release
* Will merge as much for rc2 but remaining will be deferred to next rc
* Will make next-net ready for rc2 on Friday morning
* next-net-crypto
* Almost ready for rc2
* Future of the arm based crypto is not clear
* ipsec-secgw, set default to IPsec library mode deferred to next release
* Compression, waiting for new version
* A work-group established in techboard to decide on CPU crypto decisions
* next-net-eventdev
* pull request sent, planned to pull today
* next-net-virtio
* Sent pull request, ready for rc2
* next-net-intel
* ipn3ke PMD waiting for a new version
* LTS
* v18.11.3 is released
https://mails.dpdk.org/archives/announce/2019-October/000283.html
* Next week Kevin will start backporting patches for next release
OvS
---
* vhost patch to enable large buffer support merged, this will help enabling TSO
in OvS.
Conferences
-----------
* DPDK Summit North America, Mountain View CA, November 12-13
https://www.dpdk.org/event/dpdk-summit-na-mountain-view/
Opens
-----
* Governing board triggered some questions related DPDK community lab,
we can have more discussion soon related to utilizing the lab better
DPDK Release Status Meetings
============================
The DPDK Release Status Meeting is intended for DPDK Committers to discuss
the status of the master tree and sub-trees, and for project managers to
track progress or milestone dates.
The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just
send an email to "John McNamara <john.mcnamara@intel.com>" for the invite.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
@ 2019-11-07 12:35 3% ` Dekel Peled
1 sibling, 1 reply; 200+ results
From: Dekel Peled @ 2019-11-07 12:35 UTC (permalink / raw)
To: john.mcnamara, marko.kovacevic, nhorman, ajit.khaparde,
somnath.kotur, anatoly.burakov, xuanziyang2, cloud.wangxiaoyun,
zhouguoyang, wenzhuo.lu, konstantin.ananyev, matan, shahafs,
viacheslavo, rmody, shshaikh, maxime.coquelin, tiwei.bie,
zhihong.wang, yongwang, thomas, ferruh.yigit, arybchenko,
jingjing.wu, bernard.iremonger
Cc: dev
This patch implements [1], to support API for configuration and
validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11
are updated accordingly.
Various PMDs using LRO offload are updated, the new data members are
initialized to ensure they don't fail validation.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/
Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
---
doc/guides/nics/features.rst | 2 ++
doc/guides/rel_notes/deprecation.rst | 4 ---
doc/guides/rel_notes/release_19_11.rst | 8 ++++++
drivers/net/bnxt/bnxt_ethdev.c | 1 +
drivers/net/hinic/hinic_pmd_ethdev.c | 1 +
drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++
drivers/net/ixgbe/ixgbe_vf_representor.c | 1 +
drivers/net/mlx5/mlx5.h | 3 +++
drivers/net/mlx5/mlx5_ethdev.c | 1 +
drivers/net/mlx5/mlx5_rxq.c | 1 -
drivers/net/qede/qede_ethdev.c | 1 +
drivers/net/virtio/virtio_ethdev.c | 1 +
drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 +
lib/librte_ethdev/rte_ethdev.c | 44 ++++++++++++++++++++++++++++++++
lib/librte_ethdev/rte_ethdev.h | 4 +++
15 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 7a31cf7..2138ce3 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -193,10 +193,12 @@ LRO
Supports Large Receive Offload.
* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_TCP_LRO``.
+ ``dev_conf.rxmode.max_lro_pkt_size``.
* **[implements] datapath**: ``LRO functionality``.
* **[implements] rte_eth_dev_data**: ``lro``.
* **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``.
* **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``.
+* **[provides] rte_eth_dev_info**: ``max_lro_pkt_size``.
.. _nic_features_tso:
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index c10dc30..fdec33d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -87,10 +87,6 @@ Deprecation Notices
This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and
thereby improve Rx performance if application wishes do so.
-* ethdev: New 32-bit fields may be added for maximum LRO session size, in
- struct ``rte_eth_dev_info`` for the port capability and in struct
- ``rte_eth_rxmode`` for the port configuration.
-
* cryptodev: support for using IV with all sizes is added, J0 still can
be used but only when IV length in following structs ``rte_crypto_auth_xform``,
``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index 23182d1..b2b788c 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -406,6 +406,14 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
+* ethdev: Added 32-bit fields for maximum LRO aggregated packet size, in
+ struct ``rte_eth_dev_info`` for the port capability and in struct
+ ``rte_eth_rxmode`` for the port configuration.
+ Application should use the new field in struct ``rte_eth_rxmode`` to configure
+ the requested size.
+ PMD should use the new field in struct ``rte_eth_dev_info`` to report the
+ supported port capability.
+
Shared Library Versions
-----------------------
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index b9b055e..741b897 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -519,6 +519,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,
/* Fast path specifics */
dev_info->min_rx_bufsize = 1;
dev_info->max_rx_pktlen = BNXT_MAX_PKT_LEN;
+ dev_info->max_lro_pkt_size = BNXT_MAX_PKT_LEN;
dev_info->rx_offload_capa = BNXT_DEV_RX_OFFLOAD_SUPPORT;
if (bp->flags & BNXT_FLAG_PTP_SUPPORTED)
diff --git a/drivers/net/hinic/hinic_pmd_ethdev.c b/drivers/net/hinic/hinic_pmd_ethdev.c
index 9f37a40..b33b2cf 100644
--- a/drivers/net/hinic/hinic_pmd_ethdev.c
+++ b/drivers/net/hinic/hinic_pmd_ethdev.c
@@ -727,6 +727,7 @@ static void hinic_get_speed_capa(struct rte_eth_dev *dev, uint32_t *speed_capa)
info->max_tx_queues = nic_dev->nic_cap.max_sqs;
info->min_rx_bufsize = HINIC_MIN_RX_BUF_SIZE;
info->max_rx_pktlen = HINIC_MAX_JUMBO_FRAME_SIZE;
+ info->max_lro_pkt_size = HINIC_MAX_JUMBO_FRAME_SIZE;
info->max_mac_addrs = HINIC_MAX_UC_MAC_ADDRS;
info->min_mtu = HINIC_MIN_MTU_SIZE;
info->max_mtu = HINIC_MAX_MTU_SIZE;
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 30c0379..c391f51 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3814,6 +3814,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
}
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL register */
dev_info->max_rx_pktlen = 15872; /* includes CRC, cf MAXFRS register */
+ dev_info->max_lro_pkt_size = 15872;
dev_info->max_mac_addrs = hw->mac.num_rar_entries;
dev_info->max_hash_mac_addrs = IXGBE_VMDQ_NUM_UC_MAC;
dev_info->max_vfs = pci_dev->max_vfs;
@@ -3937,6 +3938,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues;
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL reg */
dev_info->max_rx_pktlen = 9728; /* includes CRC, cf MAXFRS reg */
+ dev_info->max_lro_pkt_size = 9728;
dev_info->max_mtu = dev_info->max_rx_pktlen - IXGBE_ETH_OVERHEAD;
dev_info->max_mac_addrs = hw->mac.num_rar_entries;
dev_info->max_hash_mac_addrs = IXGBE_VMDQ_NUM_UC_MAC;
diff --git a/drivers/net/ixgbe/ixgbe_vf_representor.c b/drivers/net/ixgbe/ixgbe_vf_representor.c
index dbbef29..28dfa3a 100644
--- a/drivers/net/ixgbe/ixgbe_vf_representor.c
+++ b/drivers/net/ixgbe/ixgbe_vf_representor.c
@@ -48,6 +48,7 @@
dev_info->min_rx_bufsize = 1024;
/**< Minimum size of RX buffer. */
dev_info->max_rx_pktlen = 9728;
+ dev_info->max_lro_pkt_size = 9728;
/**< Maximum configurable length of RX pkt. */
dev_info->max_rx_queues = IXGBE_VF_MAX_RX_QUEUES;
/**< Maximum number of RX queues. */
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index f644998..fdfc99b 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -203,6 +203,9 @@ struct mlx5_hca_attr {
#define MLX5_LRO_SUPPORTED(dev) \
(((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported)
+/* Maximal size of aggregated LRO packet. */
+#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)
+
/* LRO configurations structure. */
struct mlx5_lro_config {
uint32_t supported:1; /* Whether LRO is supported. */
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index c2bed2f..1443faa 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -606,6 +606,7 @@ struct ethtool_link_settings {
/* FIXME: we should ask the device for these values. */
info->min_rx_bufsize = 32;
info->max_rx_pktlen = 65536;
+ info->max_lro_pkt_size = MLX5_MAX_LRO_SIZE;
/*
* Since we need one CQ per QP, the limit is the minimum number
* between the two values.
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index 24d0eaa..9423e7b 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -1701,7 +1701,6 @@ struct mlx5_rxq_obj *
return 0;
}
-#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)
#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \
sizeof(struct rte_vlan_hdr) * 2 + \
sizeof(struct rte_ipv6_hdr)))
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 575982f..ccbb8a4 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev)
dev_info->min_rx_bufsize = (uint32_t)QEDE_MIN_RX_BUFF_SIZE;
dev_info->max_rx_pktlen = (uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
+ dev_info->max_lro_pkt_size = (uint32_t)0x7FFF;
dev_info->rx_desc_lim = qede_rx_desc_lim;
dev_info->tx_desc_lim = qede_tx_desc_lim;
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 646de99..fa33c45 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -2435,6 +2435,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)
RTE_MIN(hw->max_queue_pairs, VIRTIO_MAX_TX_QUEUES);
dev_info->min_rx_bufsize = VIRTIO_MIN_RX_BUFSIZE;
dev_info->max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN;
+ dev_info->max_lro_pkt_size = VIRTIO_MAX_RX_PKTLEN;
dev_info->max_mac_addrs = VIRTIO_MAX_MAC_ADDRS;
host_features = VTPCI_OPS(hw)->get_features(hw);
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index d1faeaa..d18e8bc 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -1161,6 +1161,7 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device *pci_dev)
dev_info->max_tx_queues = VMXNET3_MAX_TX_QUEUES;
dev_info->min_rx_bufsize = 1518 + RTE_PKTMBUF_HEADROOM;
dev_info->max_rx_pktlen = 16384; /* includes CRC, cf MAXFRS register */
+ dev_info->max_lro_pkt_size = 16384;
dev_info->speed_capa = ETH_LINK_SPEED_10G;
dev_info->max_mac_addrs = VMXNET3_MAX_MAC_ADDRS;
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 652c369..c642ba5 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -1136,6 +1136,26 @@ struct rte_eth_dev *
return name;
}
+static inline int
+check_lro_pkt_size(uint16_t port_id, uint32_t config_size,
+ uint32_t dev_info_size)
+{
+ int ret = 0;
+
+ if (config_size > dev_info_size) {
+ RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d max_lro_pkt_size %u "
+ "> max allowed value %u\n", port_id, config_size,
+ dev_info_size);
+ ret = -EINVAL;
+ } else if (config_size < RTE_ETHER_MIN_LEN) {
+ RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d max_lro_pkt_size %u "
+ "< min allowed value %u\n", port_id, config_size,
+ (unsigned int)RTE_ETHER_MIN_LEN);
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
int
rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
const struct rte_eth_conf *dev_conf)
@@ -1266,6 +1286,18 @@ struct rte_eth_dev *
RTE_ETHER_MAX_LEN;
}
+ /*
+ * If LRO is enabled, check that the maximum aggregated packet
+ * size is supported by the configured device.
+ */
+ if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
+ ret = check_lro_pkt_size(
+ port_id, dev_conf->rxmode.max_lro_pkt_size,
+ dev_info.max_lro_pkt_size);
+ if (ret != 0)
+ goto rollback;
+ }
+
/* Any requested offloading must be within its device capabilities */
if ((dev_conf->rxmode.offloads & dev_info.rx_offload_capa) !=
dev_conf->rxmode.offloads) {
@@ -1770,6 +1802,18 @@ struct rte_eth_dev *
return -EINVAL;
}
+ /*
+ * If LRO is enabled, check that the maximum aggregated packet
+ * size is supported by the configured device.
+ */
+ if (local_conf.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
+ int ret = check_lro_pkt_size(port_id,
+ dev->data->dev_conf.rxmode.max_lro_pkt_size,
+ dev_info.max_lro_pkt_size);
+ if (ret != 0)
+ return ret;
+ }
+
ret = (*dev->dev_ops->rx_queue_setup)(dev, rx_queue_id, nb_rx_desc,
socket_id, &local_conf, mp);
if (!ret) {
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 44d77b3..1b76df5 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -395,6 +395,8 @@ struct rte_eth_rxmode {
/** The multi-queue packet distribution mode to be used, e.g. RSS. */
enum rte_eth_rx_mq_mode mq_mode;
uint32_t max_rx_pkt_len; /**< Only used if JUMBO_FRAME enabled. */
+ /** Maximum allowed size of LRO aggregated packet. */
+ uint32_t max_lro_pkt_size;
uint16_t split_hdr_size; /**< hdr buf size (header_split enabled).*/
/**
* Per-port Rx offloads to be set using DEV_RX_OFFLOAD_* flags.
@@ -1218,6 +1220,8 @@ struct rte_eth_dev_info {
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
+ /** Maximum configurable size of LRO aggregated packet. */
+ uint32_t max_lro_pkt_size;
uint16_t max_rx_queues; /**< Maximum number of RX queues. */
uint16_t max_tx_queues; /**< Maximum number of TX queues. */
uint32_t max_mac_addrs; /**< Maximum number of MAC addresses. */
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 0/5] Some fixes for hinic PMD driver
2019-11-01 13:36 3% [dpdk-dev] [PATCH v5 0/5] Some fixes for hinic PMD driver Xiaoyun wang
@ 2019-11-07 9:29 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-11-07 9:29 UTC (permalink / raw)
To: Xiaoyun wang, dev
Cc: zhouguoyang, wulike1, luoxianjun, shahar.belkar, tanya.brokhman,
xuanziyang2
On 11/1/2019 1:36 PM, Xiaoyun wang wrote:
> This patch fixes code style check issue, offload info calculating problem
> for TSO offload. Replace mbuf alloc function with initialized, remove
> Flow Director feature from doc files and add Flow API feature to
> hinic.ini, Remove Free Tx mbuf on demand from hinic.ini.
>
> --
> v4->v5:
> - Fix code style check issue
> - Fix offload info calculating problem for TSO
> - Replace mbuf alloc function with initialized
> - Remove Flow Director feature from doc files
> - Remove Free Tx mbuf on demand from hinic.ini
>
> v3->v4:
> - Fix receive performance code review comments
> - Fix 32-bit build errs for mbox logs
> - Modify skb description as mbuf
>
> v2->v3:
> - Split hinic.ini and hinic.rst to related feature patches
> - Add min_mtu & max_mtu initialization for hinic_dev_infos_get
> - Fix fdir config patch with net/hinic/base
> - Split link patch into link and fw version getting 2 patches
> - Update pmd doc files to new next version
> - Add comments for cover letter patch
> - Add rxq & txq info getting interfaces
> - Fix load intrinsics for receiving packets
>
> v1->v2:
> - Fix RSS bugs for vxlan packets inner type
> - Add comments for new added func interface
> - Fix code review comments from patch v1
> - Fix code style problems
> - Remove ceq interfaces and definitions that not used
> - Fix aeq init bugs, firstly alloc aeq resource, then set aeq ctrl len
> - Fix bar map bugs for VF Page size larger than PF
> - Modify link state set, add enable or disable fiber in tx direction
> - Fix mbox and mgmt channel sync lock mechanism to reduce CPU usage
> - Fix FDIR bugs for VRRP packets
> - Fit ABI changes from dpdk lib
>
> v1:
> - Support SR-IOV function
> - Support FLOW API for packet filter
> - Support allmulticast mode
> - Support MTU set
> - Support unicast and multicast MAC set
> - Support setting link down and up
> - Support get firmware version
> - Support inner L3 checksum offload
> - Support LRO offload
> - Add hinic PMD doc files
>
> Xiaoyun wang (5):
> net/hinic/base: fix code style check issue
> net/hinic: fix offload info calculating problem for TSO
> net/hinic: optimize mbuf alloc function with initialized
> net/hinic: remove Flow Director feature from doc files
> net/hinic: remove Free Tx mbuf on demand from hinic.ini
Series applied to dpdk-next-net/master, thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps
2019-11-06 21:53 0% ` David Marchand
@ 2019-11-06 22:12 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-11-06 22:12 UTC (permalink / raw)
To: David Marchand, Anatoly Burakov
Cc: dev, Bruce Richardson, Rajesh Ravi, Ajit Khaparde,
Jonathan Richardson, Scott Branden, Vikram Mysore Prakash,
Srinath Mannam, Kevin Traynor
06/11/2019 22:53, David Marchand:
> On Tue, Nov 5, 2019 at 4:15 PM Anatoly Burakov
> <anatoly.burakov@intel.com> wrote:
> >
> > Currently, externally created heaps are supposed to be automatically
> > mapped for VFIO DMA by EAL, however they only do so if, at the time of
> > heap creation, VFIO is initialized and has at least one device
> > available. If no devices are available at the time of heap creation (or
> > if devices were available, but were since hot-unplugged, thus dropping
> > all VFIO container mappings), then VFIO mapping code would have skipped
> > over externally allocated heaps.
> >
> > The fix is two-fold. First, we allow externally allocated memory
> > segments to be marked as "heap" segments. This allows us to distinguish
> > between external memory segments that were created via heap API, from
> > those that were created via rte_extmem_register() API.
> >
> > Then, we fix the VFIO code to only skip non-heap external segments.
> > Also, since external heaps are not guaranteed to have valid IOVA
> > addresses, we will skip those which have invalid IOVA addresses as well.
> >
> > Fixes: 0f526d674f8e ("malloc: separate creating memseg list and malloc heap")
> >
> > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > ---
> >
> > Notes:
> > This cannot be backported to older releases as it breaks the
> > API and ABI. A separate fix is in the works for stable.
>
> I'd say we still have to Cc: stable, on the principle so that the
> stable maintainers know there is an issue on this commit.
Yes I agree. Cc: stable should be in this commit log.
Adding Cc: stable does not mean the patch can be backported without any effort :)
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps
2019-11-05 15:15 2% [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps Anatoly Burakov
2019-11-05 17:15 0% ` Burakov, Anatoly
@ 2019-11-06 21:53 0% ` David Marchand
2019-11-06 22:12 0% ` Thomas Monjalon
2019-11-07 6:35 0% ` Rajesh Ravi
2019-11-07 15:35 0% ` David Marchand
3 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-11-06 21:53 UTC (permalink / raw)
To: Anatoly Burakov
Cc: dev, Bruce Richardson, Rajesh Ravi, Ajit Khaparde,
Jonathan Richardson, Scott Branden, Vikram Mysore Prakash,
Srinath Mannam, Thomas Monjalon, Kevin Traynor
On Tue, Nov 5, 2019 at 4:15 PM Anatoly Burakov
<anatoly.burakov@intel.com> wrote:
>
> Currently, externally created heaps are supposed to be automatically
> mapped for VFIO DMA by EAL, however they only do so if, at the time of
> heap creation, VFIO is initialized and has at least one device
> available. If no devices are available at the time of heap creation (or
> if devices were available, but were since hot-unplugged, thus dropping
> all VFIO container mappings), then VFIO mapping code would have skipped
> over externally allocated heaps.
>
> The fix is two-fold. First, we allow externally allocated memory
> segments to be marked as "heap" segments. This allows us to distinguish
> between external memory segments that were created via heap API, from
> those that were created via rte_extmem_register() API.
>
> Then, we fix the VFIO code to only skip non-heap external segments.
> Also, since external heaps are not guaranteed to have valid IOVA
> addresses, we will skip those which have invalid IOVA addresses as well.
>
> Fixes: 0f526d674f8e ("malloc: separate creating memseg list and malloc heap")
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
>
> Notes:
> This cannot be backported to older releases as it breaks the
> API and ABI. A separate fix is in the works for stable.
I'd say we still have to Cc: stable, on the principle so that the
stable maintainers know there is an issue on this commit.
Kevin, wdyt?
>
> lib/librte_eal/common/include/rte_memory.h | 1 +
> lib/librte_eal/common/rte_malloc.c | 1 +
> lib/librte_eal/freebsd/eal/eal_memory.c | 1 +
> lib/librte_eal/linux/eal/eal_memory.c | 3 ++
> lib/librte_eal/linux/eal/eal_vfio.c | 46 +++++++++++++++++++---
> 5 files changed, 47 insertions(+), 5 deletions(-)
>
> diff --git a/lib/librte_eal/common/include/rte_memory.h b/lib/librte_eal/common/include/rte_memory.h
> index 38e00e382c..bf81a2faa8 100644
> --- a/lib/librte_eal/common/include/rte_memory.h
> +++ b/lib/librte_eal/common/include/rte_memory.h
> @@ -81,6 +81,7 @@ struct rte_memseg_list {
> volatile uint32_t version; /**< version number for multiprocess sync. */
> size_t len; /**< Length of memory area covered by this memseg list. */
> unsigned int external; /**< 1 if this list points to external memory */
> + unsigned int heap; /**< 1 if this list points to a heap */
> struct rte_fbarray memseg_arr;
> };
>
> diff --git a/lib/librte_eal/common/rte_malloc.c b/lib/librte_eal/common/rte_malloc.c
> index 044d3a9078..413e4aa004 100644
> --- a/lib/librte_eal/common/rte_malloc.c
> +++ b/lib/librte_eal/common/rte_malloc.c
> @@ -396,6 +396,7 @@ rte_malloc_heap_memory_add(const char *heap_name, void *va_addr, size_t len,
>
> rte_spinlock_lock(&heap->lock);
> ret = malloc_heap_add_external_memory(heap, msl);
> + msl->heap = 1; /* mark it as heap segment */
> rte_spinlock_unlock(&heap->lock);
>
> unlock:
> diff --git a/lib/librte_eal/freebsd/eal/eal_memory.c b/lib/librte_eal/freebsd/eal/eal_memory.c
> index 7fe3178898..a97d8f0f0c 100644
> --- a/lib/librte_eal/freebsd/eal/eal_memory.c
> +++ b/lib/librte_eal/freebsd/eal/eal_memory.c
> @@ -93,6 +93,7 @@ rte_eal_hugepage_init(void)
> msl->page_sz = page_sz;
> msl->len = internal_config.memory;
> msl->socket_id = 0;
> + msl->heap = 1;
>
> /* populate memsegs. each memseg is 1 page long */
> for (cur_seg = 0; cur_seg < n_segs; cur_seg++) {
> diff --git a/lib/librte_eal/linux/eal/eal_memory.c b/lib/librte_eal/linux/eal/eal_memory.c
> index accfd2e232..43e4ffc757 100644
> --- a/lib/librte_eal/linux/eal/eal_memory.c
> +++ b/lib/librte_eal/linux/eal/eal_memory.c
> @@ -831,6 +831,7 @@ alloc_memseg_list(struct rte_memseg_list *msl, uint64_t page_sz,
> msl->page_sz = page_sz;
> msl->socket_id = socket_id;
> msl->base_va = NULL;
> + msl->heap = 1; /* mark it as a heap segment */
>
> RTE_LOG(DEBUG, EAL, "Memseg list allocated: 0x%zxkB at socket %i\n",
> (size_t)page_sz >> 10, socket_id);
> @@ -1405,6 +1406,7 @@ eal_legacy_hugepage_init(void)
> msl->page_sz = page_sz;
> msl->socket_id = 0;
> msl->len = internal_config.memory;
> + msl->heap = 1;
>
> /* we're in single-file segments mode, so only the segment list
> * fd needs to be set up.
> @@ -1677,6 +1679,7 @@ eal_legacy_hugepage_init(void)
> mem_sz = msl->len;
> munmap(msl->base_va, mem_sz);
> msl->base_va = NULL;
> + msl->heap = 0;
>
> /* destroy backing fbarray */
> rte_fbarray_destroy(&msl->memseg_arr);
> diff --git a/lib/librte_eal/linux/eal/eal_vfio.c b/lib/librte_eal/linux/eal/eal_vfio.c
> index d9541b1220..d5a2bbea0d 100644
> --- a/lib/librte_eal/linux/eal/eal_vfio.c
> +++ b/lib/librte_eal/linux/eal/eal_vfio.c
> @@ -1250,7 +1250,16 @@ type1_map(const struct rte_memseg_list *msl, const struct rte_memseg *ms,
> {
> int *vfio_container_fd = arg;
>
> - if (msl->external)
> + /* skip external memory that isn't a heap */
> + if (msl->external && !msl->heap)
> + return 0;
> +
> + /* skip any segments with invalid IOVA addresses */
> + if (ms->iova == RTE_BAD_IOVA)
> + return 0;
> +
> + /* if IOVA mode is VA, we've already mapped the internal segments */
> + if (!msl->external && rte_eal_iova_mode() == RTE_IOVA_VA)
> return 0;
>
> return vfio_type1_dma_mem_map(*vfio_container_fd, ms->addr_64, ms->iova,
> @@ -1313,12 +1322,18 @@ vfio_type1_dma_mem_map(int vfio_container_fd, uint64_t vaddr, uint64_t iova,
> static int
> vfio_type1_dma_map(int vfio_container_fd)
> {
> + int ret;
> if (rte_eal_iova_mode() == RTE_IOVA_VA) {
> /* with IOVA as VA mode, we can get away with mapping contiguous
> * chunks rather than going page-by-page.
> */
> - return rte_memseg_contig_walk(type1_map_contig,
> + ret = rte_memseg_contig_walk(type1_map_contig,
We can move the ret variable declaration in this block.
I can do when applying.
> &vfio_container_fd);
> + if (ret)
> + return ret;
> + /* we have to continue the walk because we've skipped the
> + * external segments during the config walk.
> + */
> }
> return rte_memseg_walk(type1_map, &vfio_container_fd);
> }
> @@ -1410,7 +1425,15 @@ vfio_spapr_map_walk(const struct rte_memseg_list *msl,
> {
> struct spapr_remap_walk_param *param = arg;
>
> - if (msl->external || ms->addr_64 == param->addr_64)
> + /* skip external memory that isn't a heap */
> + if (msl->external && !msl->heap)
> + return 0;
> +
> + /* skip any segments with invalid IOVA addresses */
> + if (ms->iova == RTE_BAD_IOVA)
> + return 0;
> +
> + if (ms->addr_64 == param->addr_64)
> return 0;
>
> return vfio_spapr_dma_do_map(param->vfio_container_fd, ms->addr_64, ms->iova,
> @@ -1423,7 +1446,15 @@ vfio_spapr_unmap_walk(const struct rte_memseg_list *msl,
> {
> struct spapr_remap_walk_param *param = arg;
>
> - if (msl->external || ms->addr_64 == param->addr_64)
> + /* skip external memory that isn't a heap */
> + if (msl->external && !msl->heap)
> + return 0;
> +
> + /* skip any segments with invalid IOVA addresses */
> + if (ms->iova == RTE_BAD_IOVA)
> + return 0;
> +
> + if (ms->addr_64 == param->addr_64)
> return 0;
>
> return vfio_spapr_dma_do_map(param->vfio_container_fd, ms->addr_64, ms->iova,
> @@ -1443,7 +1474,12 @@ vfio_spapr_window_size_walk(const struct rte_memseg_list *msl,
> struct spapr_walk_param *param = arg;
> uint64_t max = ms->iova + ms->len;
>
> - if (msl->external)
> + /* skip external memory that isn't a heap */
> + if (msl->external && !msl->heap)
> + return 0;
> +
> + /* skip any segments with invalid IOVA addresses */
> + if (ms->iova == RTE_BAD_IOVA)
> return 0;
>
> /* do not iterate ms we haven't mapped yet */
> --
> 2.17.1
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions
2019-11-06 9:22 9% ` Ray Kinsella
@ 2019-11-06 21:07 10% ` Thomas Monjalon
2019-11-08 14:09 5% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-11-06 21:07 UTC (permalink / raw)
To: Ray Kinsella
Cc: dev, stephen, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
Hi,
Please find the techboard comments below.
06/11/2019 10:22, Ray Kinsella:
> On 06/11/2019 09:06, Thomas Monjalon wrote:
> > 06/11/2019 09:49, Ray Kinsella:
> >> On 06/11/2019 00:11, Thomas Monjalon wrote:
> >>> 05/11/2019 16:24, Ray Kinsella:
> >>>> +#. Major ABI versions are declared every **year** and are then supported for one
> >>>> + year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
> >>>
> >>> As discussed earlier, a major ABI version can be declared less often
> >>> than one year in the future.
> >>> An ABI is supported more than one year, because of the LTS branches.
> >>> That's why I propose to replace with this sentence:
> >>> "
> >>> Major ABI versions are declared regularly and are then supported for
> >>> at least one year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
> >>> "
> >>
> >> So look, this one was a decision of the technical board.
> >
> > The techboard didn't decide to change the ABI every year.
> > We decided to review the duration after the first year, with a plan to extend.
> >
> >> My position is still what was agreed was, "declared every year, and supported for one year".
> >> I like it, it's crystal clear what is the policy, until we change the policy.
> >
> > I think it gives a wrong message.
> >
> >> That said, I can make the change no problem, but I need some others to chime in to ok it.
> >> Perhaps at the head of the Techboard today?
> >
> > Yes I add it to the techboard meeting.
The techboard propose other rewords:
"supported" may be replaced with "compatibility is enforced"
"every year" may be replaced with "no more frequently than every year"
"declared" may be replaced with "could be declared"
I think you got the idea. Please adjust wording to something more accurate.
###
> >>>> +A major ABI version is declared every year, aligned with that year's LTS
> >>>> +release, e.g. v19.11. This ABI version is then supported for one year by all
> >>>> +subsequent releases within that time period, until the next LTS release, e.g.
> >>>> +v20.11.
> >>>
> >>> Let's reword like this:
> >>> "
> >>> A new major ABI version can be declared when a new LTS branch is started,
It has been suggested to replace "can" with "may".
> >>> e.g. ABI 19 for DPDK 19.11.0.
> >>> This major ABI version is then supported until the next one,
> >>> e.g. ABI 20 for DPDK 20.11.0.
> >>> All ABI changes must be detailed in the release notes.
> >>> "
My reword is wrong because ABI versions should be 20 and 21 respectively.
> >> This is more ambiguous, although what I said above stands.
> >
> > What you said is wrong because of 2 reasons:
> > - it is not always one year for an major ABI
>
> Well that is a point of disagreement.
The techboard agreed to remove "every year".
>
> > - it is always longer because of LTS branch
>
> Well I was pretty careful to qualify the ABI policy applies to releases over the year.
> To distinguish it from LTS branch.
As above, we may replace "ABI is supported" with
"ABI compatibility is enforced".
> >> If there is general agreement with changing this part of the policy, I am ok to make
> >> the change.
> >
> > Yes let's review with the techboard.
Please try to reflect techboard comments while keeping something understandable :)
###
> >>>> + ABI breakages due to changes such as reorganizing public
> >>>> + structure fields for aesthetic or readability purposes should be avoided.
> >>>
> >>> Why it should be avoided?
> >>> If the ABI is broken anyway, I don't see any reason to not break it more.
> >>
> >> This is text from the original ABI Policy - I think the general sentiment still stands.
> >> Just because you have an ABI Breakage window doesn't mean you should feel free to break
> >> the ABI. The 3 ACKs required from Technical Board member to change the ABI, are another
> >> reflection of this.
> >>
> >> As a general rule.
> >> Unnecessary changes should still be avoided, to reduce ABI churn between ABI versions.
> >
> > I agree we must avoid unnecessary API changes because it requires apps to adapt.
> > But if the change is only ABI, and we are in an ABI-change window,
> > I don't see any issue
The techboard agrees that the ABI changes are unlimited but API changes must be avoided.
It is suggested to replace "ABI" with "API". I think this reword is better:
"
API changes such as reorganizing public structure fields
for aesthetic or readability purposes should be avoided.
"
###
> >>>> +Libraries marked as ``experimental`` are entirely not considered part of an ABI
> >>>> +version, and may change without warning at any time. Experimental libraries
> >>>> +always have a major version of ``0`` to indicate they exist outside of
> >>>> +ABI Versioning, with the minor version incremented with each ABI change
> >>>> +to library.
> >>>
> >>> It means not all libraries will have the same ABI version.
> >>> It is contrary of "ABI version is managed at a project level",
> >>> and I don't see a real benefit of a different version number.
> >>
> >> There is a benefit, major version 0 is a very clear indication that
> >> the library exists outside of ABI management.
> >> A library isn't in the ABI, until it is in the ABI - an then it gets
> >> added to the major version number.
> >>
> >>> Anyway, some experimental functions can live inside a library
> >>> with a stable ABI version number
> >>
> >> True, but if an entire library is experimental - let's be crystal
> >> clear about that.
> >
> > I would like to see what others think.
The techboard decided to keep this policy: .0 for pure experimental libs.
^ permalink raw reply [relevance 10%]
* [dpdk-dev] [PATCH v6 09/10] build: change ABI version to 20.0
` (10 preceding siblings ...)
2019-11-06 16:54 3% ` [dpdk-dev] [PATCH v6 08/10] drivers/octeontx: add missing public symbol Anatoly Burakov
@ 2019-11-06 16:54 2% ` Anatoly Burakov
2019-11-06 16:54 23% ` [dpdk-dev] [PATCH v6 10/10] buildtools: add ABI versioning check script Anatoly Burakov
12 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-06 16:54 UTC (permalink / raw)
To: dev
Cc: Pawel Modrak, Nicolas Chautru, Hemant Agrawal, Sachin Saxena,
Rosen Xu, Stephen Hemminger, Anoob Joseph, Tomasz Duszynski,
Liron Himi, Jerin Jacob, Nithin Dabilpuram, Vamsi Attunuru,
Lee Daly, Fiona Trahe, Ashish Gupta, Sunila Sahu, Declan Doherty,
Pablo de Lara, Gagandeep Singh, Ravi Kumar, Akhil Goyal,
Michael Shamis, Nagadheeraj Rottela, Srikanth Jampala,
Ankur Dwivedi, Fan Zhang, Jay Zhou, Nipun Gupta,
Mattias Rönnblom, Pavan Nikhilesh, Liang Ma, Peter Mccarthy,
Harry van Haaren, Artem V. Andreev, Andrew Rybchenko,
Olivier Matz, Gage Eads, John W. Linville, Xiaolong Ye, Qi Zhang,
Shepard Siegel, Ed Czeck, John Miller, Igor Russkikh,
Pavel Belous, Allain Legacy, Matt Peters, Rasesh Mody,
Shahed Shaikh, Ajit Khaparde, Somnath Kotur, Chas Williams,
Rahul Lakkireddy, Wenzhuo Lu, Marcin Wojtas, Michal Krawczyk,
Guy Tzalik, Evgeny Schemeilin, Igor Chauskin, John Daley,
Hyong Youb Kim, Gaetan Rivet, Xiao Wang, Ziyang Xuan,
Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier), Min Hu (Connor),
Yisen Zhuang, Beilei Xing, Jingjing Wu, Qiming Yang,
Konstantin Ananyev, Ferruh Yigit, Shijith Thotton,
Srisivasubramanian Srinivasan, Jakub Grajciar, Matan Azrad,
Shahaf Shuler, Viacheslav Ovsiienko, Zyta Szpak,
K. Y. Srinivasan, Haiyang Zhang, Rastislav Cernay, Jan Remes,
Alejandro Lucero, Tetsuya Mukawa, Kiran Kumar K,
Bruce Richardson, Jasvinder Singh, Cristian Dumitrescu,
Keith Wiles, Maciej Czekaj, Maxime Coquelin, Tiwei Bie,
Zhihong Wang, Yong Wang, Tianfei zhang, Xiaoyun Li, Satha Rao,
Shreyansh Jain, David Hunt, Byron Marohn, Yipeng Wang,
Thomas Monjalon, Jiayu Hu, Sameh Gobriel, Reshma Pattan,
Vladimir Medvedkin, Robert Sanford, Erik Gabriel Carrillo,
john.mcnamara, ray.kinsella, david.marchand
From: Pawel Modrak <pawelx.modrak@intel.com>
Merge all vesions in linker version script files to DPDK_20.0.
This commit was generated by running the following command:
:~/DPDK$ buildtools/update-abi.sh 20.0
Signed-off-by: Pawel Modrak <pawelx.modrak@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
.../rte_pmd_bbdev_fpga_lte_fec_version.map | 8 +-
.../null/rte_pmd_bbdev_null_version.map | 2 +-
.../rte_pmd_bbdev_turbo_sw_version.map | 2 +-
drivers/bus/dpaa/rte_bus_dpaa_version.map | 113 +++---
drivers/bus/fslmc/rte_bus_fslmc_version.map | 154 ++++-----
drivers/bus/ifpga/rte_bus_ifpga_version.map | 14 +-
drivers/bus/pci/rte_bus_pci_version.map | 2 +-
drivers/bus/vdev/rte_bus_vdev_version.map | 12 +-
drivers/bus/vmbus/rte_bus_vmbus_version.map | 12 +-
drivers/common/cpt/rte_common_cpt_version.map | 9 +-
.../common/dpaax/rte_common_dpaax_version.map | 14 +-
.../common/mvep/rte_common_mvep_version.map | 6 +-
.../octeontx/rte_common_octeontx_version.map | 6 +-
.../rte_common_octeontx2_version.map | 16 +-
.../compress/isal/rte_pmd_isal_version.map | 2 +-
.../rte_pmd_octeontx_compress_version.map | 2 +-
drivers/compress/qat/rte_pmd_qat_version.map | 2 +-
.../compress/zlib/rte_pmd_zlib_version.map | 2 +-
.../aesni_gcm/rte_pmd_aesni_gcm_version.map | 2 +-
.../aesni_mb/rte_pmd_aesni_mb_version.map | 2 +-
.../crypto/armv8/rte_pmd_armv8_version.map | 2 +-
.../caam_jr/rte_pmd_caam_jr_version.map | 3 +-
drivers/crypto/ccp/rte_pmd_ccp_version.map | 3 +-
.../dpaa2_sec/rte_pmd_dpaa2_sec_version.map | 10 +-
.../dpaa_sec/rte_pmd_dpaa_sec_version.map | 10 +-
.../crypto/kasumi/rte_pmd_kasumi_version.map | 2 +-
.../crypto/mvsam/rte_pmd_mvsam_version.map | 2 +-
.../crypto/nitrox/rte_pmd_nitrox_version.map | 2 +-
.../null/rte_pmd_null_crypto_version.map | 2 +-
.../rte_pmd_octeontx_crypto_version.map | 3 +-
.../rte_pmd_octeontx2_crypto_version.map | 3 +-
.../openssl/rte_pmd_openssl_version.map | 2 +-
.../rte_pmd_crypto_scheduler_version.map | 19 +-
.../crypto/snow3g/rte_pmd_snow3g_version.map | 2 +-
.../virtio/rte_pmd_virtio_crypto_version.map | 2 +-
drivers/crypto/zuc/rte_pmd_zuc_version.map | 2 +-
.../event/dpaa/rte_pmd_dpaa_event_version.map | 3 +-
.../dpaa2/rte_pmd_dpaa2_event_version.map | 2 +-
.../event/dsw/rte_pmd_dsw_event_version.map | 2 +-
.../rte_pmd_octeontx_event_version.map | 2 +-
.../rte_pmd_octeontx2_event_version.map | 3 +-
.../event/opdl/rte_pmd_opdl_event_version.map | 2 +-
.../rte_pmd_skeleton_event_version.map | 3 +-
drivers/event/sw/rte_pmd_sw_event_version.map | 2 +-
.../bucket/rte_mempool_bucket_version.map | 3 +-
.../mempool/dpaa/rte_mempool_dpaa_version.map | 2 +-
.../dpaa2/rte_mempool_dpaa2_version.map | 12 +-
.../octeontx/rte_mempool_octeontx_version.map | 2 +-
.../rte_mempool_octeontx2_version.map | 4 +-
.../mempool/ring/rte_mempool_ring_version.map | 3 +-
.../stack/rte_mempool_stack_version.map | 3 +-
.../af_packet/rte_pmd_af_packet_version.map | 3 +-
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 2 +-
drivers/net/ark/rte_pmd_ark_version.map | 5 +-
.../net/atlantic/rte_pmd_atlantic_version.map | 6 -
drivers/net/avp/rte_pmd_avp_version.map | 2 +-
drivers/net/axgbe/rte_pmd_axgbe_version.map | 2 +-
drivers/net/bnx2x/rte_pmd_bnx2x_version.map | 3 +-
drivers/net/bnxt/rte_pmd_bnxt_version.map | 4 +-
drivers/net/bonding/rte_pmd_bond_version.map | 47 +--
drivers/net/cxgbe/rte_pmd_cxgbe_version.map | 3 +-
drivers/net/dpaa/rte_pmd_dpaa_version.map | 11 +-
drivers/net/dpaa2/rte_pmd_dpaa2_version.map | 12 +-
drivers/net/e1000/rte_pmd_e1000_version.map | 3 +-
drivers/net/ena/rte_pmd_ena_version.map | 3 +-
drivers/net/enetc/rte_pmd_enetc_version.map | 3 +-
drivers/net/enic/rte_pmd_enic_version.map | 3 +-
.../net/failsafe/rte_pmd_failsafe_version.map | 3 +-
drivers/net/fm10k/rte_pmd_fm10k_version.map | 3 +-
drivers/net/hinic/rte_pmd_hinic_version.map | 3 +-
drivers/net/hns3/rte_pmd_hns3_version.map | 4 +-
drivers/net/i40e/rte_pmd_i40e_version.map | 65 +---
drivers/net/iavf/rte_pmd_iavf_version.map | 3 +-
drivers/net/ice/rte_pmd_ice_version.map | 3 +-
drivers/net/ifc/rte_pmd_ifc_version.map | 3 +-
drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map | 3 +-
drivers/net/ixgbe/rte_pmd_ixgbe_version.map | 62 ++--
drivers/net/kni/rte_pmd_kni_version.map | 3 +-
.../net/liquidio/rte_pmd_liquidio_version.map | 3 +-
drivers/net/memif/rte_pmd_memif_version.map | 5 +-
drivers/net/mlx4/rte_pmd_mlx4_version.map | 3 +-
drivers/net/mlx5/rte_pmd_mlx5_version.map | 2 +-
drivers/net/mvneta/rte_pmd_mvneta_version.map | 2 +-
drivers/net/mvpp2/rte_pmd_mvpp2_version.map | 2 +-
drivers/net/netvsc/rte_pmd_netvsc_version.map | 4 +-
drivers/net/nfb/rte_pmd_nfb_version.map | 3 +-
drivers/net/nfp/rte_pmd_nfp_version.map | 2 +-
drivers/net/null/rte_pmd_null_version.map | 3 +-
.../net/octeontx/rte_pmd_octeontx_version.map | 10 +-
.../octeontx2/rte_pmd_octeontx2_version.map | 3 +-
drivers/net/pcap/rte_pmd_pcap_version.map | 3 +-
drivers/net/pfe/rte_pmd_pfe_version.map | 3 +-
drivers/net/qede/rte_pmd_qede_version.map | 3 +-
drivers/net/ring/rte_pmd_ring_version.map | 10 +-
drivers/net/sfc/rte_pmd_sfc_version.map | 3 +-
.../net/softnic/rte_pmd_softnic_version.map | 2 +-
.../net/szedata2/rte_pmd_szedata2_version.map | 2 +-
drivers/net/tap/rte_pmd_tap_version.map | 3 +-
.../net/thunderx/rte_pmd_thunderx_version.map | 3 +-
.../rte_pmd_vdev_netvsc_version.map | 3 +-
drivers/net/vhost/rte_pmd_vhost_version.map | 11 +-
drivers/net/virtio/rte_pmd_virtio_version.map | 3 +-
.../net/vmxnet3/rte_pmd_vmxnet3_version.map | 3 +-
.../rte_rawdev_dpaa2_cmdif_version.map | 3 +-
.../rte_rawdev_dpaa2_qdma_version.map | 4 +-
.../raw/ifpga/rte_rawdev_ifpga_version.map | 3 +-
drivers/raw/ioat/rte_rawdev_ioat_version.map | 3 +-
drivers/raw/ntb/rte_rawdev_ntb_version.map | 5 +-
.../rte_rawdev_octeontx2_dma_version.map | 3 +-
.../skeleton/rte_rawdev_skeleton_version.map | 3 +-
lib/librte_acl/rte_acl_version.map | 2 +-
.../rte_bitratestats_version.map | 2 +-
lib/librte_cfgfile/rte_cfgfile_version.map | 34 +-
lib/librte_cmdline/rte_cmdline_version.map | 10 +-
.../rte_cryptodev_version.map | 102 ++----
.../rte_distributor_version.map | 4 +-
lib/librte_eal/rte_eal_version.map | 324 ++++++------------
lib/librte_efd/rte_efd_version.map | 2 +-
lib/librte_ethdev/rte_ethdev_version.map | 160 +++------
lib/librte_eventdev/rte_eventdev_version.map | 130 +++----
lib/librte_gro/rte_gro_version.map | 2 +-
lib/librte_gso/rte_gso_version.map | 2 +-
lib/librte_hash/rte_hash_version.map | 43 +--
lib/librte_ip_frag/rte_ip_frag_version.map | 10 +-
lib/librte_jobstats/rte_jobstats_version.map | 10 +-
lib/librte_kni/rte_kni_version.map | 2 +-
lib/librte_kvargs/rte_kvargs_version.map | 4 +-
.../rte_latencystats_version.map | 2 +-
lib/librte_lpm/rte_lpm_version.map | 39 +--
lib/librte_mbuf/rte_mbuf_version.map | 49 +--
lib/librte_member/rte_member_version.map | 2 +-
lib/librte_mempool/rte_mempool_version.map | 44 +--
lib/librte_meter/rte_meter_version.map | 13 +-
lib/librte_metrics/rte_metrics_version.map | 2 +-
lib/librte_net/rte_net_version.map | 23 +-
lib/librte_pci/rte_pci_version.map | 2 +-
lib/librte_pdump/rte_pdump_version.map | 2 +-
lib/librte_pipeline/rte_pipeline_version.map | 36 +-
lib/librte_port/rte_port_version.map | 64 +---
lib/librte_power/rte_power_version.map | 24 +-
lib/librte_rawdev/rte_rawdev_version.map | 4 +-
lib/librte_reorder/rte_reorder_version.map | 8 +-
lib/librte_ring/rte_ring_version.map | 10 +-
lib/librte_sched/rte_sched_version.map | 14 +-
lib/librte_security/rte_security_version.map | 2 +-
lib/librte_table/rte_table_version.map | 2 +-
lib/librte_timer/rte_timer_version.map | 12 +-
lib/librte_vhost/rte_vhost_version.map | 52 +--
148 files changed, 695 insertions(+), 1438 deletions(-)
diff --git a/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map b/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
index f64b0f9c27..d9de5102db 100644
--- a/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
+++ b/drivers/baseband/fpga_lte_fec/rte_pmd_bbdev_fpga_lte_fec_version.map
@@ -1,10 +1,6 @@
-DPDK_19.08 {
- local: *;
-};
-
EXPERIMENTAL {
- global:
+ global:
- fpga_lte_fec_configure;
+ fpga_lte_fec_configure;
};
diff --git a/drivers/baseband/null/rte_pmd_bbdev_null_version.map b/drivers/baseband/null/rte_pmd_bbdev_null_version.map
index 58b94270d4..f9f17e4f6e 100644
--- a/drivers/baseband/null/rte_pmd_bbdev_null_version.map
+++ b/drivers/baseband/null/rte_pmd_bbdev_null_version.map
@@ -1,3 +1,3 @@
-DPDK_18.02 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/baseband/turbo_sw/rte_pmd_bbdev_turbo_sw_version.map b/drivers/baseband/turbo_sw/rte_pmd_bbdev_turbo_sw_version.map
index 58b94270d4..f9f17e4f6e 100644
--- a/drivers/baseband/turbo_sw/rte_pmd_bbdev_turbo_sw_version.map
+++ b/drivers/baseband/turbo_sw/rte_pmd_bbdev_turbo_sw_version.map
@@ -1,3 +1,3 @@
-DPDK_18.02 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/bus/dpaa/rte_bus_dpaa_version.map b/drivers/bus/dpaa/rte_bus_dpaa_version.map
index cf428a54dc..e6ca4361e0 100644
--- a/drivers/bus/dpaa/rte_bus_dpaa_version.map
+++ b/drivers/bus/dpaa/rte_bus_dpaa_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
bman_acquire;
@@ -7,123 +7,90 @@ DPDK_17.11 {
bman_new_pool;
bman_query_free_buffers;
bman_release;
+ bman_thread_irq;
+ dpaa_logtype_eventdev;
dpaa_logtype_mempool;
dpaa_logtype_pmd;
dpaa_netcfg;
+ dpaa_svr_family;
fman_ccsr_map_fd;
fman_dealloc_bufs_mask_hi;
fman_dealloc_bufs_mask_lo;
fman_if_add_mac_addr;
fman_if_clear_mac_addr;
fman_if_disable_rx;
- fman_if_enable_rx;
fman_if_discard_rx_errors;
- fman_if_get_fc_threshold;
+ fman_if_enable_rx;
fman_if_get_fc_quanta;
+ fman_if_get_fc_threshold;
fman_if_get_fdoff;
+ fman_if_get_sg_enable;
fman_if_loopback_disable;
fman_if_loopback_enable;
fman_if_promiscuous_disable;
fman_if_promiscuous_enable;
fman_if_reset_mcast_filter_table;
fman_if_set_bp;
- fman_if_set_fc_threshold;
fman_if_set_fc_quanta;
+ fman_if_set_fc_threshold;
fman_if_set_fdoff;
fman_if_set_ic_params;
fman_if_set_maxfrm;
fman_if_set_mcast_filter_table;
+ fman_if_set_sg;
fman_if_stats_get;
fman_if_stats_get_all;
fman_if_stats_reset;
fman_ip_rev;
+ fsl_qman_fq_portal_create;
netcfg_acquire;
netcfg_release;
- qm_channel_caam;
- qman_create_fq;
- qman_dequeue;
- qman_dqrr_consume;
- qman_enqueue;
- qman_enqueue_multi;
- qman_fq_fqid;
- qman_fq_state;
- qman_init_fq;
- qman_poll_dqrr;
- qman_query_fq_np;
- qman_set_vdq;
- qman_reserve_fqid_range;
- qman_volatile_dequeue;
- rte_dpaa_driver_register;
- rte_dpaa_driver_unregister;
- rte_dpaa_mem_ptov;
- rte_dpaa_portal_init;
-
- local: *;
-};
-
-DPDK_18.02 {
- global:
-
- dpaa_logtype_eventdev;
- dpaa_svr_family;
per_lcore_dpaa_io;
per_lcore_held_bufs;
+ qm_channel_caam;
qm_channel_pool1;
qman_alloc_cgrid_range;
qman_alloc_pool_range;
+ qman_clear_irq;
qman_create_cgr;
+ qman_create_fq;
qman_dca_index;
qman_delete_cgr;
+ qman_dequeue;
+ qman_dqrr_consume;
+ qman_enqueue;
+ qman_enqueue_multi;
qman_enqueue_multi_fq;
+ qman_fq_fqid;
+ qman_fq_portal_irqsource_add;
+ qman_fq_portal_irqsource_remove;
+ qman_fq_portal_thread_irq;
+ qman_fq_state;
+ qman_init_fq;
+ qman_irqsource_add;
+ qman_irqsource_remove;
qman_modify_cgr;
qman_oos_fq;
+ qman_poll_dqrr;
qman_portal_dequeue;
qman_portal_poll_rx;
qman_query_fq_frm_cnt;
+ qman_query_fq_np;
qman_release_cgrid_range;
+ qman_reserve_fqid_range;
qman_retire_fq;
+ qman_set_fq_lookup_table;
+ qman_set_vdq;
qman_static_dequeue_add;
- rte_dpaa_portal_fq_close;
- rte_dpaa_portal_fq_init;
-
-} DPDK_17.11;
-
-DPDK_18.08 {
- global:
-
- fman_if_get_sg_enable;
- fman_if_set_sg;
-
-} DPDK_18.02;
-
-DPDK_18.11 {
- global:
-
- bman_thread_irq;
- fman_if_get_sg_enable;
- fman_if_set_sg;
- qman_clear_irq;
-
- qman_irqsource_add;
- qman_irqsource_remove;
qman_thread_fd;
qman_thread_irq;
-
-} DPDK_18.08;
-
-DPDK_19.05 {
- global:
-
- qman_set_fq_lookup_table;
-
-} DPDK_18.11;
-
-DPDK_19.11 {
- global:
-
- fsl_qman_fq_portal_create;
- qman_fq_portal_irqsource_add;
- qman_fq_portal_irqsource_remove;
- qman_fq_portal_thread_irq;
-
-} DPDK_19.05;
+ qman_volatile_dequeue;
+ rte_dpaa_driver_register;
+ rte_dpaa_driver_unregister;
+ rte_dpaa_mem_ptov;
+ rte_dpaa_portal_fq_close;
+ rte_dpaa_portal_fq_init;
+ rte_dpaa_portal_init;
+
+ local: *;
+};
diff --git a/drivers/bus/fslmc/rte_bus_fslmc_version.map b/drivers/bus/fslmc/rte_bus_fslmc_version.map
index 4da787236b..fe45575046 100644
--- a/drivers/bus/fslmc/rte_bus_fslmc_version.map
+++ b/drivers/bus/fslmc/rte_bus_fslmc_version.map
@@ -1,32 +1,67 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
+ dpaa2_affine_qbman_ethrx_swp;
dpaa2_affine_qbman_swp;
dpaa2_alloc_dpbp_dev;
dpaa2_alloc_dq_storage;
+ dpaa2_dpbp_supported;
+ dpaa2_dqrr_size;
+ dpaa2_eqcr_size;
dpaa2_free_dpbp_dev;
dpaa2_free_dq_storage;
+ dpaa2_free_eq_descriptors;
+ dpaa2_get_qbman_swp;
+ dpaa2_io_portal;
+ dpaa2_svr_family;
+ dpaa2_virt_mode;
dpbp_disable;
dpbp_enable;
dpbp_get_attributes;
dpbp_get_num_free_bufs;
dpbp_open;
dpbp_reset;
+ dpci_get_opr;
+ dpci_set_opr;
+ dpci_set_rx_queue;
+ dpcon_get_attributes;
+ dpcon_open;
+ dpdmai_close;
+ dpdmai_disable;
+ dpdmai_enable;
+ dpdmai_get_attributes;
+ dpdmai_get_rx_queue;
+ dpdmai_get_tx_queue;
+ dpdmai_open;
+ dpdmai_set_rx_queue;
+ dpio_add_static_dequeue_channel;
dpio_close;
dpio_disable;
dpio_enable;
dpio_get_attributes;
dpio_open;
+ dpio_remove_static_dequeue_channel;
dpio_reset;
dpio_set_stashing_destination;
+ mc_get_soc_version;
+ mc_get_version;
mc_send_command;
per_lcore__dpaa2_io;
+ per_lcore_dpaa2_held_bufs;
qbman_check_command_complete;
+ qbman_check_new_result;
qbman_eq_desc_clear;
+ qbman_eq_desc_set_dca;
qbman_eq_desc_set_fq;
qbman_eq_desc_set_no_orp;
+ qbman_eq_desc_set_orp;
qbman_eq_desc_set_qd;
qbman_eq_desc_set_response;
+ qbman_eq_desc_set_token;
+ qbman_fq_query_state;
+ qbman_fq_state_frame_count;
+ qbman_get_dqrr_from_idx;
+ qbman_get_dqrr_idx;
qbman_pull_desc_clear;
qbman_pull_desc_set_fq;
qbman_pull_desc_set_numframes;
@@ -35,112 +70,43 @@ DPDK_17.05 {
qbman_release_desc_set_bpid;
qbman_result_DQ_fd;
qbman_result_DQ_flags;
- qbman_result_has_new_result;
- qbman_swp_acquire;
- qbman_swp_pull;
- qbman_swp_release;
- rte_fslmc_driver_register;
- rte_fslmc_driver_unregister;
- rte_fslmc_vfio_dmamap;
- rte_mcp_ptr_list;
-
- local: *;
-};
-
-DPDK_17.08 {
- global:
-
- dpaa2_io_portal;
- dpaa2_get_qbman_swp;
- dpci_set_rx_queue;
- dpcon_open;
- dpcon_get_attributes;
- dpio_add_static_dequeue_channel;
- dpio_remove_static_dequeue_channel;
- mc_get_soc_version;
- mc_get_version;
- qbman_check_new_result;
- qbman_eq_desc_set_dca;
- qbman_get_dqrr_from_idx;
- qbman_get_dqrr_idx;
qbman_result_DQ_fqd_ctx;
+ qbman_result_DQ_odpid;
+ qbman_result_DQ_seqnum;
qbman_result_SCN_state;
+ qbman_result_eqresp_fd;
+ qbman_result_eqresp_rc;
+ qbman_result_eqresp_rspid;
+ qbman_result_eqresp_set_rspid;
+ qbman_result_has_new_result;
+ qbman_swp_acquire;
qbman_swp_dqrr_consume;
+ qbman_swp_dqrr_idx_consume;
qbman_swp_dqrr_next;
qbman_swp_enqueue_multiple;
qbman_swp_enqueue_multiple_desc;
+ qbman_swp_enqueue_multiple_fd;
qbman_swp_interrupt_clear_status;
+ qbman_swp_prefetch_dqrr_next;
+ qbman_swp_pull;
qbman_swp_push_set;
+ qbman_swp_release;
rte_dpaa2_alloc_dpci_dev;
- rte_fslmc_object_register;
- rte_global_active_dqs_list;
-
-} DPDK_17.05;
-
-DPDK_17.11 {
- global:
-
- dpaa2_dpbp_supported;
rte_dpaa2_dev_type;
+ rte_dpaa2_free_dpci_dev;
rte_dpaa2_intr_disable;
rte_dpaa2_intr_enable;
-
-} DPDK_17.08;
-
-DPDK_18.02 {
- global:
-
- dpaa2_svr_family;
- dpaa2_virt_mode;
- per_lcore_dpaa2_held_bufs;
- qbman_fq_query_state;
- qbman_fq_state_frame_count;
- qbman_swp_dqrr_idx_consume;
- qbman_swp_prefetch_dqrr_next;
- rte_fslmc_get_device_count;
-
-} DPDK_17.11;
-
-DPDK_18.05 {
- global:
-
- dpaa2_affine_qbman_ethrx_swp;
- dpdmai_close;
- dpdmai_disable;
- dpdmai_enable;
- dpdmai_get_attributes;
- dpdmai_get_rx_queue;
- dpdmai_get_tx_queue;
- dpdmai_open;
- dpdmai_set_rx_queue;
- rte_dpaa2_free_dpci_dev;
rte_dpaa2_memsegs;
-
-} DPDK_18.02;
-
-DPDK_18.11 {
- global:
- dpaa2_dqrr_size;
- dpaa2_eqcr_size;
- dpci_get_opr;
- dpci_set_opr;
-
-} DPDK_18.05;
-
-DPDK_19.05 {
- global:
- dpaa2_free_eq_descriptors;
-
- qbman_eq_desc_set_orp;
- qbman_eq_desc_set_token;
- qbman_result_DQ_odpid;
- qbman_result_DQ_seqnum;
- qbman_result_eqresp_fd;
- qbman_result_eqresp_rc;
- qbman_result_eqresp_rspid;
- qbman_result_eqresp_set_rspid;
- qbman_swp_enqueue_multiple_fd;
-} DPDK_18.11;
+ rte_fslmc_driver_register;
+ rte_fslmc_driver_unregister;
+ rte_fslmc_get_device_count;
+ rte_fslmc_object_register;
+ rte_fslmc_vfio_dmamap;
+ rte_global_active_dqs_list;
+ rte_mcp_ptr_list;
+
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/drivers/bus/ifpga/rte_bus_ifpga_version.map b/drivers/bus/ifpga/rte_bus_ifpga_version.map
index 964c9a9c45..05b4a28c1b 100644
--- a/drivers/bus/ifpga/rte_bus_ifpga_version.map
+++ b/drivers/bus/ifpga/rte_bus_ifpga_version.map
@@ -1,17 +1,11 @@
-DPDK_18.05 {
+DPDK_20.0 {
global:
- rte_ifpga_get_integer32_arg;
- rte_ifpga_get_string_arg;
rte_ifpga_driver_register;
rte_ifpga_driver_unregister;
+ rte_ifpga_find_afu_by_name;
+ rte_ifpga_get_integer32_arg;
+ rte_ifpga_get_string_arg;
local: *;
};
-
-DPDK_19.05 {
- global:
-
- rte_ifpga_find_afu_by_name;
-
-} DPDK_18.05;
diff --git a/drivers/bus/pci/rte_bus_pci_version.map b/drivers/bus/pci/rte_bus_pci_version.map
index 27e9c4f101..012d817e14 100644
--- a/drivers/bus/pci/rte_bus_pci_version.map
+++ b/drivers/bus/pci/rte_bus_pci_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
rte_pci_dump;
diff --git a/drivers/bus/vdev/rte_bus_vdev_version.map b/drivers/bus/vdev/rte_bus_vdev_version.map
index 590cf9b437..5abb10ecb0 100644
--- a/drivers/bus/vdev/rte_bus_vdev_version.map
+++ b/drivers/bus/vdev/rte_bus_vdev_version.map
@@ -1,18 +1,12 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
+ rte_vdev_add_custom_scan;
rte_vdev_init;
rte_vdev_register;
+ rte_vdev_remove_custom_scan;
rte_vdev_uninit;
rte_vdev_unregister;
local: *;
};
-
-DPDK_18.02 {
- global:
-
- rte_vdev_add_custom_scan;
- rte_vdev_remove_custom_scan;
-
-} DPDK_17.11;
diff --git a/drivers/bus/vmbus/rte_bus_vmbus_version.map b/drivers/bus/vmbus/rte_bus_vmbus_version.map
index ae231ad329..cbaaebc06c 100644
--- a/drivers/bus/vmbus/rte_bus_vmbus_version.map
+++ b/drivers/bus/vmbus/rte_bus_vmbus_version.map
@@ -1,6 +1,4 @@
-/* SPDX-License-Identifier: BSD-3-Clause */
-
-DPDK_18.08 {
+DPDK_20.0 {
global:
rte_vmbus_chan_close;
@@ -20,6 +18,7 @@ DPDK_18.08 {
rte_vmbus_probe;
rte_vmbus_register;
rte_vmbus_scan;
+ rte_vmbus_set_latency;
rte_vmbus_sub_channel_index;
rte_vmbus_subchan_open;
rte_vmbus_unmap_device;
@@ -27,10 +26,3 @@ DPDK_18.08 {
local: *;
};
-
-DPDK_18.11 {
- global:
-
- rte_vmbus_set_latency;
-
-} DPDK_18.08;
diff --git a/drivers/common/cpt/rte_common_cpt_version.map b/drivers/common/cpt/rte_common_cpt_version.map
index 382ec4bd44..7f1929d58e 100644
--- a/drivers/common/cpt/rte_common_cpt_version.map
+++ b/drivers/common/cpt/rte_common_cpt_version.map
@@ -1,14 +1,9 @@
-DPDK_18.11 {
+DPDK_20.0 {
global:
+ cpt_pmd_ops_helper_asym_get_mlen;
cpt_pmd_ops_helper_get_mlen_direct_mode;
cpt_pmd_ops_helper_get_mlen_sg_mode;
-};
-
-DPDK_19.11 {
- global:
-
- cpt_pmd_ops_helper_asym_get_mlen;
local: *;
};
diff --git a/drivers/common/dpaax/rte_common_dpaax_version.map b/drivers/common/dpaax/rte_common_dpaax_version.map
index a7699ae4dd..f72eba761d 100644
--- a/drivers/common/dpaax/rte_common_dpaax_version.map
+++ b/drivers/common/dpaax/rte_common_dpaax_version.map
@@ -1,29 +1,23 @@
-DPDK_18.11 {
+DPDK_20.0 {
global:
- dpaax_iova_table_update;
dpaax_iova_table_depopulate;
dpaax_iova_table_dump;
dpaax_iova_table_p;
dpaax_iova_table_populate;
-
- local: *;
-};
-
-DPDK_19.11 {
- global:
+ dpaax_iova_table_update;
of_device_is_available;
of_device_is_compatible;
of_find_compatible_node;
of_find_node_by_phandle;
of_get_address;
of_get_mac_address;
+ of_get_next_child;
of_get_parent;
of_get_property;
of_init_path;
of_n_addr_cells;
of_translate_address;
- of_get_next_child;
local: *;
-} DPDK_18.11;
+};
diff --git a/drivers/common/mvep/rte_common_mvep_version.map b/drivers/common/mvep/rte_common_mvep_version.map
index c71722d79f..030928439d 100644
--- a/drivers/common/mvep/rte_common_mvep_version.map
+++ b/drivers/common/mvep/rte_common_mvep_version.map
@@ -1,6 +1,8 @@
-DPDK_18.11 {
+DPDK_20.0 {
global:
- rte_mvep_init;
rte_mvep_deinit;
+ rte_mvep_init;
+
+ local: *;
};
diff --git a/drivers/common/octeontx/rte_common_octeontx_version.map b/drivers/common/octeontx/rte_common_octeontx_version.map
index a9b3cff9bc..c15fb89112 100644
--- a/drivers/common/octeontx/rte_common_octeontx_version.map
+++ b/drivers/common/octeontx/rte_common_octeontx_version.map
@@ -1,8 +1,10 @@
-DPDK_18.05 {
+DPDK_20.0 {
global:
octeontx_logtype_mbox;
+ octeontx_mbox_send;
octeontx_mbox_set_ram_mbox_base;
octeontx_mbox_set_reg;
- octeontx_mbox_send;
+
+ local: *;
};
diff --git a/drivers/common/octeontx2/rte_common_octeontx2_version.map b/drivers/common/octeontx2/rte_common_octeontx2_version.map
index 4400120da0..adad21a2d6 100644
--- a/drivers/common/octeontx2/rte_common_octeontx2_version.map
+++ b/drivers/common/octeontx2/rte_common_octeontx2_version.map
@@ -1,39 +1,35 @@
-DPDK_19.08 {
+DPDK_20.0 {
global:
otx2_dev_active_vfs;
otx2_dev_fini;
otx2_dev_priv_init;
-
+ otx2_disable_irqs;
+ otx2_intra_dev_get_cfg;
otx2_logtype_base;
otx2_logtype_dpi;
otx2_logtype_mbox;
+ otx2_logtype_nix;
otx2_logtype_npa;
otx2_logtype_npc;
- otx2_logtype_nix;
otx2_logtype_sso;
- otx2_logtype_tm;
otx2_logtype_tim;
-
+ otx2_logtype_tm;
otx2_mbox_alloc_msg_rsp;
otx2_mbox_get_rsp;
otx2_mbox_get_rsp_tmo;
otx2_mbox_id2name;
otx2_mbox_msg_send;
otx2_mbox_wait_for_rsp;
-
- otx2_intra_dev_get_cfg;
otx2_npa_lf_active;
otx2_npa_lf_obj_get;
otx2_npa_lf_obj_ref;
otx2_npa_pf_func_get;
otx2_npa_set_defaults;
+ otx2_register_irq;
otx2_sso_pf_func_get;
otx2_sso_pf_func_set;
-
- otx2_disable_irqs;
otx2_unregister_irq;
- otx2_register_irq;
local: *;
};
diff --git a/drivers/compress/isal/rte_pmd_isal_version.map b/drivers/compress/isal/rte_pmd_isal_version.map
index de8e412ff1..f9f17e4f6e 100644
--- a/drivers/compress/isal/rte_pmd_isal_version.map
+++ b/drivers/compress/isal/rte_pmd_isal_version.map
@@ -1,3 +1,3 @@
-DPDK_18.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/compress/octeontx/rte_pmd_octeontx_compress_version.map b/drivers/compress/octeontx/rte_pmd_octeontx_compress_version.map
index ad6e191e49..f9f17e4f6e 100644
--- a/drivers/compress/octeontx/rte_pmd_octeontx_compress_version.map
+++ b/drivers/compress/octeontx/rte_pmd_octeontx_compress_version.map
@@ -1,3 +1,3 @@
-DPDK_18.08 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/compress/qat/rte_pmd_qat_version.map b/drivers/compress/qat/rte_pmd_qat_version.map
index ad6e191e49..f9f17e4f6e 100644
--- a/drivers/compress/qat/rte_pmd_qat_version.map
+++ b/drivers/compress/qat/rte_pmd_qat_version.map
@@ -1,3 +1,3 @@
-DPDK_18.08 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/compress/zlib/rte_pmd_zlib_version.map b/drivers/compress/zlib/rte_pmd_zlib_version.map
index ad6e191e49..f9f17e4f6e 100644
--- a/drivers/compress/zlib/rte_pmd_zlib_version.map
+++ b/drivers/compress/zlib/rte_pmd_zlib_version.map
@@ -1,3 +1,3 @@
-DPDK_18.08 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map b/drivers/crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map
index dc4d417b7b..f9f17e4f6e 100644
--- a/drivers/crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map
+++ b/drivers/crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map
@@ -1,3 +1,3 @@
-DPDK_16.04 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/aesni_mb/rte_pmd_aesni_mb_version.map b/drivers/crypto/aesni_mb/rte_pmd_aesni_mb_version.map
index ad607bbedd..f9f17e4f6e 100644
--- a/drivers/crypto/aesni_mb/rte_pmd_aesni_mb_version.map
+++ b/drivers/crypto/aesni_mb/rte_pmd_aesni_mb_version.map
@@ -1,3 +1,3 @@
-DPDK_2.2 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/armv8/rte_pmd_armv8_version.map b/drivers/crypto/armv8/rte_pmd_armv8_version.map
index 1f84b68a83..f9f17e4f6e 100644
--- a/drivers/crypto/armv8/rte_pmd_armv8_version.map
+++ b/drivers/crypto/armv8/rte_pmd_armv8_version.map
@@ -1,3 +1,3 @@
-DPDK_17.02 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/caam_jr/rte_pmd_caam_jr_version.map b/drivers/crypto/caam_jr/rte_pmd_caam_jr_version.map
index 521e51f411..f9f17e4f6e 100644
--- a/drivers/crypto/caam_jr/rte_pmd_caam_jr_version.map
+++ b/drivers/crypto/caam_jr/rte_pmd_caam_jr_version.map
@@ -1,4 +1,3 @@
-DPDK_18.11 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/ccp/rte_pmd_ccp_version.map b/drivers/crypto/ccp/rte_pmd_ccp_version.map
index 9b9ab1a4cf..f9f17e4f6e 100644
--- a/drivers/crypto/ccp/rte_pmd_ccp_version.map
+++ b/drivers/crypto/ccp/rte_pmd_ccp_version.map
@@ -1,4 +1,3 @@
-DPDK_18.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/dpaa2_sec/rte_pmd_dpaa2_sec_version.map b/drivers/crypto/dpaa2_sec/rte_pmd_dpaa2_sec_version.map
index 0bfb986d0b..5952d645fd 100644
--- a/drivers/crypto/dpaa2_sec/rte_pmd_dpaa2_sec_version.map
+++ b/drivers/crypto/dpaa2_sec/rte_pmd_dpaa2_sec_version.map
@@ -1,12 +1,8 @@
-DPDK_17.05 {
-
- local: *;
-};
-
-DPDK_18.11 {
+DPDK_20.0 {
global:
dpaa2_sec_eventq_attach;
dpaa2_sec_eventq_detach;
-} DPDK_17.05;
+ local: *;
+};
diff --git a/drivers/crypto/dpaa_sec/rte_pmd_dpaa_sec_version.map b/drivers/crypto/dpaa_sec/rte_pmd_dpaa_sec_version.map
index cc7f2162e0..8580fa13db 100644
--- a/drivers/crypto/dpaa_sec/rte_pmd_dpaa_sec_version.map
+++ b/drivers/crypto/dpaa_sec/rte_pmd_dpaa_sec_version.map
@@ -1,12 +1,8 @@
-DPDK_17.11 {
-
- local: *;
-};
-
-DPDK_19.11 {
+DPDK_20.0 {
global:
dpaa_sec_eventq_attach;
dpaa_sec_eventq_detach;
-} DPDK_17.11;
+ local: *;
+};
diff --git a/drivers/crypto/kasumi/rte_pmd_kasumi_version.map b/drivers/crypto/kasumi/rte_pmd_kasumi_version.map
index 8ffeca934e..f9f17e4f6e 100644
--- a/drivers/crypto/kasumi/rte_pmd_kasumi_version.map
+++ b/drivers/crypto/kasumi/rte_pmd_kasumi_version.map
@@ -1,3 +1,3 @@
-DPDK_16.07 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/mvsam/rte_pmd_mvsam_version.map b/drivers/crypto/mvsam/rte_pmd_mvsam_version.map
index a753031720..f9f17e4f6e 100644
--- a/drivers/crypto/mvsam/rte_pmd_mvsam_version.map
+++ b/drivers/crypto/mvsam/rte_pmd_mvsam_version.map
@@ -1,3 +1,3 @@
-DPDK_17.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/nitrox/rte_pmd_nitrox_version.map b/drivers/crypto/nitrox/rte_pmd_nitrox_version.map
index 406964d1fc..f9f17e4f6e 100644
--- a/drivers/crypto/nitrox/rte_pmd_nitrox_version.map
+++ b/drivers/crypto/nitrox/rte_pmd_nitrox_version.map
@@ -1,3 +1,3 @@
-DPDK_19.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/null/rte_pmd_null_crypto_version.map b/drivers/crypto/null/rte_pmd_null_crypto_version.map
index dc4d417b7b..f9f17e4f6e 100644
--- a/drivers/crypto/null/rte_pmd_null_crypto_version.map
+++ b/drivers/crypto/null/rte_pmd_null_crypto_version.map
@@ -1,3 +1,3 @@
-DPDK_16.04 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map b/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
index 521e51f411..f9f17e4f6e 100644
--- a/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
+++ b/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
@@ -1,4 +1,3 @@
-DPDK_18.11 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/octeontx2/rte_pmd_octeontx2_crypto_version.map b/drivers/crypto/octeontx2/rte_pmd_octeontx2_crypto_version.map
index b7b7c91683..f9f17e4f6e 100644
--- a/drivers/crypto/octeontx2/rte_pmd_octeontx2_crypto_version.map
+++ b/drivers/crypto/octeontx2/rte_pmd_octeontx2_crypto_version.map
@@ -1,4 +1,3 @@
-DPDK_19.11 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/openssl/rte_pmd_openssl_version.map b/drivers/crypto/openssl/rte_pmd_openssl_version.map
index cc5829e30b..f9f17e4f6e 100644
--- a/drivers/crypto/openssl/rte_pmd_openssl_version.map
+++ b/drivers/crypto/openssl/rte_pmd_openssl_version.map
@@ -1,3 +1,3 @@
-DPDK_16.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/scheduler/rte_pmd_crypto_scheduler_version.map b/drivers/crypto/scheduler/rte_pmd_crypto_scheduler_version.map
index 5c43127cf2..077afedce7 100644
--- a/drivers/crypto/scheduler/rte_pmd_crypto_scheduler_version.map
+++ b/drivers/crypto/scheduler/rte_pmd_crypto_scheduler_version.map
@@ -1,21 +1,16 @@
-DPDK_17.02 {
+DPDK_20.0 {
global:
rte_cryptodev_scheduler_load_user_scheduler;
- rte_cryptodev_scheduler_slave_attach;
- rte_cryptodev_scheduler_slave_detach;
- rte_cryptodev_scheduler_ordering_set;
- rte_cryptodev_scheduler_ordering_get;
-
-};
-
-DPDK_17.05 {
- global:
-
rte_cryptodev_scheduler_mode_get;
rte_cryptodev_scheduler_mode_set;
rte_cryptodev_scheduler_option_get;
rte_cryptodev_scheduler_option_set;
+ rte_cryptodev_scheduler_ordering_get;
+ rte_cryptodev_scheduler_ordering_set;
+ rte_cryptodev_scheduler_slave_attach;
+ rte_cryptodev_scheduler_slave_detach;
rte_cryptodev_scheduler_slaves_get;
-} DPDK_17.02;
+ local: *;
+};
diff --git a/drivers/crypto/snow3g/rte_pmd_snow3g_version.map b/drivers/crypto/snow3g/rte_pmd_snow3g_version.map
index dc4d417b7b..f9f17e4f6e 100644
--- a/drivers/crypto/snow3g/rte_pmd_snow3g_version.map
+++ b/drivers/crypto/snow3g/rte_pmd_snow3g_version.map
@@ -1,3 +1,3 @@
-DPDK_16.04 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/virtio/rte_pmd_virtio_crypto_version.map b/drivers/crypto/virtio/rte_pmd_virtio_crypto_version.map
index de8e412ff1..f9f17e4f6e 100644
--- a/drivers/crypto/virtio/rte_pmd_virtio_crypto_version.map
+++ b/drivers/crypto/virtio/rte_pmd_virtio_crypto_version.map
@@ -1,3 +1,3 @@
-DPDK_18.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/crypto/zuc/rte_pmd_zuc_version.map b/drivers/crypto/zuc/rte_pmd_zuc_version.map
index cc5829e30b..f9f17e4f6e 100644
--- a/drivers/crypto/zuc/rte_pmd_zuc_version.map
+++ b/drivers/crypto/zuc/rte_pmd_zuc_version.map
@@ -1,3 +1,3 @@
-DPDK_16.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/dpaa/rte_pmd_dpaa_event_version.map b/drivers/event/dpaa/rte_pmd_dpaa_event_version.map
index 179140fb87..f9f17e4f6e 100644
--- a/drivers/event/dpaa/rte_pmd_dpaa_event_version.map
+++ b/drivers/event/dpaa/rte_pmd_dpaa_event_version.map
@@ -1,4 +1,3 @@
-DPDK_18.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/dpaa2/rte_pmd_dpaa2_event_version.map b/drivers/event/dpaa2/rte_pmd_dpaa2_event_version.map
index 1c0b7559dc..f9f17e4f6e 100644
--- a/drivers/event/dpaa2/rte_pmd_dpaa2_event_version.map
+++ b/drivers/event/dpaa2/rte_pmd_dpaa2_event_version.map
@@ -1,3 +1,3 @@
-DPDK_17.08 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/dsw/rte_pmd_dsw_event_version.map b/drivers/event/dsw/rte_pmd_dsw_event_version.map
index 24bd5cdb35..f9f17e4f6e 100644
--- a/drivers/event/dsw/rte_pmd_dsw_event_version.map
+++ b/drivers/event/dsw/rte_pmd_dsw_event_version.map
@@ -1,3 +1,3 @@
-DPDK_18.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/octeontx/rte_pmd_octeontx_event_version.map b/drivers/event/octeontx/rte_pmd_octeontx_event_version.map
index 5352e7e3bd..f9f17e4f6e 100644
--- a/drivers/event/octeontx/rte_pmd_octeontx_event_version.map
+++ b/drivers/event/octeontx/rte_pmd_octeontx_event_version.map
@@ -1,3 +1,3 @@
-DPDK_17.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/octeontx2/rte_pmd_octeontx2_event_version.map b/drivers/event/octeontx2/rte_pmd_octeontx2_event_version.map
index 41c65c8c9c..f9f17e4f6e 100644
--- a/drivers/event/octeontx2/rte_pmd_octeontx2_event_version.map
+++ b/drivers/event/octeontx2/rte_pmd_octeontx2_event_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
+DPDK_20.0 {
local: *;
};
-
diff --git a/drivers/event/opdl/rte_pmd_opdl_event_version.map b/drivers/event/opdl/rte_pmd_opdl_event_version.map
index 58b94270d4..f9f17e4f6e 100644
--- a/drivers/event/opdl/rte_pmd_opdl_event_version.map
+++ b/drivers/event/opdl/rte_pmd_opdl_event_version.map
@@ -1,3 +1,3 @@
-DPDK_18.02 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/skeleton/rte_pmd_skeleton_event_version.map b/drivers/event/skeleton/rte_pmd_skeleton_event_version.map
index 8591cc0b18..f9f17e4f6e 100644
--- a/drivers/event/skeleton/rte_pmd_skeleton_event_version.map
+++ b/drivers/event/skeleton/rte_pmd_skeleton_event_version.map
@@ -1,4 +1,3 @@
-DPDK_17.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/event/sw/rte_pmd_sw_event_version.map b/drivers/event/sw/rte_pmd_sw_event_version.map
index 5352e7e3bd..f9f17e4f6e 100644
--- a/drivers/event/sw/rte_pmd_sw_event_version.map
+++ b/drivers/event/sw/rte_pmd_sw_event_version.map
@@ -1,3 +1,3 @@
-DPDK_17.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/mempool/bucket/rte_mempool_bucket_version.map b/drivers/mempool/bucket/rte_mempool_bucket_version.map
index 9b9ab1a4cf..f9f17e4f6e 100644
--- a/drivers/mempool/bucket/rte_mempool_bucket_version.map
+++ b/drivers/mempool/bucket/rte_mempool_bucket_version.map
@@ -1,4 +1,3 @@
-DPDK_18.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/mempool/dpaa/rte_mempool_dpaa_version.map b/drivers/mempool/dpaa/rte_mempool_dpaa_version.map
index 60bf50b2d1..9eebaf7ffd 100644
--- a/drivers/mempool/dpaa/rte_mempool_dpaa_version.map
+++ b/drivers/mempool/dpaa/rte_mempool_dpaa_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
rte_dpaa_bpid_info;
diff --git a/drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map b/drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map
index b45e7a9ac1..cd4bc88273 100644
--- a/drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map
+++ b/drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map
@@ -1,16 +1,10 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
rte_dpaa2_bpid_info;
rte_dpaa2_mbuf_alloc_bulk;
-
- local: *;
-};
-
-DPDK_18.05 {
- global:
-
rte_dpaa2_mbuf_from_buf_addr;
rte_dpaa2_mbuf_pool_bpid;
-} DPDK_17.05;
+ local: *;
+};
diff --git a/drivers/mempool/octeontx/rte_mempool_octeontx_version.map b/drivers/mempool/octeontx/rte_mempool_octeontx_version.map
index a753031720..f9f17e4f6e 100644
--- a/drivers/mempool/octeontx/rte_mempool_octeontx_version.map
+++ b/drivers/mempool/octeontx/rte_mempool_octeontx_version.map
@@ -1,3 +1,3 @@
-DPDK_17.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/mempool/octeontx2/rte_mempool_octeontx2_version.map b/drivers/mempool/octeontx2/rte_mempool_octeontx2_version.map
index d703368c31..d4f81aed8e 100644
--- a/drivers/mempool/octeontx2/rte_mempool_octeontx2_version.map
+++ b/drivers/mempool/octeontx2/rte_mempool_octeontx2_version.map
@@ -1,8 +1,8 @@
-DPDK_19.08 {
+DPDK_20.0 {
global:
- otx2_npa_lf_init;
otx2_npa_lf_fini;
+ otx2_npa_lf_init;
local: *;
};
diff --git a/drivers/mempool/ring/rte_mempool_ring_version.map b/drivers/mempool/ring/rte_mempool_ring_version.map
index 8591cc0b18..f9f17e4f6e 100644
--- a/drivers/mempool/ring/rte_mempool_ring_version.map
+++ b/drivers/mempool/ring/rte_mempool_ring_version.map
@@ -1,4 +1,3 @@
-DPDK_17.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/mempool/stack/rte_mempool_stack_version.map b/drivers/mempool/stack/rte_mempool_stack_version.map
index 8591cc0b18..f9f17e4f6e 100644
--- a/drivers/mempool/stack/rte_mempool_stack_version.map
+++ b/drivers/mempool/stack/rte_mempool_stack_version.map
@@ -1,4 +1,3 @@
-DPDK_17.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/af_packet/rte_pmd_af_packet_version.map b/drivers/net/af_packet/rte_pmd_af_packet_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/af_packet/rte_pmd_af_packet_version.map
+++ b/drivers/net/af_packet/rte_pmd_af_packet_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/af_xdp/rte_pmd_af_xdp_version.map b/drivers/net/af_xdp/rte_pmd_af_xdp_version.map
index c6db030fe6..f9f17e4f6e 100644
--- a/drivers/net/af_xdp/rte_pmd_af_xdp_version.map
+++ b/drivers/net/af_xdp/rte_pmd_af_xdp_version.map
@@ -1,3 +1,3 @@
-DPDK_19.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ark/rte_pmd_ark_version.map b/drivers/net/ark/rte_pmd_ark_version.map
index 1062e0429f..f9f17e4f6e 100644
--- a/drivers/net/ark/rte_pmd_ark_version.map
+++ b/drivers/net/ark/rte_pmd_ark_version.map
@@ -1,4 +1,3 @@
-DPDK_17.05 {
- local: *;
-
+DPDK_20.0 {
+ local: *;
};
diff --git a/drivers/net/atlantic/rte_pmd_atlantic_version.map b/drivers/net/atlantic/rte_pmd_atlantic_version.map
index b16faa999f..74146e9c09 100644
--- a/drivers/net/atlantic/rte_pmd_atlantic_version.map
+++ b/drivers/net/atlantic/rte_pmd_atlantic_version.map
@@ -1,8 +1,3 @@
-DPDK_18.11 {
-
- local: *;
-};
-
EXPERIMENTAL {
global:
@@ -13,4 +8,3 @@ EXPERIMENTAL {
rte_pmd_atl_macsec_select_txsa;
rte_pmd_atl_macsec_select_rxsa;
};
-
diff --git a/drivers/net/avp/rte_pmd_avp_version.map b/drivers/net/avp/rte_pmd_avp_version.map
index 5352e7e3bd..f9f17e4f6e 100644
--- a/drivers/net/avp/rte_pmd_avp_version.map
+++ b/drivers/net/avp/rte_pmd_avp_version.map
@@ -1,3 +1,3 @@
-DPDK_17.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/axgbe/rte_pmd_axgbe_version.map b/drivers/net/axgbe/rte_pmd_axgbe_version.map
index de8e412ff1..f9f17e4f6e 100644
--- a/drivers/net/axgbe/rte_pmd_axgbe_version.map
+++ b/drivers/net/axgbe/rte_pmd_axgbe_version.map
@@ -1,3 +1,3 @@
-DPDK_18.05 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/bnx2x/rte_pmd_bnx2x_version.map b/drivers/net/bnx2x/rte_pmd_bnx2x_version.map
index bd8138a034..f9f17e4f6e 100644
--- a/drivers/net/bnx2x/rte_pmd_bnx2x_version.map
+++ b/drivers/net/bnx2x/rte_pmd_bnx2x_version.map
@@ -1,4 +1,3 @@
-DPDK_2.1 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/bnxt/rte_pmd_bnxt_version.map b/drivers/net/bnxt/rte_pmd_bnxt_version.map
index 4750d40ad6..bb52562347 100644
--- a/drivers/net/bnxt/rte_pmd_bnxt_version.map
+++ b/drivers/net/bnxt/rte_pmd_bnxt_version.map
@@ -1,4 +1,4 @@
-DPDK_17.08 {
+DPDK_20.0 {
global:
rte_pmd_bnxt_get_vf_rx_status;
@@ -10,13 +10,13 @@ DPDK_17.08 {
rte_pmd_bnxt_set_tx_loopback;
rte_pmd_bnxt_set_vf_mac_addr;
rte_pmd_bnxt_set_vf_mac_anti_spoof;
+ rte_pmd_bnxt_set_vf_persist_stats;
rte_pmd_bnxt_set_vf_rate_limit;
rte_pmd_bnxt_set_vf_rxmode;
rte_pmd_bnxt_set_vf_vlan_anti_spoof;
rte_pmd_bnxt_set_vf_vlan_filter;
rte_pmd_bnxt_set_vf_vlan_insert;
rte_pmd_bnxt_set_vf_vlan_stripq;
- rte_pmd_bnxt_set_vf_persist_stats;
local: *;
};
diff --git a/drivers/net/bonding/rte_pmd_bond_version.map b/drivers/net/bonding/rte_pmd_bond_version.map
index 00d955c481..270c7d5d55 100644
--- a/drivers/net/bonding/rte_pmd_bond_version.map
+++ b/drivers/net/bonding/rte_pmd_bond_version.map
@@ -1,9 +1,21 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
+ rte_eth_bond_8023ad_agg_selection_get;
+ rte_eth_bond_8023ad_agg_selection_set;
+ rte_eth_bond_8023ad_conf_get;
+ rte_eth_bond_8023ad_dedicated_queues_disable;
+ rte_eth_bond_8023ad_dedicated_queues_enable;
+ rte_eth_bond_8023ad_ext_collect;
+ rte_eth_bond_8023ad_ext_collect_get;
+ rte_eth_bond_8023ad_ext_distrib;
+ rte_eth_bond_8023ad_ext_distrib_get;
+ rte_eth_bond_8023ad_ext_slowtx;
+ rte_eth_bond_8023ad_setup;
rte_eth_bond_8023ad_slave_info;
rte_eth_bond_active_slaves_get;
rte_eth_bond_create;
+ rte_eth_bond_free;
rte_eth_bond_link_monitoring_set;
rte_eth_bond_mac_address_reset;
rte_eth_bond_mac_address_set;
@@ -19,36 +31,3 @@ DPDK_2.0 {
local: *;
};
-
-DPDK_2.1 {
- global:
-
- rte_eth_bond_free;
-
-} DPDK_2.0;
-
-DPDK_16.04 {
-};
-
-DPDK_16.07 {
- global:
-
- rte_eth_bond_8023ad_ext_collect;
- rte_eth_bond_8023ad_ext_collect_get;
- rte_eth_bond_8023ad_ext_distrib;
- rte_eth_bond_8023ad_ext_distrib_get;
- rte_eth_bond_8023ad_ext_slowtx;
-
-} DPDK_16.04;
-
-DPDK_17.08 {
- global:
-
- rte_eth_bond_8023ad_dedicated_queues_enable;
- rte_eth_bond_8023ad_dedicated_queues_disable;
- rte_eth_bond_8023ad_agg_selection_get;
- rte_eth_bond_8023ad_agg_selection_set;
- rte_eth_bond_8023ad_conf_get;
- rte_eth_bond_8023ad_setup;
-
-} DPDK_16.07;
diff --git a/drivers/net/cxgbe/rte_pmd_cxgbe_version.map b/drivers/net/cxgbe/rte_pmd_cxgbe_version.map
index bd8138a034..f9f17e4f6e 100644
--- a/drivers/net/cxgbe/rte_pmd_cxgbe_version.map
+++ b/drivers/net/cxgbe/rte_pmd_cxgbe_version.map
@@ -1,4 +1,3 @@
-DPDK_2.1 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/dpaa/rte_pmd_dpaa_version.map b/drivers/net/dpaa/rte_pmd_dpaa_version.map
index 8cb4500b51..f403a1526d 100644
--- a/drivers/net/dpaa/rte_pmd_dpaa_version.map
+++ b/drivers/net/dpaa/rte_pmd_dpaa_version.map
@@ -1,12 +1,9 @@
-DPDK_17.11 {
-
- local: *;
-};
-
-DPDK_18.08 {
+DPDK_20.0 {
global:
dpaa_eth_eventq_attach;
dpaa_eth_eventq_detach;
rte_pmd_dpaa_set_tx_loopback;
-} DPDK_17.11;
+
+ local: *;
+};
diff --git a/drivers/net/dpaa2/rte_pmd_dpaa2_version.map b/drivers/net/dpaa2/rte_pmd_dpaa2_version.map
index d1b4cdb232..f2bb793319 100644
--- a/drivers/net/dpaa2/rte_pmd_dpaa2_version.map
+++ b/drivers/net/dpaa2/rte_pmd_dpaa2_version.map
@@ -1,15 +1,11 @@
-DPDK_17.05 {
-
- local: *;
-};
-
-DPDK_17.11 {
+DPDK_20.0 {
global:
dpaa2_eth_eventq_attach;
dpaa2_eth_eventq_detach;
-} DPDK_17.05;
+ local: *;
+};
EXPERIMENTAL {
global:
@@ -17,4 +13,4 @@ EXPERIMENTAL {
rte_pmd_dpaa2_mux_flow_create;
rte_pmd_dpaa2_set_custom_hash;
rte_pmd_dpaa2_set_timestamp;
-} DPDK_17.11;
+};
diff --git a/drivers/net/e1000/rte_pmd_e1000_version.map b/drivers/net/e1000/rte_pmd_e1000_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/e1000/rte_pmd_e1000_version.map
+++ b/drivers/net/e1000/rte_pmd_e1000_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ena/rte_pmd_ena_version.map b/drivers/net/ena/rte_pmd_ena_version.map
index 349c6e1c22..f9f17e4f6e 100644
--- a/drivers/net/ena/rte_pmd_ena_version.map
+++ b/drivers/net/ena/rte_pmd_ena_version.map
@@ -1,4 +1,3 @@
-DPDK_16.04 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/enetc/rte_pmd_enetc_version.map b/drivers/net/enetc/rte_pmd_enetc_version.map
index 521e51f411..f9f17e4f6e 100644
--- a/drivers/net/enetc/rte_pmd_enetc_version.map
+++ b/drivers/net/enetc/rte_pmd_enetc_version.map
@@ -1,4 +1,3 @@
-DPDK_18.11 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/enic/rte_pmd_enic_version.map b/drivers/net/enic/rte_pmd_enic_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/enic/rte_pmd_enic_version.map
+++ b/drivers/net/enic/rte_pmd_enic_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/failsafe/rte_pmd_failsafe_version.map b/drivers/net/failsafe/rte_pmd_failsafe_version.map
index b6d2840be4..f9f17e4f6e 100644
--- a/drivers/net/failsafe/rte_pmd_failsafe_version.map
+++ b/drivers/net/failsafe/rte_pmd_failsafe_version.map
@@ -1,4 +1,3 @@
-DPDK_17.08 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/fm10k/rte_pmd_fm10k_version.map b/drivers/net/fm10k/rte_pmd_fm10k_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/fm10k/rte_pmd_fm10k_version.map
+++ b/drivers/net/fm10k/rte_pmd_fm10k_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/hinic/rte_pmd_hinic_version.map b/drivers/net/hinic/rte_pmd_hinic_version.map
index 9a61188cd5..f9f17e4f6e 100644
--- a/drivers/net/hinic/rte_pmd_hinic_version.map
+++ b/drivers/net/hinic/rte_pmd_hinic_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/hns3/rte_pmd_hns3_version.map b/drivers/net/hns3/rte_pmd_hns3_version.map
index 35e5f2debb..f9f17e4f6e 100644
--- a/drivers/net/hns3/rte_pmd_hns3_version.map
+++ b/drivers/net/hns3/rte_pmd_hns3_version.map
@@ -1,3 +1,3 @@
-DPDK_19.11 {
- local: *;
+DPDK_20.0 {
+ local: *;
};
diff --git a/drivers/net/i40e/rte_pmd_i40e_version.map b/drivers/net/i40e/rte_pmd_i40e_version.map
index cccd5768c2..a80e69b93e 100644
--- a/drivers/net/i40e/rte_pmd_i40e_version.map
+++ b/drivers/net/i40e/rte_pmd_i40e_version.map
@@ -1,23 +1,34 @@
-DPDK_2.0 {
-
- local: *;
-};
-
-DPDK_17.02 {
+DPDK_20.0 {
global:
+ rte_pmd_i40e_add_vf_mac_addr;
+ rte_pmd_i40e_flow_add_del_packet_template;
+ rte_pmd_i40e_flow_type_mapping_get;
+ rte_pmd_i40e_flow_type_mapping_reset;
+ rte_pmd_i40e_flow_type_mapping_update;
+ rte_pmd_i40e_get_ddp_info;
+ rte_pmd_i40e_get_ddp_list;
rte_pmd_i40e_get_vf_stats;
+ rte_pmd_i40e_inset_get;
+ rte_pmd_i40e_inset_set;
rte_pmd_i40e_ping_vfs;
+ rte_pmd_i40e_process_ddp_package;
rte_pmd_i40e_ptype_mapping_get;
rte_pmd_i40e_ptype_mapping_replace;
rte_pmd_i40e_ptype_mapping_reset;
rte_pmd_i40e_ptype_mapping_update;
+ rte_pmd_i40e_query_vfid_by_mac;
rte_pmd_i40e_reset_vf_stats;
+ rte_pmd_i40e_rss_queue_region_conf;
+ rte_pmd_i40e_set_tc_strict_prio;
rte_pmd_i40e_set_tx_loopback;
rte_pmd_i40e_set_vf_broadcast;
rte_pmd_i40e_set_vf_mac_addr;
rte_pmd_i40e_set_vf_mac_anti_spoof;
+ rte_pmd_i40e_set_vf_max_bw;
rte_pmd_i40e_set_vf_multicast_promisc;
+ rte_pmd_i40e_set_vf_tc_bw_alloc;
+ rte_pmd_i40e_set_vf_tc_max_bw;
rte_pmd_i40e_set_vf_unicast_promisc;
rte_pmd_i40e_set_vf_vlan_anti_spoof;
rte_pmd_i40e_set_vf_vlan_filter;
@@ -25,43 +36,5 @@ DPDK_17.02 {
rte_pmd_i40e_set_vf_vlan_stripq;
rte_pmd_i40e_set_vf_vlan_tag;
-} DPDK_2.0;
-
-DPDK_17.05 {
- global:
-
- rte_pmd_i40e_set_tc_strict_prio;
- rte_pmd_i40e_set_vf_max_bw;
- rte_pmd_i40e_set_vf_tc_bw_alloc;
- rte_pmd_i40e_set_vf_tc_max_bw;
- rte_pmd_i40e_process_ddp_package;
- rte_pmd_i40e_get_ddp_list;
-
-} DPDK_17.02;
-
-DPDK_17.08 {
- global:
-
- rte_pmd_i40e_get_ddp_info;
-
-} DPDK_17.05;
-
-DPDK_17.11 {
- global:
-
- rte_pmd_i40e_add_vf_mac_addr;
- rte_pmd_i40e_flow_add_del_packet_template;
- rte_pmd_i40e_flow_type_mapping_update;
- rte_pmd_i40e_flow_type_mapping_get;
- rte_pmd_i40e_flow_type_mapping_reset;
- rte_pmd_i40e_query_vfid_by_mac;
- rte_pmd_i40e_rss_queue_region_conf;
-
-} DPDK_17.08;
-
-DPDK_18.02 {
- global:
-
- rte_pmd_i40e_inset_get;
- rte_pmd_i40e_inset_set;
-} DPDK_17.11;
\ No newline at end of file
+ local: *;
+};
diff --git a/drivers/net/iavf/rte_pmd_iavf_version.map b/drivers/net/iavf/rte_pmd_iavf_version.map
index 179140fb87..f9f17e4f6e 100644
--- a/drivers/net/iavf/rte_pmd_iavf_version.map
+++ b/drivers/net/iavf/rte_pmd_iavf_version.map
@@ -1,4 +1,3 @@
-DPDK_18.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ice/rte_pmd_ice_version.map b/drivers/net/ice/rte_pmd_ice_version.map
index 7b23b609da..f9f17e4f6e 100644
--- a/drivers/net/ice/rte_pmd_ice_version.map
+++ b/drivers/net/ice/rte_pmd_ice_version.map
@@ -1,4 +1,3 @@
-DPDK_19.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ifc/rte_pmd_ifc_version.map b/drivers/net/ifc/rte_pmd_ifc_version.map
index 9b9ab1a4cf..f9f17e4f6e 100644
--- a/drivers/net/ifc/rte_pmd_ifc_version.map
+++ b/drivers/net/ifc/rte_pmd_ifc_version.map
@@ -1,4 +1,3 @@
-DPDK_18.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map b/drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map
index fc8c95e919..f9f17e4f6e 100644
--- a/drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map
+++ b/drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map
@@ -1,4 +1,3 @@
-DPDK_19.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe_version.map b/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
index c814f96d72..21534dbc3d 100644
--- a/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
+++ b/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
@@ -1,57 +1,39 @@
-DPDK_2.0 {
-
- local: *;
-};
-
-DPDK_16.11 {
- global:
-
- rte_pmd_ixgbe_set_all_queues_drop_en;
- rte_pmd_ixgbe_set_tx_loopback;
- rte_pmd_ixgbe_set_vf_mac_addr;
- rte_pmd_ixgbe_set_vf_mac_anti_spoof;
- rte_pmd_ixgbe_set_vf_split_drop_en;
- rte_pmd_ixgbe_set_vf_vlan_anti_spoof;
- rte_pmd_ixgbe_set_vf_vlan_insert;
- rte_pmd_ixgbe_set_vf_vlan_stripq;
-} DPDK_2.0;
-
-DPDK_17.02 {
+DPDK_20.0 {
global:
+ rte_pmd_ixgbe_bypass_event_show;
+ rte_pmd_ixgbe_bypass_event_store;
+ rte_pmd_ixgbe_bypass_init;
+ rte_pmd_ixgbe_bypass_state_set;
+ rte_pmd_ixgbe_bypass_state_show;
+ rte_pmd_ixgbe_bypass_ver_show;
+ rte_pmd_ixgbe_bypass_wd_reset;
+ rte_pmd_ixgbe_bypass_wd_timeout_show;
+ rte_pmd_ixgbe_bypass_wd_timeout_store;
rte_pmd_ixgbe_macsec_config_rxsc;
rte_pmd_ixgbe_macsec_config_txsc;
rte_pmd_ixgbe_macsec_disable;
rte_pmd_ixgbe_macsec_enable;
rte_pmd_ixgbe_macsec_select_rxsa;
rte_pmd_ixgbe_macsec_select_txsa;
+ rte_pmd_ixgbe_ping_vf;
+ rte_pmd_ixgbe_set_all_queues_drop_en;
+ rte_pmd_ixgbe_set_tc_bw_alloc;
+ rte_pmd_ixgbe_set_tx_loopback;
+ rte_pmd_ixgbe_set_vf_mac_addr;
+ rte_pmd_ixgbe_set_vf_mac_anti_spoof;
rte_pmd_ixgbe_set_vf_rate_limit;
rte_pmd_ixgbe_set_vf_rx;
rte_pmd_ixgbe_set_vf_rxmode;
+ rte_pmd_ixgbe_set_vf_split_drop_en;
rte_pmd_ixgbe_set_vf_tx;
+ rte_pmd_ixgbe_set_vf_vlan_anti_spoof;
rte_pmd_ixgbe_set_vf_vlan_filter;
-} DPDK_16.11;
+ rte_pmd_ixgbe_set_vf_vlan_insert;
+ rte_pmd_ixgbe_set_vf_vlan_stripq;
-DPDK_17.05 {
- global:
-
- rte_pmd_ixgbe_ping_vf;
- rte_pmd_ixgbe_set_tc_bw_alloc;
-} DPDK_17.02;
-
-DPDK_17.08 {
- global:
-
- rte_pmd_ixgbe_bypass_event_show;
- rte_pmd_ixgbe_bypass_event_store;
- rte_pmd_ixgbe_bypass_init;
- rte_pmd_ixgbe_bypass_state_set;
- rte_pmd_ixgbe_bypass_state_show;
- rte_pmd_ixgbe_bypass_ver_show;
- rte_pmd_ixgbe_bypass_wd_reset;
- rte_pmd_ixgbe_bypass_wd_timeout_show;
- rte_pmd_ixgbe_bypass_wd_timeout_store;
-} DPDK_17.05;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/drivers/net/kni/rte_pmd_kni_version.map b/drivers/net/kni/rte_pmd_kni_version.map
index 8591cc0b18..f9f17e4f6e 100644
--- a/drivers/net/kni/rte_pmd_kni_version.map
+++ b/drivers/net/kni/rte_pmd_kni_version.map
@@ -1,4 +1,3 @@
-DPDK_17.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/liquidio/rte_pmd_liquidio_version.map b/drivers/net/liquidio/rte_pmd_liquidio_version.map
index 8591cc0b18..f9f17e4f6e 100644
--- a/drivers/net/liquidio/rte_pmd_liquidio_version.map
+++ b/drivers/net/liquidio/rte_pmd_liquidio_version.map
@@ -1,4 +1,3 @@
-DPDK_17.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/memif/rte_pmd_memif_version.map b/drivers/net/memif/rte_pmd_memif_version.map
index 8861484fb3..f9f17e4f6e 100644
--- a/drivers/net/memif/rte_pmd_memif_version.map
+++ b/drivers/net/memif/rte_pmd_memif_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
-
- local: *;
+DPDK_20.0 {
+ local: *;
};
diff --git a/drivers/net/mlx4/rte_pmd_mlx4_version.map b/drivers/net/mlx4/rte_pmd_mlx4_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/mlx4/rte_pmd_mlx4_version.map
+++ b/drivers/net/mlx4/rte_pmd_mlx4_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/mlx5/rte_pmd_mlx5_version.map b/drivers/net/mlx5/rte_pmd_mlx5_version.map
index ad607bbedd..f9f17e4f6e 100644
--- a/drivers/net/mlx5/rte_pmd_mlx5_version.map
+++ b/drivers/net/mlx5/rte_pmd_mlx5_version.map
@@ -1,3 +1,3 @@
-DPDK_2.2 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/mvneta/rte_pmd_mvneta_version.map b/drivers/net/mvneta/rte_pmd_mvneta_version.map
index 24bd5cdb35..f9f17e4f6e 100644
--- a/drivers/net/mvneta/rte_pmd_mvneta_version.map
+++ b/drivers/net/mvneta/rte_pmd_mvneta_version.map
@@ -1,3 +1,3 @@
-DPDK_18.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/mvpp2/rte_pmd_mvpp2_version.map b/drivers/net/mvpp2/rte_pmd_mvpp2_version.map
index a753031720..f9f17e4f6e 100644
--- a/drivers/net/mvpp2/rte_pmd_mvpp2_version.map
+++ b/drivers/net/mvpp2/rte_pmd_mvpp2_version.map
@@ -1,3 +1,3 @@
-DPDK_17.11 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/netvsc/rte_pmd_netvsc_version.map b/drivers/net/netvsc/rte_pmd_netvsc_version.map
index d534019a6b..f9f17e4f6e 100644
--- a/drivers/net/netvsc/rte_pmd_netvsc_version.map
+++ b/drivers/net/netvsc/rte_pmd_netvsc_version.map
@@ -1,5 +1,3 @@
-/* SPDX-License-Identifier: BSD-3-Clause */
-
-DPDK_18.08 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/nfb/rte_pmd_nfb_version.map b/drivers/net/nfb/rte_pmd_nfb_version.map
index fc8c95e919..f9f17e4f6e 100644
--- a/drivers/net/nfb/rte_pmd_nfb_version.map
+++ b/drivers/net/nfb/rte_pmd_nfb_version.map
@@ -1,4 +1,3 @@
-DPDK_19.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/nfp/rte_pmd_nfp_version.map b/drivers/net/nfp/rte_pmd_nfp_version.map
index ad607bbedd..f9f17e4f6e 100644
--- a/drivers/net/nfp/rte_pmd_nfp_version.map
+++ b/drivers/net/nfp/rte_pmd_nfp_version.map
@@ -1,3 +1,3 @@
-DPDK_2.2 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/null/rte_pmd_null_version.map b/drivers/net/null/rte_pmd_null_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/null/rte_pmd_null_version.map
+++ b/drivers/net/null/rte_pmd_null_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/octeontx/rte_pmd_octeontx_version.map b/drivers/net/octeontx/rte_pmd_octeontx_version.map
index a3161b14d0..f7cae02fac 100644
--- a/drivers/net/octeontx/rte_pmd_octeontx_version.map
+++ b/drivers/net/octeontx/rte_pmd_octeontx_version.map
@@ -1,11 +1,7 @@
-DPDK_17.11 {
-
- local: *;
-};
-
-DPDK_18.02 {
+DPDK_20.0 {
global:
rte_octeontx_pchan_map;
-} DPDK_17.11;
+ local: *;
+};
diff --git a/drivers/net/octeontx2/rte_pmd_octeontx2_version.map b/drivers/net/octeontx2/rte_pmd_octeontx2_version.map
index 9a61188cd5..f9f17e4f6e 100644
--- a/drivers/net/octeontx2/rte_pmd_octeontx2_version.map
+++ b/drivers/net/octeontx2/rte_pmd_octeontx2_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/pcap/rte_pmd_pcap_version.map b/drivers/net/pcap/rte_pmd_pcap_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/pcap/rte_pmd_pcap_version.map
+++ b/drivers/net/pcap/rte_pmd_pcap_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/pfe/rte_pmd_pfe_version.map b/drivers/net/pfe/rte_pmd_pfe_version.map
index b7b7c91683..f9f17e4f6e 100644
--- a/drivers/net/pfe/rte_pmd_pfe_version.map
+++ b/drivers/net/pfe/rte_pmd_pfe_version.map
@@ -1,4 +1,3 @@
-DPDK_19.11 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/qede/rte_pmd_qede_version.map b/drivers/net/qede/rte_pmd_qede_version.map
index 349c6e1c22..f9f17e4f6e 100644
--- a/drivers/net/qede/rte_pmd_qede_version.map
+++ b/drivers/net/qede/rte_pmd_qede_version.map
@@ -1,4 +1,3 @@
-DPDK_16.04 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/ring/rte_pmd_ring_version.map b/drivers/net/ring/rte_pmd_ring_version.map
index 1f785d9409..ebb6be2733 100644
--- a/drivers/net/ring/rte_pmd_ring_version.map
+++ b/drivers/net/ring/rte_pmd_ring_version.map
@@ -1,14 +1,8 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
+ rte_eth_from_ring;
rte_eth_from_rings;
local: *;
};
-
-DPDK_2.2 {
- global:
-
- rte_eth_from_ring;
-
-} DPDK_2.0;
diff --git a/drivers/net/sfc/rte_pmd_sfc_version.map b/drivers/net/sfc/rte_pmd_sfc_version.map
index 31eca32ebe..f9f17e4f6e 100644
--- a/drivers/net/sfc/rte_pmd_sfc_version.map
+++ b/drivers/net/sfc/rte_pmd_sfc_version.map
@@ -1,4 +1,3 @@
-DPDK_17.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/softnic/rte_pmd_softnic_version.map b/drivers/net/softnic/rte_pmd_softnic_version.map
index bc44b06f98..50f113d5a2 100644
--- a/drivers/net/softnic/rte_pmd_softnic_version.map
+++ b/drivers/net/softnic/rte_pmd_softnic_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
rte_pmd_softnic_run;
diff --git a/drivers/net/szedata2/rte_pmd_szedata2_version.map b/drivers/net/szedata2/rte_pmd_szedata2_version.map
index ad607bbedd..f9f17e4f6e 100644
--- a/drivers/net/szedata2/rte_pmd_szedata2_version.map
+++ b/drivers/net/szedata2/rte_pmd_szedata2_version.map
@@ -1,3 +1,3 @@
-DPDK_2.2 {
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/tap/rte_pmd_tap_version.map b/drivers/net/tap/rte_pmd_tap_version.map
index 31eca32ebe..f9f17e4f6e 100644
--- a/drivers/net/tap/rte_pmd_tap_version.map
+++ b/drivers/net/tap/rte_pmd_tap_version.map
@@ -1,4 +1,3 @@
-DPDK_17.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/thunderx/rte_pmd_thunderx_version.map b/drivers/net/thunderx/rte_pmd_thunderx_version.map
index 1901bcb3b3..f9f17e4f6e 100644
--- a/drivers/net/thunderx/rte_pmd_thunderx_version.map
+++ b/drivers/net/thunderx/rte_pmd_thunderx_version.map
@@ -1,4 +1,3 @@
-DPDK_16.07 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/vdev_netvsc/rte_pmd_vdev_netvsc_version.map b/drivers/net/vdev_netvsc/rte_pmd_vdev_netvsc_version.map
index 179140fb87..f9f17e4f6e 100644
--- a/drivers/net/vdev_netvsc/rte_pmd_vdev_netvsc_version.map
+++ b/drivers/net/vdev_netvsc/rte_pmd_vdev_netvsc_version.map
@@ -1,4 +1,3 @@
-DPDK_18.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/vhost/rte_pmd_vhost_version.map b/drivers/net/vhost/rte_pmd_vhost_version.map
index 695db85749..16b591ccc4 100644
--- a/drivers/net/vhost/rte_pmd_vhost_version.map
+++ b/drivers/net/vhost/rte_pmd_vhost_version.map
@@ -1,13 +1,8 @@
-DPDK_16.04 {
+DPDK_20.0 {
global:
rte_eth_vhost_get_queue_event;
-
- local: *;
-};
-
-DPDK_16.11 {
- global:
-
rte_eth_vhost_get_vid_from_port_id;
+
+ local: *;
};
diff --git a/drivers/net/virtio/rte_pmd_virtio_version.map b/drivers/net/virtio/rte_pmd_virtio_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/virtio/rte_pmd_virtio_version.map
+++ b/drivers/net/virtio/rte_pmd_virtio_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/net/vmxnet3/rte_pmd_vmxnet3_version.map b/drivers/net/vmxnet3/rte_pmd_vmxnet3_version.map
index ef35398402..f9f17e4f6e 100644
--- a/drivers/net/vmxnet3/rte_pmd_vmxnet3_version.map
+++ b/drivers/net/vmxnet3/rte_pmd_vmxnet3_version.map
@@ -1,4 +1,3 @@
-DPDK_2.0 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map b/drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map
index 9b9ab1a4cf..f9f17e4f6e 100644
--- a/drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map
+++ b/drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map
@@ -1,4 +1,3 @@
-DPDK_18.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map b/drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map
index d16a136fc8..ca6a0d7626 100644
--- a/drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map
+++ b/drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map
@@ -1,4 +1,4 @@
-DPDK_19.05 {
+DPDK_20.0 {
global:
rte_qdma_attr_get;
@@ -9,9 +9,9 @@ DPDK_19.05 {
rte_qdma_start;
rte_qdma_stop;
rte_qdma_vq_create;
- rte_qdma_vq_destroy;
rte_qdma_vq_dequeue;
rte_qdma_vq_dequeue_multi;
+ rte_qdma_vq_destroy;
rte_qdma_vq_enqueue;
rte_qdma_vq_enqueue_multi;
rte_qdma_vq_stats;
diff --git a/drivers/raw/ifpga/rte_rawdev_ifpga_version.map b/drivers/raw/ifpga/rte_rawdev_ifpga_version.map
index 9b9ab1a4cf..f9f17e4f6e 100644
--- a/drivers/raw/ifpga/rte_rawdev_ifpga_version.map
+++ b/drivers/raw/ifpga/rte_rawdev_ifpga_version.map
@@ -1,4 +1,3 @@
-DPDK_18.05 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/raw/ioat/rte_rawdev_ioat_version.map b/drivers/raw/ioat/rte_rawdev_ioat_version.map
index 9a61188cd5..f9f17e4f6e 100644
--- a/drivers/raw/ioat/rte_rawdev_ioat_version.map
+++ b/drivers/raw/ioat/rte_rawdev_ioat_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/raw/ntb/rte_rawdev_ntb_version.map b/drivers/raw/ntb/rte_rawdev_ntb_version.map
index 8861484fb3..f9f17e4f6e 100644
--- a/drivers/raw/ntb/rte_rawdev_ntb_version.map
+++ b/drivers/raw/ntb/rte_rawdev_ntb_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
-
- local: *;
+DPDK_20.0 {
+ local: *;
};
diff --git a/drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map b/drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map
index 9a61188cd5..f9f17e4f6e 100644
--- a/drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map
+++ b/drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map
@@ -1,4 +1,3 @@
-DPDK_19.08 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/drivers/raw/skeleton/rte_rawdev_skeleton_version.map b/drivers/raw/skeleton/rte_rawdev_skeleton_version.map
index 179140fb87..f9f17e4f6e 100644
--- a/drivers/raw/skeleton/rte_rawdev_skeleton_version.map
+++ b/drivers/raw/skeleton/rte_rawdev_skeleton_version.map
@@ -1,4 +1,3 @@
-DPDK_18.02 {
-
+DPDK_20.0 {
local: *;
};
diff --git a/lib/librte_acl/rte_acl_version.map b/lib/librte_acl/rte_acl_version.map
index b09370a104..c3daca8115 100644
--- a/lib/librte_acl/rte_acl_version.map
+++ b/lib/librte_acl/rte_acl_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_acl_add_rules;
diff --git a/lib/librte_bitratestats/rte_bitratestats_version.map b/lib/librte_bitratestats/rte_bitratestats_version.map
index fe7454452d..88fc2912db 100644
--- a/lib/librte_bitratestats/rte_bitratestats_version.map
+++ b/lib/librte_bitratestats/rte_bitratestats_version.map
@@ -1,4 +1,4 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
rte_stats_bitrate_calc;
diff --git a/lib/librte_cfgfile/rte_cfgfile_version.map b/lib/librte_cfgfile/rte_cfgfile_version.map
index a0a11cea8d..906eee96bf 100644
--- a/lib/librte_cfgfile/rte_cfgfile_version.map
+++ b/lib/librte_cfgfile/rte_cfgfile_version.map
@@ -1,40 +1,22 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
+ rte_cfgfile_add_entry;
+ rte_cfgfile_add_section;
rte_cfgfile_close;
+ rte_cfgfile_create;
rte_cfgfile_get_entry;
rte_cfgfile_has_entry;
rte_cfgfile_has_section;
rte_cfgfile_load;
+ rte_cfgfile_load_with_params;
rte_cfgfile_num_sections;
+ rte_cfgfile_save;
rte_cfgfile_section_entries;
+ rte_cfgfile_section_entries_by_index;
rte_cfgfile_section_num_entries;
rte_cfgfile_sections;
+ rte_cfgfile_set_entry;
local: *;
};
-
-DPDK_16.04 {
- global:
-
- rte_cfgfile_section_entries_by_index;
-
-} DPDK_2.0;
-
-DPDK_17.05 {
- global:
-
- rte_cfgfile_load_with_params;
-
-} DPDK_16.04;
-
-DPDK_17.11 {
- global:
-
- rte_cfgfile_add_entry;
- rte_cfgfile_add_section;
- rte_cfgfile_create;
- rte_cfgfile_save;
- rte_cfgfile_set_entry;
-
-} DPDK_17.05;
diff --git a/lib/librte_cmdline/rte_cmdline_version.map b/lib/librte_cmdline/rte_cmdline_version.map
index 04bcb387f2..95fce812ff 100644
--- a/lib/librte_cmdline/rte_cmdline_version.map
+++ b/lib/librte_cmdline/rte_cmdline_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
cirbuf_add_buf_head;
@@ -40,6 +40,7 @@ DPDK_2.0 {
cmdline_parse_num;
cmdline_parse_portlist;
cmdline_parse_string;
+ cmdline_poll;
cmdline_printf;
cmdline_quit;
cmdline_set_prompt;
@@ -68,10 +69,3 @@ DPDK_2.0 {
local: *;
};
-
-DPDK_2.1 {
- global:
-
- cmdline_poll;
-
-} DPDK_2.0;
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map b/lib/librte_cryptodev/rte_cryptodev_version.map
index 3deb265ac2..1dd1e259a0 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -1,92 +1,62 @@
-DPDK_16.04 {
+DPDK_20.0 {
global:
- rte_cryptodevs;
+ rte_crypto_aead_algorithm_strings;
+ rte_crypto_aead_operation_strings;
+ rte_crypto_auth_algorithm_strings;
+ rte_crypto_auth_operation_strings;
+ rte_crypto_cipher_algorithm_strings;
+ rte_crypto_cipher_operation_strings;
+ rte_crypto_op_pool_create;
+ rte_cryptodev_allocate_driver;
rte_cryptodev_callback_register;
rte_cryptodev_callback_unregister;
rte_cryptodev_close;
- rte_cryptodev_count;
rte_cryptodev_configure;
+ rte_cryptodev_count;
+ rte_cryptodev_device_count_by_driver;
+ rte_cryptodev_devices_get;
+ rte_cryptodev_driver_id_get;
+ rte_cryptodev_driver_name_get;
+ rte_cryptodev_get_aead_algo_enum;
+ rte_cryptodev_get_auth_algo_enum;
+ rte_cryptodev_get_cipher_algo_enum;
rte_cryptodev_get_dev_id;
rte_cryptodev_get_feature_name;
+ rte_cryptodev_get_sec_ctx;
rte_cryptodev_info_get;
+ rte_cryptodev_name_get;
rte_cryptodev_pmd_allocate;
rte_cryptodev_pmd_callback_process;
+ rte_cryptodev_pmd_create;
+ rte_cryptodev_pmd_create_dev_name;
+ rte_cryptodev_pmd_destroy;
+ rte_cryptodev_pmd_get_dev;
+ rte_cryptodev_pmd_get_named_dev;
+ rte_cryptodev_pmd_is_valid_dev;
+ rte_cryptodev_pmd_parse_input_args;
rte_cryptodev_pmd_release_device;
- rte_cryptodev_sym_session_create;
- rte_cryptodev_sym_session_free;
+ rte_cryptodev_queue_pair_count;
+ rte_cryptodev_queue_pair_setup;
rte_cryptodev_socket_id;
rte_cryptodev_start;
rte_cryptodev_stats_get;
rte_cryptodev_stats_reset;
rte_cryptodev_stop;
- rte_cryptodev_queue_pair_count;
- rte_cryptodev_queue_pair_setup;
- rte_crypto_op_pool_create;
-
- local: *;
-};
-
-DPDK_17.02 {
- global:
-
- rte_cryptodev_devices_get;
- rte_cryptodev_pmd_create_dev_name;
- rte_cryptodev_pmd_get_dev;
- rte_cryptodev_pmd_get_named_dev;
- rte_cryptodev_pmd_is_valid_dev;
+ rte_cryptodev_sym_capability_check_aead;
rte_cryptodev_sym_capability_check_auth;
rte_cryptodev_sym_capability_check_cipher;
rte_cryptodev_sym_capability_get;
- rte_crypto_auth_algorithm_strings;
- rte_crypto_auth_operation_strings;
- rte_crypto_cipher_algorithm_strings;
- rte_crypto_cipher_operation_strings;
-
-} DPDK_16.04;
-
-DPDK_17.05 {
- global:
-
- rte_cryptodev_get_auth_algo_enum;
- rte_cryptodev_get_cipher_algo_enum;
-
-} DPDK_17.02;
-
-DPDK_17.08 {
- global:
-
- rte_cryptodev_allocate_driver;
- rte_cryptodev_device_count_by_driver;
- rte_cryptodev_driver_id_get;
- rte_cryptodev_driver_name_get;
- rte_cryptodev_get_aead_algo_enum;
- rte_cryptodev_sym_capability_check_aead;
- rte_cryptodev_sym_session_init;
- rte_cryptodev_sym_session_clear;
- rte_crypto_aead_algorithm_strings;
- rte_crypto_aead_operation_strings;
-
-} DPDK_17.05;
-
-DPDK_17.11 {
- global:
-
- rte_cryptodev_get_sec_ctx;
- rte_cryptodev_name_get;
- rte_cryptodev_pmd_create;
- rte_cryptodev_pmd_destroy;
- rte_cryptodev_pmd_parse_input_args;
-
-} DPDK_17.08;
-
-DPDK_18.05 {
- global:
-
rte_cryptodev_sym_get_header_session_size;
rte_cryptodev_sym_get_private_session_size;
+ rte_cryptodev_sym_session_clear;
+ rte_cryptodev_sym_session_create;
+ rte_cryptodev_sym_session_free;
+ rte_cryptodev_sym_session_init;
+ rte_cryptodevs;
-} DPDK_17.11;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_distributor/rte_distributor_version.map b/lib/librte_distributor/rte_distributor_version.map
index 00e26b4804..1b7c643005 100644
--- a/lib/librte_distributor/rte_distributor_version.map
+++ b/lib/librte_distributor/rte_distributor_version.map
@@ -1,4 +1,4 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
rte_distributor_clear_returns;
@@ -10,4 +10,6 @@ DPDK_17.05 {
rte_distributor_request_pkt;
rte_distributor_return_pkt;
rte_distributor_returned_pkts;
+
+ local: *;
};
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index 3478d3b852..8cfe6ca07e 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
__rte_panic;
@@ -6,44 +6,113 @@ DPDK_2.0 {
eal_timer_source;
per_lcore__lcore_id;
per_lcore__rte_errno;
+ rte_bus_dump;
+ rte_bus_find;
+ rte_bus_find_by_device;
+ rte_bus_find_by_name;
+ rte_bus_get_iommu_class;
+ rte_bus_probe;
+ rte_bus_register;
+ rte_bus_scan;
+ rte_bus_unregister;
rte_calloc;
rte_calloc_socket;
rte_cpu_get_flag_enabled;
+ rte_cpu_get_flag_name;
+ rte_cpu_is_supported;
+ rte_ctrl_thread_create;
rte_cycles_vmware_tsc_map;
rte_delay_us;
+ rte_delay_us_block;
+ rte_delay_us_callback_register;
+ rte_dev_is_probed;
+ rte_dev_probe;
+ rte_dev_remove;
+ rte_devargs_add;
+ rte_devargs_dump;
+ rte_devargs_insert;
+ rte_devargs_next;
+ rte_devargs_parse;
+ rte_devargs_parsef;
+ rte_devargs_remove;
+ rte_devargs_type_count;
rte_dump_physmem_layout;
rte_dump_registers;
rte_dump_stack;
rte_dump_tailq;
rte_eal_alarm_cancel;
rte_eal_alarm_set;
+ rte_eal_cleanup;
+ rte_eal_create_uio_dev;
rte_eal_get_lcore_state;
rte_eal_get_physmem_size;
+ rte_eal_get_runtime_dir;
rte_eal_has_hugepages;
+ rte_eal_has_pci;
+ rte_eal_hotplug_add;
+ rte_eal_hotplug_remove;
rte_eal_hpet_init;
rte_eal_init;
rte_eal_iopl_init;
+ rte_eal_iova_mode;
rte_eal_lcore_role;
+ rte_eal_mbuf_user_pool_ops;
rte_eal_mp_remote_launch;
rte_eal_mp_wait_lcore;
+ rte_eal_primary_proc_alive;
rte_eal_process_type;
rte_eal_remote_launch;
rte_eal_tailq_lookup;
rte_eal_tailq_register;
+ rte_eal_using_phys_addrs;
+ rte_eal_vfio_intr_mode;
rte_eal_wait_lcore;
+ rte_epoll_ctl;
+ rte_epoll_wait;
rte_exit;
rte_free;
rte_get_hpet_cycles;
rte_get_hpet_hz;
+ rte_get_master_lcore;
+ rte_get_next_lcore;
rte_get_tsc_hz;
rte_hexdump;
+ rte_hypervisor_get;
+ rte_hypervisor_get_name;
+ rte_intr_allow_others;
rte_intr_callback_register;
rte_intr_callback_unregister;
+ rte_intr_cap_multiple;
rte_intr_disable;
+ rte_intr_dp_is_en;
+ rte_intr_efd_disable;
+ rte_intr_efd_enable;
rte_intr_enable;
+ rte_intr_free_epoll_fd;
+ rte_intr_rx_ctl;
+ rte_intr_tls_epfd;
+ rte_keepalive_create;
+ rte_keepalive_dispatch_pings;
+ rte_keepalive_mark_alive;
+ rte_keepalive_mark_sleep;
+ rte_keepalive_register_core;
+ rte_keepalive_register_relay_callback;
+ rte_lcore_count;
+ rte_lcore_has_role;
+ rte_lcore_index;
+ rte_lcore_is_enabled;
+ rte_lcore_to_socket_id;
rte_log;
rte_log_cur_msg_loglevel;
rte_log_cur_msg_logtype;
+ rte_log_dump;
+ rte_log_get_global_level;
+ rte_log_get_level;
+ rte_log_register;
+ rte_log_set_global_level;
+ rte_log_set_level;
+ rte_log_set_level_pattern;
+ rte_log_set_level_regexp;
rte_logs;
rte_malloc;
rte_malloc_dump_stats;
@@ -51,155 +120,38 @@ DPDK_2.0 {
rte_malloc_set_limit;
rte_malloc_socket;
rte_malloc_validate;
+ rte_malloc_virt2iova;
+ rte_mcfg_mem_read_lock;
+ rte_mcfg_mem_read_unlock;
+ rte_mcfg_mem_write_lock;
+ rte_mcfg_mem_write_unlock;
+ rte_mcfg_mempool_read_lock;
+ rte_mcfg_mempool_read_unlock;
+ rte_mcfg_mempool_write_lock;
+ rte_mcfg_mempool_write_unlock;
+ rte_mcfg_tailq_read_lock;
+ rte_mcfg_tailq_read_unlock;
+ rte_mcfg_tailq_write_lock;
+ rte_mcfg_tailq_write_unlock;
rte_mem_lock_page;
+ rte_mem_virt2iova;
rte_mem_virt2phy;
rte_memdump;
rte_memory_get_nchannel;
rte_memory_get_nrank;
rte_memzone_dump;
+ rte_memzone_free;
rte_memzone_lookup;
rte_memzone_reserve;
rte_memzone_reserve_aligned;
rte_memzone_reserve_bounded;
rte_memzone_walk;
rte_openlog_stream;
+ rte_rand;
rte_realloc;
- rte_set_application_usage_hook;
- rte_socket_id;
- rte_strerror;
- rte_strsplit;
- rte_sys_gettid;
- rte_thread_get_affinity;
- rte_thread_set_affinity;
- rte_vlog;
- rte_zmalloc;
- rte_zmalloc_socket;
-
- local: *;
-};
-
-DPDK_2.1 {
- global:
-
- rte_epoll_ctl;
- rte_epoll_wait;
- rte_intr_allow_others;
- rte_intr_dp_is_en;
- rte_intr_efd_disable;
- rte_intr_efd_enable;
- rte_intr_rx_ctl;
- rte_intr_tls_epfd;
- rte_memzone_free;
-
-} DPDK_2.0;
-
-DPDK_2.2 {
- global:
-
- rte_intr_cap_multiple;
- rte_keepalive_create;
- rte_keepalive_dispatch_pings;
- rte_keepalive_mark_alive;
- rte_keepalive_register_core;
-
-} DPDK_2.1;
-
-DPDK_16.04 {
- global:
-
- rte_cpu_get_flag_name;
- rte_eal_primary_proc_alive;
-
-} DPDK_2.2;
-
-DPDK_16.07 {
- global:
-
- rte_keepalive_mark_sleep;
- rte_keepalive_register_relay_callback;
- rte_rtm_supported;
- rte_thread_setname;
-
-} DPDK_16.04;
-
-DPDK_16.11 {
- global:
-
- rte_delay_us_block;
- rte_delay_us_callback_register;
-
-} DPDK_16.07;
-
-DPDK_17.02 {
- global:
-
- rte_bus_dump;
- rte_bus_probe;
- rte_bus_register;
- rte_bus_scan;
- rte_bus_unregister;
-
-} DPDK_16.11;
-
-DPDK_17.05 {
- global:
-
- rte_cpu_is_supported;
- rte_intr_free_epoll_fd;
- rte_log_dump;
- rte_log_get_global_level;
- rte_log_register;
- rte_log_set_global_level;
- rte_log_set_level;
- rte_log_set_level_regexp;
-
-} DPDK_17.02;
-
-DPDK_17.08 {
- global:
-
- rte_bus_find;
- rte_bus_find_by_device;
- rte_bus_find_by_name;
- rte_log_get_level;
-
-} DPDK_17.05;
-
-DPDK_17.11 {
- global:
-
- rte_eal_create_uio_dev;
- rte_bus_get_iommu_class;
- rte_eal_has_pci;
- rte_eal_iova_mode;
- rte_eal_using_phys_addrs;
- rte_eal_vfio_intr_mode;
- rte_lcore_has_role;
- rte_malloc_virt2iova;
- rte_mem_virt2iova;
- rte_vfio_enable;
- rte_vfio_is_enabled;
- rte_vfio_noiommu_is_enabled;
- rte_vfio_release_device;
- rte_vfio_setup_device;
-
-} DPDK_17.08;
-
-DPDK_18.02 {
- global:
-
- rte_hypervisor_get;
- rte_hypervisor_get_name;
- rte_vfio_clear_group;
rte_reciprocal_value;
rte_reciprocal_value_u64;
-
-} DPDK_17.11;
-
-DPDK_18.05 {
- global:
-
- rte_log_set_level_pattern;
+ rte_rtm_supported;
rte_service_attr_get;
rte_service_attr_reset_all;
rte_service_component_register;
@@ -212,6 +164,8 @@ DPDK_18.05 {
rte_service_get_count;
rte_service_get_name;
rte_service_lcore_add;
+ rte_service_lcore_attr_get;
+ rte_service_lcore_attr_reset_all;
rte_service_lcore_count;
rte_service_lcore_count_services;
rte_service_lcore_del;
@@ -221,6 +175,7 @@ DPDK_18.05 {
rte_service_lcore_stop;
rte_service_map_lcore_get;
rte_service_map_lcore_set;
+ rte_service_may_be_active;
rte_service_probe_capability;
rte_service_run_iter_on_app_lcore;
rte_service_runstate_get;
@@ -228,17 +183,23 @@ DPDK_18.05 {
rte_service_set_runstate_mapped_check;
rte_service_set_stats_enable;
rte_service_start_with_defaults;
-
-} DPDK_18.02;
-
-DPDK_18.08 {
- global:
-
- rte_eal_mbuf_user_pool_ops;
+ rte_set_application_usage_hook;
+ rte_socket_count;
+ rte_socket_id;
+ rte_socket_id_by_idx;
+ rte_srand;
+ rte_strerror;
+ rte_strscpy;
+ rte_strsplit;
+ rte_sys_gettid;
+ rte_thread_get_affinity;
+ rte_thread_set_affinity;
+ rte_thread_setname;
rte_uuid_compare;
rte_uuid_is_null;
rte_uuid_parse;
rte_uuid_unparse;
+ rte_vfio_clear_group;
rte_vfio_container_create;
rte_vfio_container_destroy;
rte_vfio_container_dma_map;
@@ -247,77 +208,20 @@ DPDK_18.08 {
rte_vfio_container_group_unbind;
rte_vfio_dma_map;
rte_vfio_dma_unmap;
+ rte_vfio_enable;
rte_vfio_get_container_fd;
rte_vfio_get_group_fd;
rte_vfio_get_group_num;
-
-} DPDK_18.05;
-
-DPDK_18.11 {
- global:
-
- rte_dev_probe;
- rte_dev_remove;
- rte_eal_get_runtime_dir;
- rte_eal_hotplug_add;
- rte_eal_hotplug_remove;
- rte_strscpy;
-
-} DPDK_18.08;
-
-DPDK_19.05 {
- global:
-
- rte_ctrl_thread_create;
- rte_dev_is_probed;
- rte_devargs_add;
- rte_devargs_dump;
- rte_devargs_insert;
- rte_devargs_next;
- rte_devargs_parse;
- rte_devargs_parsef;
- rte_devargs_remove;
- rte_devargs_type_count;
- rte_eal_cleanup;
- rte_socket_count;
- rte_socket_id_by_idx;
-
-} DPDK_18.11;
-
-DPDK_19.08 {
- global:
-
- rte_lcore_index;
- rte_lcore_to_socket_id;
- rte_mcfg_mem_read_lock;
- rte_mcfg_mem_read_unlock;
- rte_mcfg_mem_write_lock;
- rte_mcfg_mem_write_unlock;
- rte_mcfg_mempool_read_lock;
- rte_mcfg_mempool_read_unlock;
- rte_mcfg_mempool_write_lock;
- rte_mcfg_mempool_write_unlock;
- rte_mcfg_tailq_read_lock;
- rte_mcfg_tailq_read_unlock;
- rte_mcfg_tailq_write_lock;
- rte_mcfg_tailq_write_unlock;
- rte_rand;
- rte_service_lcore_attr_get;
- rte_service_lcore_attr_reset_all;
- rte_service_may_be_active;
- rte_srand;
-
-} DPDK_19.05;
-
-DPDK_19.11 {
- global:
-
- rte_get_master_lcore;
- rte_get_next_lcore;
- rte_lcore_count;
- rte_lcore_is_enabled;
-
-} DPDK_19.08;
+ rte_vfio_is_enabled;
+ rte_vfio_noiommu_is_enabled;
+ rte_vfio_release_device;
+ rte_vfio_setup_device;
+ rte_vlog;
+ rte_zmalloc;
+ rte_zmalloc_socket;
+
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_efd/rte_efd_version.map b/lib/librte_efd/rte_efd_version.map
index ae60a64178..e010eecfe4 100644
--- a/lib/librte_efd/rte_efd_version.map
+++ b/lib/librte_efd/rte_efd_version.map
@@ -1,4 +1,4 @@
-DPDK_17.02 {
+DPDK_20.0 {
global:
rte_efd_create;
diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
index e59d51648f..28819c1bb7 100644
--- a/lib/librte_ethdev/rte_ethdev_version.map
+++ b/lib/librte_ethdev/rte_ethdev_version.map
@@ -1,35 +1,53 @@
-DPDK_2.2 {
+DPDK_20.0 {
global:
+ _rte_eth_dev_callback_process;
+ _rte_eth_dev_reset;
+ rte_eth_add_first_rx_callback;
rte_eth_add_rx_callback;
rte_eth_add_tx_callback;
rte_eth_allmulticast_disable;
rte_eth_allmulticast_enable;
rte_eth_allmulticast_get;
+ rte_eth_dev_adjust_nb_rx_tx_desc;
rte_eth_dev_allocate;
rte_eth_dev_allocated;
+ rte_eth_dev_attach_secondary;
rte_eth_dev_callback_register;
rte_eth_dev_callback_unregister;
rte_eth_dev_close;
rte_eth_dev_configure;
rte_eth_dev_count;
+ rte_eth_dev_count_avail;
+ rte_eth_dev_count_total;
rte_eth_dev_default_mac_addr_set;
+ rte_eth_dev_filter_ctrl;
rte_eth_dev_filter_supported;
rte_eth_dev_flow_ctrl_get;
rte_eth_dev_flow_ctrl_set;
+ rte_eth_dev_fw_version_get;
rte_eth_dev_get_dcb_info;
rte_eth_dev_get_eeprom;
rte_eth_dev_get_eeprom_length;
rte_eth_dev_get_mtu;
+ rte_eth_dev_get_name_by_port;
+ rte_eth_dev_get_port_by_name;
rte_eth_dev_get_reg_info;
+ rte_eth_dev_get_sec_ctx;
+ rte_eth_dev_get_supported_ptypes;
rte_eth_dev_get_vlan_offload;
- rte_eth_devices;
rte_eth_dev_info_get;
rte_eth_dev_is_valid_port;
+ rte_eth_dev_l2_tunnel_eth_type_conf;
+ rte_eth_dev_l2_tunnel_offload_set;
+ rte_eth_dev_logtype;
rte_eth_dev_mac_addr_add;
rte_eth_dev_mac_addr_remove;
+ rte_eth_dev_pool_ops_supported;
rte_eth_dev_priority_flow_ctrl_set;
+ rte_eth_dev_probing_finish;
rte_eth_dev_release_port;
+ rte_eth_dev_reset;
rte_eth_dev_rss_hash_conf_get;
rte_eth_dev_rss_hash_update;
rte_eth_dev_rss_reta_query;
@@ -38,6 +56,7 @@ DPDK_2.2 {
rte_eth_dev_rx_intr_ctl_q;
rte_eth_dev_rx_intr_disable;
rte_eth_dev_rx_intr_enable;
+ rte_eth_dev_rx_offload_name;
rte_eth_dev_rx_queue_start;
rte_eth_dev_rx_queue_stop;
rte_eth_dev_set_eeprom;
@@ -47,18 +66,28 @@ DPDK_2.2 {
rte_eth_dev_set_mtu;
rte_eth_dev_set_rx_queue_stats_mapping;
rte_eth_dev_set_tx_queue_stats_mapping;
+ rte_eth_dev_set_vlan_ether_type;
rte_eth_dev_set_vlan_offload;
rte_eth_dev_set_vlan_pvid;
rte_eth_dev_set_vlan_strip_on_queue;
rte_eth_dev_socket_id;
rte_eth_dev_start;
rte_eth_dev_stop;
+ rte_eth_dev_tx_offload_name;
rte_eth_dev_tx_queue_start;
rte_eth_dev_tx_queue_stop;
rte_eth_dev_uc_all_hash_table_set;
rte_eth_dev_uc_hash_table_set;
+ rte_eth_dev_udp_tunnel_port_add;
+ rte_eth_dev_udp_tunnel_port_delete;
rte_eth_dev_vlan_filter;
+ rte_eth_devices;
rte_eth_dma_zone_reserve;
+ rte_eth_find_next;
+ rte_eth_find_next_owned_by;
+ rte_eth_iterator_cleanup;
+ rte_eth_iterator_init;
+ rte_eth_iterator_next;
rte_eth_led_off;
rte_eth_led_on;
rte_eth_link;
@@ -75,6 +104,7 @@ DPDK_2.2 {
rte_eth_rx_queue_info_get;
rte_eth_rx_queue_setup;
rte_eth_set_queue_rate_limit;
+ rte_eth_speed_bitflag;
rte_eth_stats;
rte_eth_stats_get;
rte_eth_stats_reset;
@@ -85,66 +115,27 @@ DPDK_2.2 {
rte_eth_timesync_read_time;
rte_eth_timesync_read_tx_timestamp;
rte_eth_timesync_write_time;
- rte_eth_tx_queue_info_get;
- rte_eth_tx_queue_setup;
- rte_eth_xstats_get;
- rte_eth_xstats_reset;
-
- local: *;
-};
-
-DPDK_16.04 {
- global:
-
- rte_eth_dev_get_supported_ptypes;
- rte_eth_dev_l2_tunnel_eth_type_conf;
- rte_eth_dev_l2_tunnel_offload_set;
- rte_eth_dev_set_vlan_ether_type;
- rte_eth_dev_udp_tunnel_port_add;
- rte_eth_dev_udp_tunnel_port_delete;
- rte_eth_speed_bitflag;
rte_eth_tx_buffer_count_callback;
rte_eth_tx_buffer_drop_callback;
rte_eth_tx_buffer_init;
rte_eth_tx_buffer_set_err_callback;
-
-} DPDK_2.2;
-
-DPDK_16.07 {
- global:
-
- rte_eth_add_first_rx_callback;
- rte_eth_dev_get_name_by_port;
- rte_eth_dev_get_port_by_name;
- rte_eth_xstats_get_names;
-
-} DPDK_16.04;
-
-DPDK_17.02 {
- global:
-
- _rte_eth_dev_reset;
- rte_eth_dev_fw_version_get;
-
-} DPDK_16.07;
-
-DPDK_17.05 {
- global:
-
- rte_eth_dev_attach_secondary;
- rte_eth_find_next;
rte_eth_tx_done_cleanup;
+ rte_eth_tx_queue_info_get;
+ rte_eth_tx_queue_setup;
+ rte_eth_xstats_get;
rte_eth_xstats_get_by_id;
rte_eth_xstats_get_id_by_name;
+ rte_eth_xstats_get_names;
rte_eth_xstats_get_names_by_id;
-
-} DPDK_17.02;
-
-DPDK_17.08 {
- global:
-
- _rte_eth_dev_callback_process;
- rte_eth_dev_adjust_nb_rx_tx_desc;
+ rte_eth_xstats_reset;
+ rte_flow_copy;
+ rte_flow_create;
+ rte_flow_destroy;
+ rte_flow_error_set;
+ rte_flow_flush;
+ rte_flow_isolate;
+ rte_flow_query;
+ rte_flow_validate;
rte_tm_capabilities_get;
rte_tm_get_number_of_leaf_nodes;
rte_tm_hierarchy_commit;
@@ -176,65 +167,8 @@ DPDK_17.08 {
rte_tm_wred_profile_add;
rte_tm_wred_profile_delete;
-} DPDK_17.05;
-
-DPDK_17.11 {
- global:
-
- rte_eth_dev_get_sec_ctx;
- rte_eth_dev_pool_ops_supported;
- rte_eth_dev_reset;
-
-} DPDK_17.08;
-
-DPDK_18.02 {
- global:
-
- rte_eth_dev_filter_ctrl;
-
-} DPDK_17.11;
-
-DPDK_18.05 {
- global:
-
- rte_eth_dev_count_avail;
- rte_eth_dev_probing_finish;
- rte_eth_find_next_owned_by;
- rte_flow_copy;
- rte_flow_create;
- rte_flow_destroy;
- rte_flow_error_set;
- rte_flow_flush;
- rte_flow_isolate;
- rte_flow_query;
- rte_flow_validate;
-
-} DPDK_18.02;
-
-DPDK_18.08 {
- global:
-
- rte_eth_dev_logtype;
-
-} DPDK_18.05;
-
-DPDK_18.11 {
- global:
-
- rte_eth_dev_rx_offload_name;
- rte_eth_dev_tx_offload_name;
- rte_eth_iterator_cleanup;
- rte_eth_iterator_init;
- rte_eth_iterator_next;
-
-} DPDK_18.08;
-
-DPDK_19.05 {
- global:
-
- rte_eth_dev_count_total;
-
-} DPDK_18.11;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_eventdev/rte_eventdev_version.map b/lib/librte_eventdev/rte_eventdev_version.map
index 76b3021d3a..edfc15282d 100644
--- a/lib/librte_eventdev/rte_eventdev_version.map
+++ b/lib/librte_eventdev/rte_eventdev_version.map
@@ -1,61 +1,38 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
- rte_eventdevs;
-
+ rte_event_crypto_adapter_caps_get;
+ rte_event_crypto_adapter_create;
+ rte_event_crypto_adapter_create_ext;
+ rte_event_crypto_adapter_event_port_get;
+ rte_event_crypto_adapter_free;
+ rte_event_crypto_adapter_queue_pair_add;
+ rte_event_crypto_adapter_queue_pair_del;
+ rte_event_crypto_adapter_service_id_get;
+ rte_event_crypto_adapter_start;
+ rte_event_crypto_adapter_stats_get;
+ rte_event_crypto_adapter_stats_reset;
+ rte_event_crypto_adapter_stop;
+ rte_event_dequeue_timeout_ticks;
+ rte_event_dev_attr_get;
+ rte_event_dev_close;
+ rte_event_dev_configure;
rte_event_dev_count;
+ rte_event_dev_dump;
rte_event_dev_get_dev_id;
- rte_event_dev_socket_id;
rte_event_dev_info_get;
- rte_event_dev_configure;
+ rte_event_dev_selftest;
+ rte_event_dev_service_id_get;
+ rte_event_dev_socket_id;
rte_event_dev_start;
rte_event_dev_stop;
- rte_event_dev_close;
- rte_event_dev_dump;
+ rte_event_dev_stop_flush_callback_register;
rte_event_dev_xstats_by_name_get;
rte_event_dev_xstats_get;
rte_event_dev_xstats_names_get;
rte_event_dev_xstats_reset;
-
- rte_event_port_default_conf_get;
- rte_event_port_setup;
- rte_event_port_link;
- rte_event_port_unlink;
- rte_event_port_links_get;
-
- rte_event_queue_default_conf_get;
- rte_event_queue_setup;
-
- rte_event_dequeue_timeout_ticks;
-
- rte_event_pmd_allocate;
- rte_event_pmd_release;
- rte_event_pmd_vdev_init;
- rte_event_pmd_vdev_uninit;
- rte_event_pmd_pci_probe;
- rte_event_pmd_pci_remove;
-
- local: *;
-};
-
-DPDK_17.08 {
- global:
-
- rte_event_ring_create;
- rte_event_ring_free;
- rte_event_ring_init;
- rte_event_ring_lookup;
-} DPDK_17.05;
-
-DPDK_17.11 {
- global:
-
- rte_event_dev_attr_get;
- rte_event_dev_service_id_get;
- rte_event_port_attr_get;
- rte_event_queue_attr_get;
-
rte_event_eth_rx_adapter_caps_get;
+ rte_event_eth_rx_adapter_cb_register;
rte_event_eth_rx_adapter_create;
rte_event_eth_rx_adapter_create_ext;
rte_event_eth_rx_adapter_free;
@@ -63,38 +40,9 @@ DPDK_17.11 {
rte_event_eth_rx_adapter_queue_del;
rte_event_eth_rx_adapter_service_id_get;
rte_event_eth_rx_adapter_start;
+ rte_event_eth_rx_adapter_stats_get;
rte_event_eth_rx_adapter_stats_reset;
rte_event_eth_rx_adapter_stop;
-} DPDK_17.08;
-
-DPDK_18.02 {
- global:
-
- rte_event_dev_selftest;
-} DPDK_17.11;
-
-DPDK_18.05 {
- global:
-
- rte_event_dev_stop_flush_callback_register;
-} DPDK_18.02;
-
-DPDK_19.05 {
- global:
-
- rte_event_crypto_adapter_caps_get;
- rte_event_crypto_adapter_create;
- rte_event_crypto_adapter_create_ext;
- rte_event_crypto_adapter_event_port_get;
- rte_event_crypto_adapter_free;
- rte_event_crypto_adapter_queue_pair_add;
- rte_event_crypto_adapter_queue_pair_del;
- rte_event_crypto_adapter_service_id_get;
- rte_event_crypto_adapter_start;
- rte_event_crypto_adapter_stats_get;
- rte_event_crypto_adapter_stats_reset;
- rte_event_crypto_adapter_stop;
- rte_event_port_unlinks_in_progress;
rte_event_eth_tx_adapter_caps_get;
rte_event_eth_tx_adapter_create;
rte_event_eth_tx_adapter_create_ext;
@@ -107,6 +55,26 @@ DPDK_19.05 {
rte_event_eth_tx_adapter_stats_get;
rte_event_eth_tx_adapter_stats_reset;
rte_event_eth_tx_adapter_stop;
+ rte_event_pmd_allocate;
+ rte_event_pmd_pci_probe;
+ rte_event_pmd_pci_remove;
+ rte_event_pmd_release;
+ rte_event_pmd_vdev_init;
+ rte_event_pmd_vdev_uninit;
+ rte_event_port_attr_get;
+ rte_event_port_default_conf_get;
+ rte_event_port_link;
+ rte_event_port_links_get;
+ rte_event_port_setup;
+ rte_event_port_unlink;
+ rte_event_port_unlinks_in_progress;
+ rte_event_queue_attr_get;
+ rte_event_queue_default_conf_get;
+ rte_event_queue_setup;
+ rte_event_ring_create;
+ rte_event_ring_free;
+ rte_event_ring_init;
+ rte_event_ring_lookup;
rte_event_timer_adapter_caps_get;
rte_event_timer_adapter_create;
rte_event_timer_adapter_create_ext;
@@ -121,11 +89,7 @@ DPDK_19.05 {
rte_event_timer_arm_burst;
rte_event_timer_arm_tmo_tick_burst;
rte_event_timer_cancel_burst;
-} DPDK_18.05;
+ rte_eventdevs;
-DPDK_19.08 {
- global:
-
- rte_event_eth_rx_adapter_cb_register;
- rte_event_eth_rx_adapter_stats_get;
-} DPDK_19.05;
+ local: *;
+};
diff --git a/lib/librte_gro/rte_gro_version.map b/lib/librte_gro/rte_gro_version.map
index 1606b6dc72..9f6fe79e57 100644
--- a/lib/librte_gro/rte_gro_version.map
+++ b/lib/librte_gro/rte_gro_version.map
@@ -1,4 +1,4 @@
-DPDK_17.08 {
+DPDK_20.0 {
global:
rte_gro_ctx_create;
diff --git a/lib/librte_gso/rte_gso_version.map b/lib/librte_gso/rte_gso_version.map
index e1fd453edb..8505a59c27 100644
--- a/lib/librte_gso/rte_gso_version.map
+++ b/lib/librte_gso/rte_gso_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
rte_gso_segment;
diff --git a/lib/librte_hash/rte_hash_version.map b/lib/librte_hash/rte_hash_version.map
index 734ae28b04..138c130c1b 100644
--- a/lib/librte_hash/rte_hash_version.map
+++ b/lib/librte_hash/rte_hash_version.map
@@ -1,58 +1,33 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_fbk_hash_create;
rte_fbk_hash_find_existing;
rte_fbk_hash_free;
rte_hash_add_key;
+ rte_hash_add_key_data;
rte_hash_add_key_with_hash;
+ rte_hash_add_key_with_hash_data;
+ rte_hash_count;
rte_hash_create;
rte_hash_del_key;
rte_hash_del_key_with_hash;
rte_hash_find_existing;
rte_hash_free;
+ rte_hash_get_key_with_position;
rte_hash_hash;
+ rte_hash_iterate;
rte_hash_lookup;
rte_hash_lookup_bulk;
- rte_hash_lookup_with_hash;
-
- local: *;
-};
-
-DPDK_2.1 {
- global:
-
- rte_hash_add_key_data;
- rte_hash_add_key_with_hash_data;
- rte_hash_iterate;
rte_hash_lookup_bulk_data;
rte_hash_lookup_data;
+ rte_hash_lookup_with_hash;
rte_hash_lookup_with_hash_data;
rte_hash_reset;
-
-} DPDK_2.0;
-
-DPDK_2.2 {
- global:
-
rte_hash_set_cmp_func;
-} DPDK_2.1;
-
-DPDK_16.07 {
- global:
-
- rte_hash_get_key_with_position;
-
-} DPDK_2.2;
-
-
-DPDK_18.08 {
- global:
-
- rte_hash_count;
-
-} DPDK_16.07;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_ip_frag/rte_ip_frag_version.map b/lib/librte_ip_frag/rte_ip_frag_version.map
index a193007c61..5dd34f828c 100644
--- a/lib/librte_ip_frag/rte_ip_frag_version.map
+++ b/lib/librte_ip_frag/rte_ip_frag_version.map
@@ -1,8 +1,9 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_ip_frag_free_death_row;
rte_ip_frag_table_create;
+ rte_ip_frag_table_destroy;
rte_ip_frag_table_statistics_dump;
rte_ipv4_frag_reassemble_packet;
rte_ipv4_fragment_packet;
@@ -12,13 +13,6 @@ DPDK_2.0 {
local: *;
};
-DPDK_17.08 {
- global:
-
- rte_ip_frag_table_destroy;
-
-} DPDK_2.0;
-
EXPERIMENTAL {
global:
diff --git a/lib/librte_jobstats/rte_jobstats_version.map b/lib/librte_jobstats/rte_jobstats_version.map
index f89441438e..dbd2664ae2 100644
--- a/lib/librte_jobstats/rte_jobstats_version.map
+++ b/lib/librte_jobstats/rte_jobstats_version.map
@@ -1,6 +1,7 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
+ rte_jobstats_abort;
rte_jobstats_context_finish;
rte_jobstats_context_init;
rte_jobstats_context_reset;
@@ -17,10 +18,3 @@ DPDK_2.0 {
local: *;
};
-
-DPDK_16.04 {
- global:
-
- rte_jobstats_abort;
-
-} DPDK_2.0;
diff --git a/lib/librte_kni/rte_kni_version.map b/lib/librte_kni/rte_kni_version.map
index c877dc6aaa..9cd3cedc54 100644
--- a/lib/librte_kni/rte_kni_version.map
+++ b/lib/librte_kni/rte_kni_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_kni_alloc;
diff --git a/lib/librte_kvargs/rte_kvargs_version.map b/lib/librte_kvargs/rte_kvargs_version.map
index 8f4b4e3f8f..3ba0f4b59c 100644
--- a/lib/librte_kvargs/rte_kvargs_version.map
+++ b/lib/librte_kvargs/rte_kvargs_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_kvargs_count;
@@ -15,4 +15,4 @@ EXPERIMENTAL {
rte_kvargs_parse_delim;
rte_kvargs_strcmp;
-} DPDK_2.0;
+};
diff --git a/lib/librte_latencystats/rte_latencystats_version.map b/lib/librte_latencystats/rte_latencystats_version.map
index ac8403e821..e04e63463f 100644
--- a/lib/librte_latencystats/rte_latencystats_version.map
+++ b/lib/librte_latencystats/rte_latencystats_version.map
@@ -1,4 +1,4 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
rte_latencystats_get;
diff --git a/lib/librte_lpm/rte_lpm_version.map b/lib/librte_lpm/rte_lpm_version.map
index 90beac853d..500f58b806 100644
--- a/lib/librte_lpm/rte_lpm_version.map
+++ b/lib/librte_lpm/rte_lpm_version.map
@@ -1,13 +1,6 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
- rte_lpm_add;
- rte_lpm_create;
- rte_lpm_delete;
- rte_lpm_delete_all;
- rte_lpm_find_existing;
- rte_lpm_free;
- rte_lpm_is_rule_present;
rte_lpm6_add;
rte_lpm6_create;
rte_lpm6_delete;
@@ -18,29 +11,13 @@ DPDK_2.0 {
rte_lpm6_is_rule_present;
rte_lpm6_lookup;
rte_lpm6_lookup_bulk_func;
+ rte_lpm_add;
+ rte_lpm_create;
+ rte_lpm_delete;
+ rte_lpm_delete_all;
+ rte_lpm_find_existing;
+ rte_lpm_free;
+ rte_lpm_is_rule_present;
local: *;
};
-
-DPDK_16.04 {
- global:
-
- rte_lpm_add;
- rte_lpm_find_existing;
- rte_lpm_create;
- rte_lpm_free;
- rte_lpm_is_rule_present;
- rte_lpm_delete;
- rte_lpm_delete_all;
-
-} DPDK_2.0;
-
-DPDK_17.05 {
- global:
-
- rte_lpm6_add;
- rte_lpm6_is_rule_present;
- rte_lpm6_lookup;
- rte_lpm6_lookup_bulk_func;
-
-} DPDK_16.04;
diff --git a/lib/librte_mbuf/rte_mbuf_version.map b/lib/librte_mbuf/rte_mbuf_version.map
index 263dc0a21e..3bbb476975 100644
--- a/lib/librte_mbuf/rte_mbuf_version.map
+++ b/lib/librte_mbuf/rte_mbuf_version.map
@@ -1,26 +1,7 @@
-DPDK_2.0 {
- global:
-
- rte_get_rx_ol_flag_name;
- rte_get_tx_ol_flag_name;
- rte_mbuf_sanity_check;
- rte_pktmbuf_dump;
- rte_pktmbuf_init;
- rte_pktmbuf_pool_init;
-
- local: *;
-};
-
-DPDK_2.1 {
- global:
-
- rte_pktmbuf_pool_create;
-
-} DPDK_2.0;
-
-DPDK_16.11 {
+DPDK_20.0 {
global:
+ __rte_pktmbuf_linearize;
__rte_pktmbuf_read;
rte_get_ptype_inner_l2_name;
rte_get_ptype_inner_l3_name;
@@ -31,28 +12,24 @@ DPDK_16.11 {
rte_get_ptype_name;
rte_get_ptype_tunnel_name;
rte_get_rx_ol_flag_list;
+ rte_get_rx_ol_flag_name;
rte_get_tx_ol_flag_list;
-
-} DPDK_2.1;
-
-DPDK_18.08 {
- global:
-
+ rte_get_tx_ol_flag_name;
rte_mbuf_best_mempool_ops;
rte_mbuf_platform_mempool_ops;
+ rte_mbuf_sanity_check;
rte_mbuf_set_platform_mempool_ops;
rte_mbuf_set_user_mempool_ops;
rte_mbuf_user_mempool_ops;
- rte_pktmbuf_pool_create_by_ops;
-} DPDK_16.11;
-
-DPDK_19.11 {
- global:
-
- __rte_pktmbuf_linearize;
rte_pktmbuf_clone;
+ rte_pktmbuf_dump;
+ rte_pktmbuf_init;
+ rte_pktmbuf_pool_create;
+ rte_pktmbuf_pool_create_by_ops;
+ rte_pktmbuf_pool_init;
-} DPDK_18.08;
+ local: *;
+};
EXPERIMENTAL {
global:
@@ -68,4 +45,4 @@ EXPERIMENTAL {
rte_pktmbuf_copy;
rte_pktmbuf_free_bulk;
-} DPDK_18.08;
+};
diff --git a/lib/librte_member/rte_member_version.map b/lib/librte_member/rte_member_version.map
index 019e4cd962..87780ae611 100644
--- a/lib/librte_member/rte_member_version.map
+++ b/lib/librte_member/rte_member_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
rte_member_add;
diff --git a/lib/librte_mempool/rte_mempool_version.map b/lib/librte_mempool/rte_mempool_version.map
index ce9e791e78..d002dfc46f 100644
--- a/lib/librte_mempool/rte_mempool_version.map
+++ b/lib/librte_mempool/rte_mempool_version.map
@@ -1,57 +1,39 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_mempool_audit;
- rte_mempool_calc_obj_size;
- rte_mempool_create;
- rte_mempool_dump;
- rte_mempool_list_dump;
- rte_mempool_lookup;
- rte_mempool_walk;
-
- local: *;
-};
-
-DPDK_16.07 {
- global:
-
rte_mempool_avail_count;
rte_mempool_cache_create;
rte_mempool_cache_flush;
rte_mempool_cache_free;
+ rte_mempool_calc_obj_size;
rte_mempool_check_cookies;
+ rte_mempool_contig_blocks_check_cookies;
+ rte_mempool_create;
rte_mempool_create_empty;
rte_mempool_default_cache;
+ rte_mempool_dump;
rte_mempool_free;
rte_mempool_generic_get;
rte_mempool_generic_put;
rte_mempool_in_use_count;
+ rte_mempool_list_dump;
+ rte_mempool_lookup;
rte_mempool_mem_iter;
rte_mempool_obj_iter;
+ rte_mempool_op_calc_mem_size_default;
+ rte_mempool_op_populate_default;
rte_mempool_ops_table;
rte_mempool_populate_anon;
rte_mempool_populate_default;
+ rte_mempool_populate_iova;
rte_mempool_populate_virt;
rte_mempool_register_ops;
rte_mempool_set_ops_byname;
+ rte_mempool_walk;
-} DPDK_2.0;
-
-DPDK_17.11 {
- global:
-
- rte_mempool_populate_iova;
-
-} DPDK_16.07;
-
-DPDK_18.05 {
- global:
-
- rte_mempool_contig_blocks_check_cookies;
- rte_mempool_op_calc_mem_size_default;
- rte_mempool_op_populate_default;
-
-} DPDK_17.11;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_meter/rte_meter_version.map b/lib/librte_meter/rte_meter_version.map
index 4b460d5803..46410b0369 100644
--- a/lib/librte_meter/rte_meter_version.map
+++ b/lib/librte_meter/rte_meter_version.map
@@ -1,21 +1,16 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_meter_srtcm_color_aware_check;
rte_meter_srtcm_color_blind_check;
rte_meter_srtcm_config;
+ rte_meter_srtcm_profile_config;
rte_meter_trtcm_color_aware_check;
rte_meter_trtcm_color_blind_check;
rte_meter_trtcm_config;
-
- local: *;
-};
-
-DPDK_18.08 {
- global:
-
- rte_meter_srtcm_profile_config;
rte_meter_trtcm_profile_config;
+
+ local: *;
};
EXPERIMENTAL {
diff --git a/lib/librte_metrics/rte_metrics_version.map b/lib/librte_metrics/rte_metrics_version.map
index 6ac99a44a1..85663f356e 100644
--- a/lib/librte_metrics/rte_metrics_version.map
+++ b/lib/librte_metrics/rte_metrics_version.map
@@ -1,4 +1,4 @@
-DPDK_17.05 {
+DPDK_20.0 {
global:
rte_metrics_get_names;
diff --git a/lib/librte_net/rte_net_version.map b/lib/librte_net/rte_net_version.map
index fffc4a3723..8a4e75a3a0 100644
--- a/lib/librte_net/rte_net_version.map
+++ b/lib/librte_net/rte_net_version.map
@@ -1,25 +1,14 @@
-DPDK_16.11 {
- global:
- rte_net_get_ptype;
-
- local: *;
-};
-
-DPDK_17.05 {
- global:
-
- rte_net_crc_calc;
- rte_net_crc_set_alg;
-
-} DPDK_16.11;
-
-DPDK_19.08 {
+DPDK_20.0 {
global:
rte_eth_random_addr;
rte_ether_format_addr;
+ rte_net_crc_calc;
+ rte_net_crc_set_alg;
+ rte_net_get_ptype;
-} DPDK_17.05;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_pci/rte_pci_version.map b/lib/librte_pci/rte_pci_version.map
index 03790cb0f0..67eb845796 100644
--- a/lib/librte_pci/rte_pci_version.map
+++ b/lib/librte_pci/rte_pci_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
pci_map_resource;
diff --git a/lib/librte_pdump/rte_pdump_version.map b/lib/librte_pdump/rte_pdump_version.map
index 3e744f3012..6d02ccce6d 100644
--- a/lib/librte_pdump/rte_pdump_version.map
+++ b/lib/librte_pdump/rte_pdump_version.map
@@ -1,4 +1,4 @@
-DPDK_16.07 {
+DPDK_20.0 {
global:
rte_pdump_disable;
diff --git a/lib/librte_pipeline/rte_pipeline_version.map b/lib/librte_pipeline/rte_pipeline_version.map
index 420f065d6e..64d38afecd 100644
--- a/lib/librte_pipeline/rte_pipeline_version.map
+++ b/lib/librte_pipeline/rte_pipeline_version.map
@@ -1,6 +1,8 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
+ rte_pipeline_ah_packet_drop;
+ rte_pipeline_ah_packet_hijack;
rte_pipeline_check;
rte_pipeline_create;
rte_pipeline_flush;
@@ -9,42 +11,22 @@ DPDK_2.0 {
rte_pipeline_port_in_create;
rte_pipeline_port_in_disable;
rte_pipeline_port_in_enable;
+ rte_pipeline_port_in_stats_read;
rte_pipeline_port_out_create;
rte_pipeline_port_out_packet_insert;
+ rte_pipeline_port_out_stats_read;
rte_pipeline_run;
rte_pipeline_table_create;
rte_pipeline_table_default_entry_add;
rte_pipeline_table_default_entry_delete;
rte_pipeline_table_entry_add;
- rte_pipeline_table_entry_delete;
-
- local: *;
-};
-
-DPDK_2.1 {
- global:
-
- rte_pipeline_port_in_stats_read;
- rte_pipeline_port_out_stats_read;
- rte_pipeline_table_stats_read;
-
-} DPDK_2.0;
-
-DPDK_2.2 {
- global:
-
rte_pipeline_table_entry_add_bulk;
+ rte_pipeline_table_entry_delete;
rte_pipeline_table_entry_delete_bulk;
+ rte_pipeline_table_stats_read;
-} DPDK_2.1;
-
-DPDK_16.04 {
- global:
-
- rte_pipeline_ah_packet_hijack;
- rte_pipeline_ah_packet_drop;
-
-} DPDK_2.2;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_port/rte_port_version.map b/lib/librte_port/rte_port_version.map
index d5989721d7..18c6154672 100644
--- a/lib/librte_port/rte_port_version.map
+++ b/lib/librte_port/rte_port_version.map
@@ -1,65 +1,35 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_port_ethdev_reader_ops;
+ rte_port_ethdev_writer_nodrop_ops;
rte_port_ethdev_writer_ops;
+ rte_port_fd_reader_ops;
+ rte_port_fd_writer_nodrop_ops;
+ rte_port_fd_writer_ops;
+ rte_port_kni_reader_ops;
+ rte_port_kni_writer_nodrop_ops;
+ rte_port_kni_writer_ops;
+ rte_port_ring_multi_reader_ops;
+ rte_port_ring_multi_writer_nodrop_ops;
+ rte_port_ring_multi_writer_ops;
rte_port_ring_reader_ipv4_frag_ops;
+ rte_port_ring_reader_ipv6_frag_ops;
rte_port_ring_reader_ops;
rte_port_ring_writer_ipv4_ras_ops;
+ rte_port_ring_writer_ipv6_ras_ops;
+ rte_port_ring_writer_nodrop_ops;
rte_port_ring_writer_ops;
rte_port_sched_reader_ops;
rte_port_sched_writer_ops;
rte_port_sink_ops;
rte_port_source_ops;
-
- local: *;
-};
-
-DPDK_2.1 {
- global:
-
- rte_port_ethdev_writer_nodrop_ops;
- rte_port_ring_reader_ipv6_frag_ops;
- rte_port_ring_writer_ipv6_ras_ops;
- rte_port_ring_writer_nodrop_ops;
-
-} DPDK_2.0;
-
-DPDK_2.2 {
- global:
-
- rte_port_ring_multi_reader_ops;
- rte_port_ring_multi_writer_ops;
- rte_port_ring_multi_writer_nodrop_ops;
-
-} DPDK_2.1;
-
-DPDK_16.07 {
- global:
-
- rte_port_kni_reader_ops;
- rte_port_kni_writer_ops;
- rte_port_kni_writer_nodrop_ops;
-
-} DPDK_2.2;
-
-DPDK_16.11 {
- global:
-
- rte_port_fd_reader_ops;
- rte_port_fd_writer_ops;
- rte_port_fd_writer_nodrop_ops;
-
-} DPDK_16.07;
-
-DPDK_18.11 {
- global:
-
rte_port_sym_crypto_reader_ops;
- rte_port_sym_crypto_writer_ops;
rte_port_sym_crypto_writer_nodrop_ops;
+ rte_port_sym_crypto_writer_ops;
-} DPDK_16.11;
+ local: *;
+};
EXPERIMENTAL {
global:
diff --git a/lib/librte_power/rte_power_version.map b/lib/librte_power/rte_power_version.map
index 7729838137..55a168f56e 100644
--- a/lib/librte_power/rte_power_version.map
+++ b/lib/librte_power/rte_power_version.map
@@ -1,39 +1,27 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_power_exit;
+ rte_power_freq_disable_turbo;
rte_power_freq_down;
+ rte_power_freq_enable_turbo;
rte_power_freq_max;
rte_power_freq_min;
rte_power_freq_up;
rte_power_freqs;
+ rte_power_get_capabilities;
rte_power_get_env;
rte_power_get_freq;
+ rte_power_guest_channel_send_msg;
rte_power_init;
rte_power_set_env;
rte_power_set_freq;
+ rte_power_turbo_status;
rte_power_unset_env;
local: *;
};
-DPDK_17.11 {
- global:
-
- rte_power_guest_channel_send_msg;
- rte_power_freq_disable_turbo;
- rte_power_freq_enable_turbo;
- rte_power_turbo_status;
-
-} DPDK_2.0;
-
-DPDK_18.08 {
- global:
-
- rte_power_get_capabilities;
-
-} DPDK_17.11;
-
EXPERIMENTAL {
global:
diff --git a/lib/librte_rawdev/rte_rawdev_version.map b/lib/librte_rawdev/rte_rawdev_version.map
index b61dbff11c..d847c9e0d3 100644
--- a/lib/librte_rawdev/rte_rawdev_version.map
+++ b/lib/librte_rawdev/rte_rawdev_version.map
@@ -1,4 +1,4 @@
-DPDK_18.08 {
+DPDK_20.0 {
global:
rte_rawdev_close;
@@ -17,8 +17,8 @@ DPDK_18.08 {
rte_rawdev_pmd_release;
rte_rawdev_queue_conf_get;
rte_rawdev_queue_count;
- rte_rawdev_queue_setup;
rte_rawdev_queue_release;
+ rte_rawdev_queue_setup;
rte_rawdev_reset;
rte_rawdev_selftest;
rte_rawdev_set_attr;
diff --git a/lib/librte_reorder/rte_reorder_version.map b/lib/librte_reorder/rte_reorder_version.map
index 0a8a54de83..cf444062df 100644
--- a/lib/librte_reorder/rte_reorder_version.map
+++ b/lib/librte_reorder/rte_reorder_version.map
@@ -1,13 +1,13 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_reorder_create;
- rte_reorder_init;
+ rte_reorder_drain;
rte_reorder_find_existing;
- rte_reorder_reset;
rte_reorder_free;
+ rte_reorder_init;
rte_reorder_insert;
- rte_reorder_drain;
+ rte_reorder_reset;
local: *;
};
diff --git a/lib/librte_ring/rte_ring_version.map b/lib/librte_ring/rte_ring_version.map
index 510c1386e0..89d84bcf48 100644
--- a/lib/librte_ring/rte_ring_version.map
+++ b/lib/librte_ring/rte_ring_version.map
@@ -1,8 +1,9 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_ring_create;
rte_ring_dump;
+ rte_ring_free;
rte_ring_get_memsize;
rte_ring_init;
rte_ring_list_dump;
@@ -11,13 +12,6 @@ DPDK_2.0 {
local: *;
};
-DPDK_2.2 {
- global:
-
- rte_ring_free;
-
-} DPDK_2.0;
-
EXPERIMENTAL {
global:
diff --git a/lib/librte_sched/rte_sched_version.map b/lib/librte_sched/rte_sched_version.map
index f33761e63e..cefd990367 100644
--- a/lib/librte_sched/rte_sched_version.map
+++ b/lib/librte_sched/rte_sched_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_approx;
@@ -14,6 +14,9 @@ DPDK_2.0 {
rte_sched_port_enqueue;
rte_sched_port_free;
rte_sched_port_get_memory_footprint;
+ rte_sched_port_pkt_read_color;
+ rte_sched_port_pkt_read_tree_path;
+ rte_sched_port_pkt_write;
rte_sched_queue_read_stats;
rte_sched_subport_config;
rte_sched_subport_read_stats;
@@ -21,15 +24,6 @@ DPDK_2.0 {
local: *;
};
-DPDK_2.1 {
- global:
-
- rte_sched_port_pkt_write;
- rte_sched_port_pkt_read_tree_path;
- rte_sched_port_pkt_read_color;
-
-} DPDK_2.0;
-
EXPERIMENTAL {
global:
diff --git a/lib/librte_security/rte_security_version.map b/lib/librte_security/rte_security_version.map
index 53267bf3cc..b07314bbf4 100644
--- a/lib/librte_security/rte_security_version.map
+++ b/lib/librte_security/rte_security_version.map
@@ -1,4 +1,4 @@
-DPDK_18.11 {
+DPDK_20.0 {
global:
rte_security_attach_session;
diff --git a/lib/librte_table/rte_table_version.map b/lib/librte_table/rte_table_version.map
index 6237252bec..40f72b1fe8 100644
--- a/lib/librte_table/rte_table_version.map
+++ b/lib/librte_table/rte_table_version.map
@@ -1,4 +1,4 @@
-DPDK_17.11 {
+DPDK_20.0 {
global:
rte_table_acl_ops;
diff --git a/lib/librte_timer/rte_timer_version.map b/lib/librte_timer/rte_timer_version.map
index 72f75c8181..2a59d3f081 100644
--- a/lib/librte_timer/rte_timer_version.map
+++ b/lib/librte_timer/rte_timer_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
rte_timer_dump_stats;
@@ -14,16 +14,6 @@ DPDK_2.0 {
local: *;
};
-DPDK_19.05 {
- global:
-
- rte_timer_dump_stats;
- rte_timer_manage;
- rte_timer_reset;
- rte_timer_stop;
- rte_timer_subsystem_init;
-} DPDK_2.0;
-
EXPERIMENTAL {
global:
diff --git a/lib/librte_vhost/rte_vhost_version.map b/lib/librte_vhost/rte_vhost_version.map
index ce517b1271..c512377fe6 100644
--- a/lib/librte_vhost/rte_vhost_version.map
+++ b/lib/librte_vhost/rte_vhost_version.map
@@ -1,64 +1,34 @@
-DPDK_2.0 {
+DPDK_20.0 {
global:
+ rte_vhost_avail_entries;
rte_vhost_dequeue_burst;
rte_vhost_driver_callback_register;
- rte_vhost_driver_register;
- rte_vhost_enable_guest_notification;
- rte_vhost_enqueue_burst;
-
- local: *;
-};
-
-DPDK_2.1 {
- global:
-
- rte_vhost_driver_unregister;
-
-} DPDK_2.0;
-
-DPDK_16.07 {
- global:
-
- rte_vhost_avail_entries;
- rte_vhost_get_ifname;
- rte_vhost_get_numa_node;
- rte_vhost_get_queue_num;
-
-} DPDK_2.1;
-
-DPDK_17.05 {
- global:
-
rte_vhost_driver_disable_features;
rte_vhost_driver_enable_features;
rte_vhost_driver_get_features;
+ rte_vhost_driver_register;
rte_vhost_driver_set_features;
rte_vhost_driver_start;
+ rte_vhost_driver_unregister;
+ rte_vhost_enable_guest_notification;
+ rte_vhost_enqueue_burst;
+ rte_vhost_get_ifname;
rte_vhost_get_mem_table;
rte_vhost_get_mtu;
rte_vhost_get_negotiated_features;
+ rte_vhost_get_numa_node;
+ rte_vhost_get_queue_num;
rte_vhost_get_vhost_vring;
rte_vhost_get_vring_num;
rte_vhost_gpa_to_vva;
rte_vhost_log_used_vring;
rte_vhost_log_write;
-
-} DPDK_16.07;
-
-DPDK_17.08 {
- global:
-
rte_vhost_rx_queue_count;
-
-} DPDK_17.05;
-
-DPDK_18.02 {
- global:
-
rte_vhost_vring_call;
-} DPDK_17.08;
+ local: *;
+};
EXPERIMENTAL {
global:
--
2.17.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps
2019-11-06 13:58 3% ` David Marchand
@ 2019-11-06 15:27 0% ` Rajesh Ravi
0 siblings, 0 replies; 200+ results
From: Rajesh Ravi @ 2019-11-06 15:27 UTC (permalink / raw)
To: David Marchand
Cc: Burakov, Anatoly, dev, Bruce Richardson, Ajit Khaparde,
Jonathan Richardson, Scott Branden, Vikram Mysore Prakash,
Srinath Mannam, Thomas Monjalon
Thanks Anatoly & David.
The main patch provided by Anatoly is not compatible with DPDK 19.02.
So I had to make following patch and verified it to be working with DPDK
19.02 & SPDK 19.07 combination.
------------------------------------------------------------------------------------------------------------------------------------------------------------------
diff --git a/lib/librte_eal/common/include/rte_eal_memconfig.h
b/lib/librte_eal/common/include/rte_eal_memconfig.h
index 84aabe3..49934f5 100644
--- a/lib/librte_eal/common/include/rte_eal_memconfig.h
+++ b/lib/librte_eal/common/include/rte_eal_memconfig.h
@@ -35,6 +35,7 @@ struct rte_memseg_list {
volatile uint32_t version; /**< version number for multiprocess sync. */
size_t len; /**< Length of memory area covered by this memseg list. */
unsigned int external; /**< 1 if this list points to external memory */
+ unsigned int heap; /**< 1 if this list points to a heap */
struct rte_fbarray memseg_arr;
};
diff --git a/lib/librte_eal/common/rte_malloc.c
b/lib/librte_eal/common/rte_malloc.c
index b39de3c..4d31bf7 100644
--- a/lib/librte_eal/common/rte_malloc.c
+++ b/lib/librte_eal/common/rte_malloc.c
@@ -368,6 +368,7 @@ void rte_free(void *addr)
rte_spinlock_lock(&heap->lock);
ret = malloc_heap_add_external_memory(heap, msl);
+ msl->heap = 1; /* mark it as heap segment */
rte_spinlock_unlock(&heap->lock);
unlock:
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 1b96b57..33dd923 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -836,6 +836,7 @@ void numa_error(char *where)
msl->page_sz = page_sz;
msl->socket_id = socket_id;
msl->base_va = NULL;
+ msl->heap = 1; /* mark it as a heap segment */
RTE_LOG(DEBUG, EAL, "Memseg list allocated: 0x%zxkB at socket %i\n",
(size_t)page_sz >> 10, socket_id);
@@ -1410,6 +1411,7 @@ void numa_error(char *where)
msl->page_sz = page_sz;
msl->socket_id = 0;
msl->len = internal_config.memory;
+ msl->heap = 1;
/* we're in single-file segments mode, so only the segment list
* fd needs to be set up.
@@ -1682,6 +1684,7 @@ void numa_error(char *where)
mem_sz = msl->len;
munmap(msl->base_va, mem_sz);
msl->base_va = NULL;
+ msl->heap = 0;
/* destroy backing fbarray */
rte_fbarray_destroy(&msl->memseg_arr);
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_vfio.c
index 61b54f9..3bb3e6b 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -1238,7 +1238,16 @@ static int vfio_dma_mem_map(struct vfio_config
*vfio_cfg, uint64_t vaddr,
{
int *vfio_container_fd = arg;
- if (msl->external & !internal_config.iso_cmem)
+ /* skip external memory that isn't a heap */
+ if (msl->external && !msl->heap)
+ return 0;
+
+ /* skip any segments with invalid IOVA addresses */
+ if (ms->iova == RTE_BAD_IOVA)
+ return 0;
+
+ /* if IOVA mode is VA, we've already mapped the internal segments */
+ if (!msl->external && rte_eal_iova_mode() == RTE_IOVA_VA)
return 0;
return vfio_type1_dma_mem_map(*vfio_container_fd, ms->addr_64, ms->iova,
@@ -1362,9 +1371,19 @@ static int vfio_dma_mem_map(struct vfio_config
*vfio_cfg, uint64_t vaddr,
{
int *vfio_container_fd = arg;
- if (msl->external)
+ /* skip external memory that isn't a heap */
+ if (msl->external && !msl->heap)
return 0;
+ /* skip any segments with invalid IOVA addresses */
+ if (ms->iova == RTE_BAD_IOVA)
+ return 0;
+
+#if 0
+ if (ms->addr_64 == param->addr_64)
+ return 0;
+#endif
+
return vfio_spapr_dma_do_map(*vfio_container_fd, ms->addr_64, ms->iova,
ms->len, 1);
}
@@ -1381,6 +1400,12 @@ struct spapr_walk_param {
uint64_t max = ms->iova + ms->len;
if (msl->external)
+ /* skip external memory that isn't a heap */
+ if (msl->external && !msl->heap)
+ return 0;
+
+ /* skip any segments with invalid IOVA addresses */
+ if (ms->iova == RTE_BAD_IOVA)
return 0;
if (max > param->window_size) {
------------------------------------------------------------------------------------------------------------------------------------------------------------------
Regards,
Rajesh
On Wed, Nov 6, 2019 at 7:28 PM David Marchand <david.marchand@redhat.com>
wrote:
> On Tue, Nov 5, 2019 at 6:15 PM Burakov, Anatoly
> <anatoly.burakov@intel.com> wrote:
> >
> > On 05-Nov-19 3:15 PM, Anatoly Burakov wrote:
> > > Currently, externally created heaps are supposed to be automatically
> > > mapped for VFIO DMA by EAL, however they only do so if, at the time of
> > > heap creation, VFIO is initialized and has at least one device
> > > available. If no devices are available at the time of heap creation (or
> > > if devices were available, but were since hot-unplugged, thus dropping
> > > all VFIO container mappings), then VFIO mapping code would have skipped
> > > over externally allocated heaps.
> > >
> > > The fix is two-fold. First, we allow externally allocated memory
> > > segments to be marked as "heap" segments. This allows us to distinguish
> > > between external memory segments that were created via heap API, from
> > > those that were created via rte_extmem_register() API.
> > >
> > > Then, we fix the VFIO code to only skip non-heap external segments.
> > > Also, since external heaps are not guaranteed to have valid IOVA
> > > addresses, we will skip those which have invalid IOVA addresses as
> well.
> > >
> > > Fixes: 0f526d674f8e ("malloc: separate creating memseg list and malloc
> heap")
> > >
> > > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > > ---
> > >
> > > Notes:
> > > This cannot be backported to older releases as it breaks the
> > > API and ABI. A separate fix is in the works for stable.
> > >
> >
> > Alternative, non-breaking implementation available (which will be slower
> > due to O(N) memseg list heaps lookups):
> >
> > http://patches.dpdk.org/patch/62486/
> >
> > I'm fine with either option being merged.
> >
> > The more perfect solution would've been to rename "msl->external" into
> > "msl->flags" and have various flags for memseg lists, but it's too late
> > to break the API now.
>
> Either way is fine for me (between the 18.11 and the master patches you
> sent).
> Breaking the ABI is acceptable, but I agree the API is another story.
>
> If the code seems better to you with the additional heap flag, let's go
> for it.
>
> I would still like to hear from Rajesh though, since he seems to be
> the first to hit this issue.
>
>
> --
> David Marchand
>
>
--
Regards,
Rajesh
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] eal: add option --iso-cmem for external custom memory
2019-11-05 11:41 4% ` Burakov, Anatoly
@ 2019-11-05 14:10 0% ` Rajesh Ravi
0 siblings, 0 replies; 200+ results
From: Rajesh Ravi @ 2019-11-05 14:10 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ajit Khaparde, dev, Jonathan Richardson, Scott Branden,
Vikram Mysore Prakash, Srinath Mannam
Thanks a lot Anatoly.
Will the same solution work with DPDK 19.02 as well? We 're actually using
DPDK 19.02 for memory allocations for SPDK 19.07.
DPDK 19.11 may not be supported by SPDK 19.07 we 're currently using.
I 'll definitely test if the patch works with DPDK 19.02
Thanks again for your time and help.
Regards,
Rajesh
On Tue, Nov 5, 2019 at 5:11 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> On 04-Nov-19 10:25 AM, Burakov, Anatoly wrote:
> > On 30-Oct-19 7:50 PM, Rajesh Ravi wrote:
> >> Thanks Anatoly.
> >> Please find inline below:
> >>
> >> [Anatoly] vfio_mem_event_callback() is called every time memory is
> >> added to a
> >> heap. That includes internal and external memory
> >>
> >> [Rajesh] malloc_heap_add_external_memory() does call
> >> eal_memalloc_mem_event_notify [ instead of vfio_mem_event_callback() ]
> >> But, no callback function is getting called from inside
> >> eal_memalloc_mem_event_notify()
> >> execution flow is not entering inside following loop:
> >>
> >> /TAILQ_FOREACH(entry, &mem_event_callback_list, next) {/
> >> / RTE_LOG(DEBUG, EAL, "Calling mem event callback
> >> '%s:%p'\n",
> >> entry->name, entry->arg);
> >> entry->clb(event, start, len, entry->arg);
> >> }/
> >>
> >> Do you mean to say, we are supposed to explicitly register a callback
> >> which separately builds iommu tables in addition to calling
> >> rte_malloc_heap_memory_add() API?
> >
> > Hi,
> >
> > No, the callback in VFIO should be registered automatically [1] at EAL
> > initialization (or, more precisely, when default container is
> > initialized). Does that not happen in your case?
> >
> > [1]
> http://git.dpdk.org/dpdk/tree/lib/librte_eal/linux/eal/eal_vfio.c#n791
> >
>
> Hi Rajesh,
>
> I think i figured it out. It is a defect in design of how external
> memory heaps are handled.
>
> When VFIO initializes, it will find first VFIO-bound device, initialize
> the container, and set up DMA mappings. Then, you can add more memory
> through creating custom memory regions without adding them to heap
> (mmap() + rte_extmem_register() + rte_dev_dma_map()), or with adding
> them to heap (mmap() + rte_malloc_heap_add_memory()).
>
> The problem is, memory registered through rte_dev_dma_map() will get
> added into a list of user maps, while heap memory will not - the
> assumption is that the DMA mapping will happen through the callback, but
> there is no record left anywhere that this memory is supposed to be mapped.
>
> This makes it so that, if there are no VFIO-bound devices at startup,
> then you create a heap, and *then* you hotplug a device, the heap will
> not be mapped because (as you have correctly pointed out) type1_map()
> skips it, and it's not present in a list of user mem maps either,
> because it is heap memory, so EAL is supposed to handle it by itself and
> not through user map list.
>
> There could be two fixes here. The easiest one is to just add another
> flag to the memseglist - that will work for 19.11, and that's what i
> intend on doing since we're breaking ABI anyway.
>
> For older releases, a different approach would be required (i think
> scanning heaps is best we can do here) in order to keep the ABI and not
> introduce new stuff into rte_memseg_list.
>
> I'll submit a patch shortly, it would be great if you could test it.
>
> --
> Thanks,
> Anatoly
>
--
Regards,
Rajesh
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v6 10/10] buildtools: add ABI versioning check script
` (11 preceding siblings ...)
2019-11-06 16:54 2% ` [dpdk-dev] [PATCH v6 09/10] build: change ABI version to 20.0 Anatoly Burakov
@ 2019-11-06 16:54 23% ` Anatoly Burakov
12 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-06 16:54 UTC (permalink / raw)
To: dev
Cc: Marcin Baran, john.mcnamara, ray.kinsella, bruce.richardson,
thomas, david.marchand, Pawel Modrak
From: Marcin Baran <marcinx.baran@intel.com>
Add a shell script that checks whether built libraries are
versioned with expected ABI (current ABI, current ABI + 1,
or EXPERIMENTAL).
The following command was used to verify current source tree
(assuming build directory is in ./build):
find ./build/lib ./build/drivers -name \*.so \
-exec ./buildtools/check-abi-version.sh {} \; -print
Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
Signed-off-by: Pawel Modrak <pawelx.modrak@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
Notes:
v2:
- Moved this to the end of the patchset
- Fixed bug when ABI symbols were not found because the .so
did not declare any public symbols
buildtools/check-abi-version.sh | 54 +++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100755 buildtools/check-abi-version.sh
diff --git a/buildtools/check-abi-version.sh b/buildtools/check-abi-version.sh
new file mode 100755
index 0000000000..29aea97735
--- /dev/null
+++ b/buildtools/check-abi-version.sh
@@ -0,0 +1,54 @@
+#!/bin/sh
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+
+# Check whether library symbols have correct
+# version (provided ABI number or provided ABI
+# number + 1 or EXPERIMENTAL).
+# Args:
+# $1: path of the library .so file
+# $2: ABI major version number to check
+# (defaults to ABI_VERSION file value)
+
+if [ -z "$1" ]; then
+ echo "Script checks whether library symbols have"
+ echo "correct version (ABI_VER/ABI_VER+1/EXPERIMENTAL)"
+ echo "Usage:"
+ echo " $0 SO_FILE_PATH [ABI_VER]"
+ exit 1
+fi
+
+LIB="$1"
+DEFAULT_ABI=$(cat "$(dirname \
+ $(readlink -f $0))/../config/ABI_VERSION" | \
+ cut -d'.' -f 1)
+ABIVER="DPDK_${2-$DEFAULT_ABI}"
+NEXT_ABIVER="DPDK_$((${2-$DEFAULT_ABI}+1))"
+
+ret=0
+
+# get output of objdump
+OBJ_DUMP_OUTPUT=`objdump -TC --section=.text ${LIB} 2>&1 | grep ".text"`
+
+# there may not be any .text sections in the .so file, in which case exit early
+echo "${OBJ_DUMP_OUTPUT}" | grep "not found in any input file" -q
+if [ "$?" -eq 0 ]; then
+ exit 0
+fi
+
+# we have symbols, so let's see if the versions are correct
+for SYM in `echo "${OBJ_DUMP_OUTPUT}" | awk '{print $(NF-1) "-" $NF}'`
+do
+ version=$(echo $SYM | cut -d'-' -f 1)
+ symbol=$(echo $SYM | cut -d'-' -f 2)
+ case $version in (*"$ABIVER"*|*"$NEXT_ABIVER"*|"EXPERIMENTAL")
+ ;;
+ (*)
+ echo "Warning: symbol $symbol ($version) should be annotated " \
+ "as ABI version $ABIVER / $NEXT_ABIVER, or EXPERIMENTAL."
+ ret=1
+ ;;
+ esac
+done
+
+exit $ret
--
2.17.1
^ permalink raw reply [relevance 23%]
* [dpdk-dev] [PATCH v6 08/10] drivers/octeontx: add missing public symbol
` (9 preceding siblings ...)
2019-11-06 16:54 6% ` [dpdk-dev] [PATCH v6 07/10] distributor: rename v2.0 ABI to _single suffix Anatoly Burakov
@ 2019-11-06 16:54 3% ` Anatoly Burakov
2019-11-06 16:54 2% ` [dpdk-dev] [PATCH v6 09/10] build: change ABI version to 20.0 Anatoly Burakov
2019-11-06 16:54 23% ` [dpdk-dev] [PATCH v6 10/10] buildtools: add ABI versioning check script Anatoly Burakov
12 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-06 16:54 UTC (permalink / raw)
To: dev
Cc: Jerin Jacob, john.mcnamara, ray.kinsella, bruce.richardson,
thomas, david.marchand, pbhagavatula, stable
The logtype symbol was missing from the .map file. Add it.
Fixes: d8dd31652cf4 ("common/octeontx: move mbox to common folder")
Cc: pbhagavatula@caviumnetworks.com
Cc: stable@dpdk.org
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
Notes:
v2:
- add this patch to avoid compile breakage when bumping ABI
drivers/common/octeontx/rte_common_octeontx_version.map | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/common/octeontx/rte_common_octeontx_version.map b/drivers/common/octeontx/rte_common_octeontx_version.map
index f04b3b7f8a..a9b3cff9bc 100644
--- a/drivers/common/octeontx/rte_common_octeontx_version.map
+++ b/drivers/common/octeontx/rte_common_octeontx_version.map
@@ -1,6 +1,7 @@
DPDK_18.05 {
global:
+ octeontx_logtype_mbox;
octeontx_mbox_set_ram_mbox_base;
octeontx_mbox_set_reg;
octeontx_mbox_send;
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v6 07/10] distributor: rename v2.0 ABI to _single suffix
` (8 preceding siblings ...)
2019-11-06 16:54 4% ` [dpdk-dev] [PATCH v6 06/10] distributor: " Anatoly Burakov
@ 2019-11-06 16:54 6% ` Anatoly Burakov
2019-11-06 16:54 3% ` [dpdk-dev] [PATCH v6 08/10] drivers/octeontx: add missing public symbol Anatoly Burakov
` (2 subsequent siblings)
12 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-06 16:54 UTC (permalink / raw)
To: dev
Cc: Marcin Baran, David Hunt, john.mcnamara, ray.kinsella,
bruce.richardson, thomas, david.marchand
From: Marcin Baran <marcinx.baran@intel.com>
The original ABI versioning was slightly misleading in that the
DPDK 2.0 ABI was really a single mode for the distributor, and is
used as such throughout the distributor code.
Fix this by renaming all _v20 API's to _single API's, and remove
symbol versioning.
Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: David Hunt <david.hunt@intel.com>
---
Notes:
v4:
- Changed it back to how it was with v2
- Removed remaining v2.0 symbols
v3:
- Removed single mode from distributor as per Dave's comments
v2:
- Moved this to before ABI version bump to avoid compile breakage
lib/librte_distributor/Makefile | 2 +-
lib/librte_distributor/distributor_private.h | 10 ++--
lib/librte_distributor/meson.build | 2 +-
lib/librte_distributor/rte_distributor.c | 24 +++++-----
...ributor_v20.c => rte_distributor_single.c} | 48 +++++++++----------
...ributor_v20.h => rte_distributor_single.h} | 26 +++++-----
.../rte_distributor_version.map | 18 +------
7 files changed, 58 insertions(+), 72 deletions(-)
rename lib/librte_distributor/{rte_distributor_v20.c => rte_distributor_single.c} (88%)
rename lib/librte_distributor/{rte_distributor_v20.h => rte_distributor_single.h} (89%)
diff --git a/lib/librte_distributor/Makefile b/lib/librte_distributor/Makefile
index 0ef80dcff4..d9d0089166 100644
--- a/lib/librte_distributor/Makefile
+++ b/lib/librte_distributor/Makefile
@@ -15,7 +15,7 @@ EXPORT_MAP := rte_distributor_version.map
LIBABIVER := 1
# all source are stored in SRCS-y
-SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) := rte_distributor_v20.c
+SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) := rte_distributor_single.c
SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += rte_distributor.c
ifeq ($(CONFIG_RTE_ARCH_X86),y)
SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += rte_distributor_match_sse.c
diff --git a/lib/librte_distributor/distributor_private.h b/lib/librte_distributor/distributor_private.h
index c89371123e..489aef2acb 100644
--- a/lib/librte_distributor/distributor_private.h
+++ b/lib/librte_distributor/distributor_private.h
@@ -55,7 +55,7 @@ extern "C" {
* the next cache line to worker 0, we pad this out to three cache lines.
* Only 64-bits of the memory is actually used though.
*/
-union rte_distributor_buffer_v20 {
+union rte_distributor_buffer_single {
volatile int64_t bufptr64;
char pad[RTE_CACHE_LINE_SIZE*3];
} __rte_cache_aligned;
@@ -80,8 +80,8 @@ struct rte_distributor_returned_pkts {
struct rte_mbuf *mbufs[RTE_DISTRIB_MAX_RETURNS];
};
-struct rte_distributor_v20 {
- TAILQ_ENTRY(rte_distributor_v20) next; /**< Next in list. */
+struct rte_distributor_single {
+ TAILQ_ENTRY(rte_distributor_single) next; /**< Next in list. */
char name[RTE_DISTRIBUTOR_NAMESIZE]; /**< Name of the ring. */
unsigned int num_workers; /**< Number of workers polling */
@@ -96,7 +96,7 @@ struct rte_distributor_v20 {
struct rte_distributor_backlog backlog[RTE_DISTRIB_MAX_WORKERS];
- union rte_distributor_buffer_v20 bufs[RTE_DISTRIB_MAX_WORKERS];
+ union rte_distributor_buffer_single bufs[RTE_DISTRIB_MAX_WORKERS];
struct rte_distributor_returned_pkts returns;
};
@@ -154,7 +154,7 @@ struct rte_distributor {
enum rte_distributor_match_function dist_match_fn;
- struct rte_distributor_v20 *d_v20;
+ struct rte_distributor_single *d_single;
};
void
diff --git a/lib/librte_distributor/meson.build b/lib/librte_distributor/meson.build
index c9617d7b14..50b91887b5 100644
--- a/lib/librte_distributor/meson.build
+++ b/lib/librte_distributor/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-sources = files('rte_distributor.c', 'rte_distributor_v20.c')
+sources = files('rte_distributor.c', 'rte_distributor_single.c')
if arch_subdir == 'x86'
sources += files('rte_distributor_match_sse.c')
else
diff --git a/lib/librte_distributor/rte_distributor.c b/lib/librte_distributor/rte_distributor.c
index a4c8ff6a96..6c5b0c86e8 100644
--- a/lib/librte_distributor/rte_distributor.c
+++ b/lib/librte_distributor/rte_distributor.c
@@ -17,7 +17,7 @@
#include <rte_tailq.h>
#include "rte_distributor.h"
-#include "rte_distributor_v20.h"
+#include "rte_distributor_single.h"
#include "distributor_private.h"
TAILQ_HEAD(rte_dist_burst_list, rte_distributor);
@@ -42,7 +42,7 @@ rte_distributor_request_pkt(struct rte_distributor *d,
volatile int64_t *retptr64;
if (unlikely(d->alg_type == RTE_DIST_ALG_SINGLE)) {
- rte_distributor_request_pkt_v20(d->d_v20,
+ rte_distributor_request_pkt_single(d->d_single,
worker_id, oldpkt[0]);
return;
}
@@ -93,7 +93,8 @@ rte_distributor_poll_pkt(struct rte_distributor *d,
unsigned int i;
if (unlikely(d->alg_type == RTE_DIST_ALG_SINGLE)) {
- pkts[0] = rte_distributor_poll_pkt_v20(d->d_v20, worker_id);
+ pkts[0] = rte_distributor_poll_pkt_single(d->d_single,
+ worker_id);
return (pkts[0]) ? 1 : 0;
}
@@ -133,7 +134,7 @@ rte_distributor_get_pkt(struct rte_distributor *d,
if (unlikely(d->alg_type == RTE_DIST_ALG_SINGLE)) {
if (return_count <= 1) {
- pkts[0] = rte_distributor_get_pkt_v20(d->d_v20,
+ pkts[0] = rte_distributor_get_pkt_single(d->d_single,
worker_id, oldpkt[0]);
return (pkts[0]) ? 1 : 0;
} else
@@ -163,7 +164,7 @@ rte_distributor_return_pkt(struct rte_distributor *d,
if (unlikely(d->alg_type == RTE_DIST_ALG_SINGLE)) {
if (num == 1)
- return rte_distributor_return_pkt_v20(d->d_v20,
+ return rte_distributor_return_pkt_single(d->d_single,
worker_id, oldpkt[0]);
else
return -EINVAL;
@@ -354,7 +355,8 @@ rte_distributor_process(struct rte_distributor *d,
if (d->alg_type == RTE_DIST_ALG_SINGLE) {
/* Call the old API */
- return rte_distributor_process_v20(d->d_v20, mbufs, num_mbufs);
+ return rte_distributor_process_single(d->d_single,
+ mbufs, num_mbufs);
}
if (unlikely(num_mbufs == 0)) {
@@ -494,7 +496,7 @@ rte_distributor_returned_pkts(struct rte_distributor *d,
if (d->alg_type == RTE_DIST_ALG_SINGLE) {
/* Call the old API */
- return rte_distributor_returned_pkts_v20(d->d_v20,
+ return rte_distributor_returned_pkts_single(d->d_single,
mbufs, max_mbufs);
}
@@ -537,7 +539,7 @@ rte_distributor_flush(struct rte_distributor *d)
if (d->alg_type == RTE_DIST_ALG_SINGLE) {
/* Call the old API */
- return rte_distributor_flush_v20(d->d_v20);
+ return rte_distributor_flush_single(d->d_single);
}
flushed = total_outstanding(d);
@@ -568,7 +570,7 @@ rte_distributor_clear_returns(struct rte_distributor *d)
if (d->alg_type == RTE_DIST_ALG_SINGLE) {
/* Call the old API */
- rte_distributor_clear_returns_v20(d->d_v20);
+ rte_distributor_clear_returns_single(d->d_single);
return;
}
@@ -610,9 +612,9 @@ rte_distributor_create(const char *name,
rte_errno = ENOMEM;
return NULL;
}
- d->d_v20 = rte_distributor_create_v20(name,
+ d->d_single = rte_distributor_create_single(name,
socket_id, num_workers);
- if (d->d_v20 == NULL) {
+ if (d->d_single == NULL) {
free(d);
/* rte_errno will have been set */
return NULL;
diff --git a/lib/librte_distributor/rte_distributor_v20.c b/lib/librte_distributor/rte_distributor_single.c
similarity index 88%
rename from lib/librte_distributor/rte_distributor_v20.c
rename to lib/librte_distributor/rte_distributor_single.c
index 53fa16d27d..91d8824c64 100644
--- a/lib/librte_distributor/rte_distributor_v20.c
+++ b/lib/librte_distributor/rte_distributor_single.c
@@ -15,10 +15,10 @@
#include <rte_pause.h>
#include <rte_tailq.h>
-#include "rte_distributor_v20.h"
+#include "rte_distributor_single.h"
#include "distributor_private.h"
-TAILQ_HEAD(rte_distributor_list, rte_distributor_v20);
+TAILQ_HEAD(rte_distributor_list, rte_distributor_single);
static struct rte_tailq_elem rte_distributor_tailq = {
.name = "RTE_DISTRIBUTOR",
@@ -28,10 +28,10 @@ EAL_REGISTER_TAILQ(rte_distributor_tailq)
/**** APIs called by workers ****/
void
-rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
+rte_distributor_request_pkt_single(struct rte_distributor_single *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
- union rte_distributor_buffer_v20 *buf = &d->bufs[worker_id];
+ union rte_distributor_buffer_single *buf = &d->bufs[worker_id];
int64_t req = (((int64_t)(uintptr_t)oldpkt) << RTE_DISTRIB_FLAG_BITS)
| RTE_DISTRIB_GET_BUF;
while (unlikely(__atomic_load_n(&buf->bufptr64, __ATOMIC_RELAXED)
@@ -43,10 +43,10 @@ rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
}
struct rte_mbuf *
-rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
+rte_distributor_poll_pkt_single(struct rte_distributor_single *d,
unsigned worker_id)
{
- union rte_distributor_buffer_v20 *buf = &d->bufs[worker_id];
+ union rte_distributor_buffer_single *buf = &d->bufs[worker_id];
/* Sync with distributor. Acquire bufptr64. */
if (__atomic_load_n(&buf->bufptr64, __ATOMIC_ACQUIRE)
& RTE_DISTRIB_GET_BUF)
@@ -58,21 +58,21 @@ rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
}
struct rte_mbuf *
-rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
+rte_distributor_get_pkt_single(struct rte_distributor_single *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
struct rte_mbuf *ret;
- rte_distributor_request_pkt_v20(d, worker_id, oldpkt);
- while ((ret = rte_distributor_poll_pkt_v20(d, worker_id)) == NULL)
+ rte_distributor_request_pkt_single(d, worker_id, oldpkt);
+ while ((ret = rte_distributor_poll_pkt_single(d, worker_id)) == NULL)
rte_pause();
return ret;
}
int
-rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
+rte_distributor_return_pkt_single(struct rte_distributor_single *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
- union rte_distributor_buffer_v20 *buf = &d->bufs[worker_id];
+ union rte_distributor_buffer_single *buf = &d->bufs[worker_id];
uint64_t req = (((int64_t)(uintptr_t)oldpkt) << RTE_DISTRIB_FLAG_BITS)
| RTE_DISTRIB_RETURN_BUF;
/* Sync with distributor on RETURN_BUF flag. */
@@ -104,7 +104,7 @@ backlog_pop(struct rte_distributor_backlog *bl)
/* stores a packet returned from a worker inside the returns array */
static inline void
-store_return(uintptr_t oldbuf, struct rte_distributor_v20 *d,
+store_return(uintptr_t oldbuf, struct rte_distributor_single *d,
unsigned *ret_start, unsigned *ret_count)
{
/* store returns in a circular buffer - code is branch-free */
@@ -115,7 +115,7 @@ store_return(uintptr_t oldbuf, struct rte_distributor_v20 *d,
}
static inline void
-handle_worker_shutdown(struct rte_distributor_v20 *d, unsigned int wkr)
+handle_worker_shutdown(struct rte_distributor_single *d, unsigned int wkr)
{
d->in_flight_tags[wkr] = 0;
d->in_flight_bitmask &= ~(1UL << wkr);
@@ -146,7 +146,7 @@ handle_worker_shutdown(struct rte_distributor_v20 *d, unsigned int wkr)
* Note that the tags were set before first level call
* to rte_distributor_process.
*/
- rte_distributor_process_v20(d, pkts, i);
+ rte_distributor_process_single(d, pkts, i);
bl->count = bl->start = 0;
}
}
@@ -156,7 +156,7 @@ handle_worker_shutdown(struct rte_distributor_v20 *d, unsigned int wkr)
* to do a partial flush.
*/
static int
-process_returns(struct rte_distributor_v20 *d)
+process_returns(struct rte_distributor_single *d)
{
unsigned wkr;
unsigned flushed = 0;
@@ -201,7 +201,7 @@ process_returns(struct rte_distributor_v20 *d)
/* process a set of packets to distribute them to workers */
int
-rte_distributor_process_v20(struct rte_distributor_v20 *d,
+rte_distributor_process_single(struct rte_distributor_single *d,
struct rte_mbuf **mbufs, unsigned num_mbufs)
{
unsigned next_idx = 0;
@@ -317,7 +317,7 @@ rte_distributor_process_v20(struct rte_distributor_v20 *d,
/* return to the caller, packets returned from workers */
int
-rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
+rte_distributor_returned_pkts_single(struct rte_distributor_single *d,
struct rte_mbuf **mbufs, unsigned max_mbufs)
{
struct rte_distributor_returned_pkts *returns = &d->returns;
@@ -339,7 +339,7 @@ rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
* being worked on or queued up in a backlog.
*/
static inline unsigned
-total_outstanding(const struct rte_distributor_v20 *d)
+total_outstanding(const struct rte_distributor_single *d)
{
unsigned wkr, total_outstanding;
@@ -354,19 +354,19 @@ total_outstanding(const struct rte_distributor_v20 *d)
/* flush the distributor, so that there are no outstanding packets in flight or
* queued up. */
int
-rte_distributor_flush_v20(struct rte_distributor_v20 *d)
+rte_distributor_flush_single(struct rte_distributor_single *d)
{
const unsigned flushed = total_outstanding(d);
while (total_outstanding(d) > 0)
- rte_distributor_process_v20(d, NULL, 0);
+ rte_distributor_process_single(d, NULL, 0);
return flushed;
}
/* clears the internal returns array in the distributor */
void
-rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
+rte_distributor_clear_returns_single(struct rte_distributor_single *d)
{
d->returns.start = d->returns.count = 0;
#ifndef __OPTIMIZE__
@@ -375,12 +375,12 @@ rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
}
/* creates a distributor instance */
-struct rte_distributor_v20 *
-rte_distributor_create_v20(const char *name,
+struct rte_distributor_single *
+rte_distributor_create_single(const char *name,
unsigned socket_id,
unsigned num_workers)
{
- struct rte_distributor_v20 *d;
+ struct rte_distributor_single *d;
struct rte_distributor_list *distributor_list;
char mz_name[RTE_MEMZONE_NAMESIZE];
const struct rte_memzone *mz;
diff --git a/lib/librte_distributor/rte_distributor_v20.h b/lib/librte_distributor/rte_distributor_single.h
similarity index 89%
rename from lib/librte_distributor/rte_distributor_v20.h
rename to lib/librte_distributor/rte_distributor_single.h
index 12865658ba..2f80aa43d1 100644
--- a/lib/librte_distributor/rte_distributor_v20.h
+++ b/lib/librte_distributor/rte_distributor_single.h
@@ -2,8 +2,8 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#ifndef _RTE_DISTRIB_V20_H_
-#define _RTE_DISTRIB_V20_H_
+#ifndef _RTE_DISTRIB_SINGLE_H_
+#define _RTE_DISTRIB_SINGLE_H_
/**
* @file
@@ -19,7 +19,7 @@ extern "C" {
#define RTE_DISTRIBUTOR_NAMESIZE 32 /**< Length of name for instance */
-struct rte_distributor_v20;
+struct rte_distributor_single;
struct rte_mbuf;
/**
@@ -38,8 +38,8 @@ struct rte_mbuf;
* @return
* The newly created distributor instance
*/
-struct rte_distributor_v20 *
-rte_distributor_create_v20(const char *name, unsigned int socket_id,
+struct rte_distributor_single *
+rte_distributor_create_single(const char *name, unsigned int socket_id,
unsigned int num_workers);
/* *** APIS to be called on the distributor lcore *** */
@@ -74,7 +74,7 @@ rte_distributor_create_v20(const char *name, unsigned int socket_id,
* The number of mbufs processed.
*/
int
-rte_distributor_process_v20(struct rte_distributor_v20 *d,
+rte_distributor_process_single(struct rte_distributor_single *d,
struct rte_mbuf **mbufs, unsigned int num_mbufs);
/**
@@ -92,7 +92,7 @@ rte_distributor_process_v20(struct rte_distributor_v20 *d,
* The number of mbufs returned in the mbufs array.
*/
int
-rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
+rte_distributor_returned_pkts_single(struct rte_distributor_single *d,
struct rte_mbuf **mbufs, unsigned int max_mbufs);
/**
@@ -107,7 +107,7 @@ rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
* The number of queued/in-flight packets that were completed by this call.
*/
int
-rte_distributor_flush_v20(struct rte_distributor_v20 *d);
+rte_distributor_flush_single(struct rte_distributor_single *d);
/**
* Clears the array of returned packets used as the source for the
@@ -119,7 +119,7 @@ rte_distributor_flush_v20(struct rte_distributor_v20 *d);
* The distributor instance to be used
*/
void
-rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d);
+rte_distributor_clear_returns_single(struct rte_distributor_single *d);
/* *** APIS to be called on the worker lcores *** */
/*
@@ -148,7 +148,7 @@ rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d);
* A new packet to be processed by the worker thread.
*/
struct rte_mbuf *
-rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
+rte_distributor_get_pkt_single(struct rte_distributor_single *d,
unsigned int worker_id, struct rte_mbuf *oldpkt);
/**
@@ -164,7 +164,7 @@ rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
* The previous packet being processed by the worker
*/
int
-rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
+rte_distributor_return_pkt_single(struct rte_distributor_single *d,
unsigned int worker_id, struct rte_mbuf *mbuf);
/**
@@ -188,7 +188,7 @@ rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
* The previous packet, if any, being processed by the worker
*/
void
-rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
+rte_distributor_request_pkt_single(struct rte_distributor_single *d,
unsigned int worker_id, struct rte_mbuf *oldpkt);
/**
@@ -208,7 +208,7 @@ rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
* packet is yet available.
*/
struct rte_mbuf *
-rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
+rte_distributor_poll_pkt_single(struct rte_distributor_single *d,
unsigned int worker_id);
#ifdef __cplusplus
diff --git a/lib/librte_distributor/rte_distributor_version.map b/lib/librte_distributor/rte_distributor_version.map
index 3a285b394e..00e26b4804 100644
--- a/lib/librte_distributor/rte_distributor_version.map
+++ b/lib/librte_distributor/rte_distributor_version.map
@@ -1,19 +1,3 @@
-DPDK_2.0 {
- global:
-
- rte_distributor_clear_returns;
- rte_distributor_create;
- rte_distributor_flush;
- rte_distributor_get_pkt;
- rte_distributor_poll_pkt;
- rte_distributor_process;
- rte_distributor_request_pkt;
- rte_distributor_return_pkt;
- rte_distributor_returned_pkts;
-
- local: *;
-};
-
DPDK_17.05 {
global:
@@ -26,4 +10,4 @@ DPDK_17.05 {
rte_distributor_request_pkt;
rte_distributor_return_pkt;
rte_distributor_returned_pkts;
-} DPDK_2.0;
+};
--
2.17.1
^ permalink raw reply [relevance 6%]
* [dpdk-dev] [PATCH v6 06/10] distributor: remove deprecated code
` (7 preceding siblings ...)
2019-11-06 16:54 2% ` [dpdk-dev] [PATCH v6 05/10] lpm: " Anatoly Burakov
@ 2019-11-06 16:54 4% ` Anatoly Burakov
2019-11-06 16:54 6% ` [dpdk-dev] [PATCH v6 07/10] distributor: rename v2.0 ABI to _single suffix Anatoly Burakov
` (3 subsequent siblings)
12 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-06 16:54 UTC (permalink / raw)
To: dev
Cc: Marcin Baran, David Hunt, john.mcnamara, ray.kinsella,
bruce.richardson, thomas, david.marchand
From: Marcin Baran <marcinx.baran@intel.com>
Remove code for old ABI versions ahead of ABI version bump.
Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: David Hunt <david.hunt@intel.com>
---
Notes:
v5:
- Fixed shared library linking error due to versioning still enabled
v2:
- Moved this to before ABI version bump to avoid compile breakage
v2:
- Moved this to before ABI version bump to avoid compile breakage
lib/librte_distributor/rte_distributor.c | 56 +++--------------
.../rte_distributor_v1705.h | 61 -------------------
lib/librte_distributor/rte_distributor_v20.c | 9 ---
3 files changed, 9 insertions(+), 117 deletions(-)
delete mode 100644 lib/librte_distributor/rte_distributor_v1705.h
diff --git a/lib/librte_distributor/rte_distributor.c b/lib/librte_distributor/rte_distributor.c
index 7df97df92d..a4c8ff6a96 100644
--- a/lib/librte_distributor/rte_distributor.c
+++ b/lib/librte_distributor/rte_distributor.c
@@ -18,7 +18,6 @@
#include "rte_distributor.h"
#include "rte_distributor_v20.h"
-#include "rte_distributor_v1705.h"
#include "distributor_private.h"
TAILQ_HEAD(rte_dist_burst_list, rte_distributor);
@@ -33,7 +32,7 @@ EAL_REGISTER_TAILQ(rte_dist_burst_tailq)
/**** Burst Packet APIs called by workers ****/
void
-rte_distributor_request_pkt_v1705(struct rte_distributor *d,
+rte_distributor_request_pkt(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **oldpkt,
unsigned int count)
{
@@ -83,14 +82,9 @@ rte_distributor_request_pkt_v1705(struct rte_distributor *d,
__atomic_store_n(retptr64, *retptr64 | RTE_DISTRIB_GET_BUF,
__ATOMIC_RELEASE);
}
-BIND_DEFAULT_SYMBOL(rte_distributor_request_pkt, _v1705, 17.05);
-MAP_STATIC_SYMBOL(void rte_distributor_request_pkt(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **oldpkt,
- unsigned int count),
- rte_distributor_request_pkt_v1705);
int
-rte_distributor_poll_pkt_v1705(struct rte_distributor *d,
+rte_distributor_poll_pkt(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **pkts)
{
struct rte_distributor_buffer *buf = &d->bufs[worker_id];
@@ -129,13 +123,9 @@ rte_distributor_poll_pkt_v1705(struct rte_distributor *d,
return count;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_poll_pkt, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_distributor_poll_pkt(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **pkts),
- rte_distributor_poll_pkt_v1705);
int
-rte_distributor_get_pkt_v1705(struct rte_distributor *d,
+rte_distributor_get_pkt(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **pkts,
struct rte_mbuf **oldpkt, unsigned int return_count)
{
@@ -163,14 +153,9 @@ rte_distributor_get_pkt_v1705(struct rte_distributor *d,
}
return count;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_get_pkt, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_distributor_get_pkt(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **pkts,
- struct rte_mbuf **oldpkt, unsigned int return_count),
- rte_distributor_get_pkt_v1705);
int
-rte_distributor_return_pkt_v1705(struct rte_distributor *d,
+rte_distributor_return_pkt(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **oldpkt, int num)
{
struct rte_distributor_buffer *buf = &d->bufs[worker_id];
@@ -202,10 +187,6 @@ rte_distributor_return_pkt_v1705(struct rte_distributor *d,
return 0;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_return_pkt, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_distributor_return_pkt(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **oldpkt, int num),
- rte_distributor_return_pkt_v1705);
/**** APIs called on distributor core ***/
@@ -360,7 +341,7 @@ release(struct rte_distributor *d, unsigned int wkr)
/* process a set of packets to distribute them to workers */
int
-rte_distributor_process_v1705(struct rte_distributor *d,
+rte_distributor_process(struct rte_distributor *d,
struct rte_mbuf **mbufs, unsigned int num_mbufs)
{
unsigned int next_idx = 0;
@@ -500,14 +481,10 @@ rte_distributor_process_v1705(struct rte_distributor *d,
return num_mbufs;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_process, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_distributor_process(struct rte_distributor *d,
- struct rte_mbuf **mbufs, unsigned int num_mbufs),
- rte_distributor_process_v1705);
/* return to the caller, packets returned from workers */
int
-rte_distributor_returned_pkts_v1705(struct rte_distributor *d,
+rte_distributor_returned_pkts(struct rte_distributor *d,
struct rte_mbuf **mbufs, unsigned int max_mbufs)
{
struct rte_distributor_returned_pkts *returns = &d->returns;
@@ -532,10 +509,6 @@ rte_distributor_returned_pkts_v1705(struct rte_distributor *d,
return retval;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_returned_pkts, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_distributor_returned_pkts(struct rte_distributor *d,
- struct rte_mbuf **mbufs, unsigned int max_mbufs),
- rte_distributor_returned_pkts_v1705);
/*
* Return the number of packets in-flight in a distributor, i.e. packets
@@ -557,7 +530,7 @@ total_outstanding(const struct rte_distributor *d)
* queued up.
*/
int
-rte_distributor_flush_v1705(struct rte_distributor *d)
+rte_distributor_flush(struct rte_distributor *d)
{
unsigned int flushed;
unsigned int wkr;
@@ -586,13 +559,10 @@ rte_distributor_flush_v1705(struct rte_distributor *d)
return flushed;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_flush, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_distributor_flush(struct rte_distributor *d),
- rte_distributor_flush_v1705);
/* clears the internal returns array in the distributor */
void
-rte_distributor_clear_returns_v1705(struct rte_distributor *d)
+rte_distributor_clear_returns(struct rte_distributor *d)
{
unsigned int wkr;
@@ -608,13 +578,10 @@ rte_distributor_clear_returns_v1705(struct rte_distributor *d)
__atomic_store_n(&(d->bufs[wkr].retptr64[0]), 0,
__ATOMIC_RELEASE);
}
-BIND_DEFAULT_SYMBOL(rte_distributor_clear_returns, _v1705, 17.05);
-MAP_STATIC_SYMBOL(void rte_distributor_clear_returns(struct rte_distributor *d),
- rte_distributor_clear_returns_v1705);
/* creates a distributor instance */
struct rte_distributor *
-rte_distributor_create_v1705(const char *name,
+rte_distributor_create(const char *name,
unsigned int socket_id,
unsigned int num_workers,
unsigned int alg_type)
@@ -688,8 +655,3 @@ rte_distributor_create_v1705(const char *name,
return d;
}
-BIND_DEFAULT_SYMBOL(rte_distributor_create, _v1705, 17.05);
-MAP_STATIC_SYMBOL(struct rte_distributor *rte_distributor_create(
- const char *name, unsigned int socket_id,
- unsigned int num_workers, unsigned int alg_type),
- rte_distributor_create_v1705);
diff --git a/lib/librte_distributor/rte_distributor_v1705.h b/lib/librte_distributor/rte_distributor_v1705.h
deleted file mode 100644
index df4d9e8150..0000000000
--- a/lib/librte_distributor/rte_distributor_v1705.h
+++ /dev/null
@@ -1,61 +0,0 @@
-/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2017 Intel Corporation
- */
-
-#ifndef _RTE_DISTRIB_V1705_H_
-#define _RTE_DISTRIB_V1705_H_
-
-/**
- * @file
- * RTE distributor
- *
- * The distributor is a component which is designed to pass packets
- * one-at-a-time to workers, with dynamic load balancing.
- */
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-struct rte_distributor *
-rte_distributor_create_v1705(const char *name, unsigned int socket_id,
- unsigned int num_workers,
- unsigned int alg_type);
-
-int
-rte_distributor_process_v1705(struct rte_distributor *d,
- struct rte_mbuf **mbufs, unsigned int num_mbufs);
-
-int
-rte_distributor_returned_pkts_v1705(struct rte_distributor *d,
- struct rte_mbuf **mbufs, unsigned int max_mbufs);
-
-int
-rte_distributor_flush_v1705(struct rte_distributor *d);
-
-void
-rte_distributor_clear_returns_v1705(struct rte_distributor *d);
-
-int
-rte_distributor_get_pkt_v1705(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **pkts,
- struct rte_mbuf **oldpkt, unsigned int retcount);
-
-int
-rte_distributor_return_pkt_v1705(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **oldpkt, int num);
-
-void
-rte_distributor_request_pkt_v1705(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **oldpkt,
- unsigned int count);
-
-int
-rte_distributor_poll_pkt_v1705(struct rte_distributor *d,
- unsigned int worker_id, struct rte_mbuf **mbufs);
-
-#ifdef __cplusplus
-}
-#endif
-
-#endif
diff --git a/lib/librte_distributor/rte_distributor_v20.c b/lib/librte_distributor/rte_distributor_v20.c
index db6c49258a..53fa16d27d 100644
--- a/lib/librte_distributor/rte_distributor_v20.c
+++ b/lib/librte_distributor/rte_distributor_v20.c
@@ -41,7 +41,6 @@ rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
/* Sync with distributor on GET_BUF flag. */
__atomic_store_n(&(buf->bufptr64), req, __ATOMIC_RELEASE);
}
-VERSION_SYMBOL(rte_distributor_request_pkt, _v20, 2.0);
struct rte_mbuf *
rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
@@ -57,7 +56,6 @@ rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
int64_t ret = buf->bufptr64 >> RTE_DISTRIB_FLAG_BITS;
return (struct rte_mbuf *)((uintptr_t)ret);
}
-VERSION_SYMBOL(rte_distributor_poll_pkt, _v20, 2.0);
struct rte_mbuf *
rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
@@ -69,7 +67,6 @@ rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
rte_pause();
return ret;
}
-VERSION_SYMBOL(rte_distributor_get_pkt, _v20, 2.0);
int
rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
@@ -82,7 +79,6 @@ rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
__atomic_store_n(&(buf->bufptr64), req, __ATOMIC_RELEASE);
return 0;
}
-VERSION_SYMBOL(rte_distributor_return_pkt, _v20, 2.0);
/**** APIs called on distributor core ***/
@@ -318,7 +314,6 @@ rte_distributor_process_v20(struct rte_distributor_v20 *d,
d->returns.count = ret_count;
return num_mbufs;
}
-VERSION_SYMBOL(rte_distributor_process, _v20, 2.0);
/* return to the caller, packets returned from workers */
int
@@ -339,7 +334,6 @@ rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
return retval;
}
-VERSION_SYMBOL(rte_distributor_returned_pkts, _v20, 2.0);
/* return the number of packets in-flight in a distributor, i.e. packets
* being worked on or queued up in a backlog.
@@ -369,7 +363,6 @@ rte_distributor_flush_v20(struct rte_distributor_v20 *d)
return flushed;
}
-VERSION_SYMBOL(rte_distributor_flush, _v20, 2.0);
/* clears the internal returns array in the distributor */
void
@@ -380,7 +373,6 @@ rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
memset(d->returns.mbufs, 0, sizeof(d->returns.mbufs));
#endif
}
-VERSION_SYMBOL(rte_distributor_clear_returns, _v20, 2.0);
/* creates a distributor instance */
struct rte_distributor_v20 *
@@ -424,4 +416,3 @@ rte_distributor_create_v20(const char *name,
return d;
}
-VERSION_SYMBOL(rte_distributor_create, _v20, 2.0);
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v6 05/10] lpm: remove deprecated code
` (6 preceding siblings ...)
2019-11-06 16:54 4% ` [dpdk-dev] [PATCH v6 04/10] timer: remove deprecated code Anatoly Burakov
@ 2019-11-06 16:54 2% ` Anatoly Burakov
2019-11-06 16:54 4% ` [dpdk-dev] [PATCH v6 06/10] distributor: " Anatoly Burakov
` (4 subsequent siblings)
12 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-06 16:54 UTC (permalink / raw)
To: dev
Cc: Marcin Baran, Bruce Richardson, Vladimir Medvedkin,
john.mcnamara, ray.kinsella, thomas, david.marchand
From: Marcin Baran <marcinx.baran@intel.com>
Remove code for old ABI versions ahead of ABI version bump.
Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
Notes:
v2:
- Moved this to before ABI version bump to avoid compile breakage
lib/librte_lpm/rte_lpm.c | 996 ++------------------------------------
lib/librte_lpm/rte_lpm.h | 88 ----
lib/librte_lpm/rte_lpm6.c | 132 +----
lib/librte_lpm/rte_lpm6.h | 25 -
4 files changed, 48 insertions(+), 1193 deletions(-)
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index c96395e269..b78c487447 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -90,34 +90,8 @@ depth_to_range(uint8_t depth)
/*
* Find an existing lpm table and return a pointer to it.
*/
-struct rte_lpm_v20 *
-rte_lpm_find_existing_v20(const char *name)
-{
- struct rte_lpm_v20 *l = NULL;
- struct rte_tailq_entry *te;
- struct rte_lpm_list *lpm_list;
-
- lpm_list = RTE_TAILQ_CAST(rte_lpm_tailq.head, rte_lpm_list);
-
- rte_mcfg_tailq_read_lock();
- TAILQ_FOREACH(te, lpm_list, next) {
- l = te->data;
- if (strncmp(name, l->name, RTE_LPM_NAMESIZE) == 0)
- break;
- }
- rte_mcfg_tailq_read_unlock();
-
- if (te == NULL) {
- rte_errno = ENOENT;
- return NULL;
- }
-
- return l;
-}
-VERSION_SYMBOL(rte_lpm_find_existing, _v20, 2.0);
-
struct rte_lpm *
-rte_lpm_find_existing_v1604(const char *name)
+rte_lpm_find_existing(const char *name)
{
struct rte_lpm *l = NULL;
struct rte_tailq_entry *te;
@@ -140,88 +114,12 @@ rte_lpm_find_existing_v1604(const char *name)
return l;
}
-BIND_DEFAULT_SYMBOL(rte_lpm_find_existing, _v1604, 16.04);
-MAP_STATIC_SYMBOL(struct rte_lpm *rte_lpm_find_existing(const char *name),
- rte_lpm_find_existing_v1604);
/*
* Allocates memory for LPM object
*/
-struct rte_lpm_v20 *
-rte_lpm_create_v20(const char *name, int socket_id, int max_rules,
- __rte_unused int flags)
-{
- char mem_name[RTE_LPM_NAMESIZE];
- struct rte_lpm_v20 *lpm = NULL;
- struct rte_tailq_entry *te;
- uint32_t mem_size;
- struct rte_lpm_list *lpm_list;
-
- lpm_list = RTE_TAILQ_CAST(rte_lpm_tailq.head, rte_lpm_list);
-
- RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl_entry_v20) != 2);
-
- /* Check user arguments. */
- if ((name == NULL) || (socket_id < -1) || (max_rules == 0)) {
- rte_errno = EINVAL;
- return NULL;
- }
-
- snprintf(mem_name, sizeof(mem_name), "LPM_%s", name);
-
- /* Determine the amount of memory to allocate. */
- mem_size = sizeof(*lpm) + (sizeof(lpm->rules_tbl[0]) * max_rules);
-
- rte_mcfg_tailq_write_lock();
-
- /* guarantee there's no existing */
- TAILQ_FOREACH(te, lpm_list, next) {
- lpm = te->data;
- if (strncmp(name, lpm->name, RTE_LPM_NAMESIZE) == 0)
- break;
- }
-
- if (te != NULL) {
- lpm = NULL;
- rte_errno = EEXIST;
- goto exit;
- }
-
- /* allocate tailq entry */
- te = rte_zmalloc("LPM_TAILQ_ENTRY", sizeof(*te), 0);
- if (te == NULL) {
- RTE_LOG(ERR, LPM, "Failed to allocate tailq entry\n");
- rte_errno = ENOMEM;
- goto exit;
- }
-
- /* Allocate memory to store the LPM data structures. */
- lpm = rte_zmalloc_socket(mem_name, mem_size,
- RTE_CACHE_LINE_SIZE, socket_id);
- if (lpm == NULL) {
- RTE_LOG(ERR, LPM, "LPM memory allocation failed\n");
- rte_free(te);
- rte_errno = ENOMEM;
- goto exit;
- }
-
- /* Save user arguments. */
- lpm->max_rules = max_rules;
- strlcpy(lpm->name, name, sizeof(lpm->name));
-
- te->data = lpm;
-
- TAILQ_INSERT_TAIL(lpm_list, te, next);
-
-exit:
- rte_mcfg_tailq_write_unlock();
-
- return lpm;
-}
-VERSION_SYMBOL(rte_lpm_create, _v20, 2.0);
-
struct rte_lpm *
-rte_lpm_create_v1604(const char *name, int socket_id,
+rte_lpm_create(const char *name, int socket_id,
const struct rte_lpm_config *config)
{
char mem_name[RTE_LPM_NAMESIZE];
@@ -321,45 +219,12 @@ rte_lpm_create_v1604(const char *name, int socket_id,
return lpm;
}
-BIND_DEFAULT_SYMBOL(rte_lpm_create, _v1604, 16.04);
-MAP_STATIC_SYMBOL(
- struct rte_lpm *rte_lpm_create(const char *name, int socket_id,
- const struct rte_lpm_config *config), rte_lpm_create_v1604);
/*
* Deallocates memory for given LPM table.
*/
void
-rte_lpm_free_v20(struct rte_lpm_v20 *lpm)
-{
- struct rte_lpm_list *lpm_list;
- struct rte_tailq_entry *te;
-
- /* Check user arguments. */
- if (lpm == NULL)
- return;
-
- lpm_list = RTE_TAILQ_CAST(rte_lpm_tailq.head, rte_lpm_list);
-
- rte_mcfg_tailq_write_lock();
-
- /* find our tailq entry */
- TAILQ_FOREACH(te, lpm_list, next) {
- if (te->data == (void *) lpm)
- break;
- }
- if (te != NULL)
- TAILQ_REMOVE(lpm_list, te, next);
-
- rte_mcfg_tailq_write_unlock();
-
- rte_free(lpm);
- rte_free(te);
-}
-VERSION_SYMBOL(rte_lpm_free, _v20, 2.0);
-
-void
-rte_lpm_free_v1604(struct rte_lpm *lpm)
+rte_lpm_free(struct rte_lpm *lpm)
{
struct rte_lpm_list *lpm_list;
struct rte_tailq_entry *te;
@@ -387,9 +252,6 @@ rte_lpm_free_v1604(struct rte_lpm *lpm)
rte_free(lpm);
rte_free(te);
}
-BIND_DEFAULT_SYMBOL(rte_lpm_free, _v1604, 16.04);
-MAP_STATIC_SYMBOL(void rte_lpm_free(struct rte_lpm *lpm),
- rte_lpm_free_v1604);
/*
* Adds a rule to the rule table.
@@ -402,79 +264,7 @@ MAP_STATIC_SYMBOL(void rte_lpm_free(struct rte_lpm *lpm),
* NOTE: Valid range for depth parameter is 1 .. 32 inclusive.
*/
static int32_t
-rule_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip_masked, uint8_t depth,
- uint8_t next_hop)
-{
- uint32_t rule_gindex, rule_index, last_rule;
- int i;
-
- VERIFY_DEPTH(depth);
-
- /* Scan through rule group to see if rule already exists. */
- if (lpm->rule_info[depth - 1].used_rules > 0) {
-
- /* rule_gindex stands for rule group index. */
- rule_gindex = lpm->rule_info[depth - 1].first_rule;
- /* Initialise rule_index to point to start of rule group. */
- rule_index = rule_gindex;
- /* Last rule = Last used rule in this rule group. */
- last_rule = rule_gindex + lpm->rule_info[depth - 1].used_rules;
-
- for (; rule_index < last_rule; rule_index++) {
-
- /* If rule already exists update its next_hop and return. */
- if (lpm->rules_tbl[rule_index].ip == ip_masked) {
- lpm->rules_tbl[rule_index].next_hop = next_hop;
-
- return rule_index;
- }
- }
-
- if (rule_index == lpm->max_rules)
- return -ENOSPC;
- } else {
- /* Calculate the position in which the rule will be stored. */
- rule_index = 0;
-
- for (i = depth - 1; i > 0; i--) {
- if (lpm->rule_info[i - 1].used_rules > 0) {
- rule_index = lpm->rule_info[i - 1].first_rule
- + lpm->rule_info[i - 1].used_rules;
- break;
- }
- }
- if (rule_index == lpm->max_rules)
- return -ENOSPC;
-
- lpm->rule_info[depth - 1].first_rule = rule_index;
- }
-
- /* Make room for the new rule in the array. */
- for (i = RTE_LPM_MAX_DEPTH; i > depth; i--) {
- if (lpm->rule_info[i - 1].first_rule
- + lpm->rule_info[i - 1].used_rules == lpm->max_rules)
- return -ENOSPC;
-
- if (lpm->rule_info[i - 1].used_rules > 0) {
- lpm->rules_tbl[lpm->rule_info[i - 1].first_rule
- + lpm->rule_info[i - 1].used_rules]
- = lpm->rules_tbl[lpm->rule_info[i - 1].first_rule];
- lpm->rule_info[i - 1].first_rule++;
- }
- }
-
- /* Add the new rule. */
- lpm->rules_tbl[rule_index].ip = ip_masked;
- lpm->rules_tbl[rule_index].next_hop = next_hop;
-
- /* Increment the used rules counter for this rule group. */
- lpm->rule_info[depth - 1].used_rules++;
-
- return rule_index;
-}
-
-static int32_t
-rule_add_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
+rule_add(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
uint32_t next_hop)
{
uint32_t rule_gindex, rule_index, last_rule;
@@ -550,30 +340,7 @@ rule_add_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
* NOTE: Valid range for depth parameter is 1 .. 32 inclusive.
*/
static void
-rule_delete_v20(struct rte_lpm_v20 *lpm, int32_t rule_index, uint8_t depth)
-{
- int i;
-
- VERIFY_DEPTH(depth);
-
- lpm->rules_tbl[rule_index] =
- lpm->rules_tbl[lpm->rule_info[depth - 1].first_rule
- + lpm->rule_info[depth - 1].used_rules - 1];
-
- for (i = depth; i < RTE_LPM_MAX_DEPTH; i++) {
- if (lpm->rule_info[i].used_rules > 0) {
- lpm->rules_tbl[lpm->rule_info[i].first_rule - 1] =
- lpm->rules_tbl[lpm->rule_info[i].first_rule
- + lpm->rule_info[i].used_rules - 1];
- lpm->rule_info[i].first_rule--;
- }
- }
-
- lpm->rule_info[depth - 1].used_rules--;
-}
-
-static void
-rule_delete_v1604(struct rte_lpm *lpm, int32_t rule_index, uint8_t depth)
+rule_delete(struct rte_lpm *lpm, int32_t rule_index, uint8_t depth)
{
int i;
@@ -600,28 +367,7 @@ rule_delete_v1604(struct rte_lpm *lpm, int32_t rule_index, uint8_t depth)
* NOTE: Valid range for depth parameter is 1 .. 32 inclusive.
*/
static int32_t
-rule_find_v20(struct rte_lpm_v20 *lpm, uint32_t ip_masked, uint8_t depth)
-{
- uint32_t rule_gindex, last_rule, rule_index;
-
- VERIFY_DEPTH(depth);
-
- rule_gindex = lpm->rule_info[depth - 1].first_rule;
- last_rule = rule_gindex + lpm->rule_info[depth - 1].used_rules;
-
- /* Scan used rules at given depth to find rule. */
- for (rule_index = rule_gindex; rule_index < last_rule; rule_index++) {
- /* If rule is found return the rule index. */
- if (lpm->rules_tbl[rule_index].ip == ip_masked)
- return rule_index;
- }
-
- /* If rule is not found return -EINVAL. */
- return -EINVAL;
-}
-
-static int32_t
-rule_find_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth)
+rule_find(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth)
{
uint32_t rule_gindex, last_rule, rule_index;
@@ -645,42 +391,7 @@ rule_find_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth)
* Find, clean and allocate a tbl8.
*/
static int32_t
-tbl8_alloc_v20(struct rte_lpm_tbl_entry_v20 *tbl8)
-{
- uint32_t group_idx; /* tbl8 group index. */
- struct rte_lpm_tbl_entry_v20 *tbl8_entry;
-
- /* Scan through tbl8 to find a free (i.e. INVALID) tbl8 group. */
- for (group_idx = 0; group_idx < RTE_LPM_TBL8_NUM_GROUPS;
- group_idx++) {
- tbl8_entry = &tbl8[group_idx * RTE_LPM_TBL8_GROUP_NUM_ENTRIES];
- /* If a free tbl8 group is found clean it and set as VALID. */
- if (!tbl8_entry->valid_group) {
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = INVALID,
- .depth = 0,
- .valid_group = VALID,
- };
- new_tbl8_entry.next_hop = 0;
-
- memset(&tbl8_entry[0], 0,
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES *
- sizeof(tbl8_entry[0]));
-
- __atomic_store(tbl8_entry, &new_tbl8_entry,
- __ATOMIC_RELAXED);
-
- /* Return group index for allocated tbl8 group. */
- return group_idx;
- }
- }
-
- /* If there are no tbl8 groups free then return error. */
- return -ENOSPC;
-}
-
-static int32_t
-tbl8_alloc_v1604(struct rte_lpm_tbl_entry *tbl8, uint32_t number_tbl8s)
+tbl8_alloc(struct rte_lpm_tbl_entry *tbl8, uint32_t number_tbl8s)
{
uint32_t group_idx; /* tbl8 group index. */
struct rte_lpm_tbl_entry *tbl8_entry;
@@ -714,22 +425,7 @@ tbl8_alloc_v1604(struct rte_lpm_tbl_entry *tbl8, uint32_t number_tbl8s)
}
static void
-tbl8_free_v20(struct rte_lpm_tbl_entry_v20 *tbl8, uint32_t tbl8_group_start)
-{
- /* Set tbl8 group invalid*/
- struct rte_lpm_tbl_entry_v20 zero_tbl8_entry = {
- .valid = INVALID,
- .depth = 0,
- .valid_group = INVALID,
- };
- zero_tbl8_entry.next_hop = 0;
-
- __atomic_store(&tbl8[tbl8_group_start], &zero_tbl8_entry,
- __ATOMIC_RELAXED);
-}
-
-static void
-tbl8_free_v1604(struct rte_lpm_tbl_entry *tbl8, uint32_t tbl8_group_start)
+tbl8_free(struct rte_lpm_tbl_entry *tbl8, uint32_t tbl8_group_start)
{
/* Set tbl8 group invalid*/
struct rte_lpm_tbl_entry zero_tbl8_entry = {0};
@@ -739,78 +435,7 @@ tbl8_free_v1604(struct rte_lpm_tbl_entry *tbl8, uint32_t tbl8_group_start)
}
static __rte_noinline int32_t
-add_depth_small_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
- uint8_t next_hop)
-{
- uint32_t tbl24_index, tbl24_range, tbl8_index, tbl8_group_end, i, j;
-
- /* Calculate the index into Table24. */
- tbl24_index = ip >> 8;
- tbl24_range = depth_to_range(depth);
-
- for (i = tbl24_index; i < (tbl24_index + tbl24_range); i++) {
- /*
- * For invalid OR valid and non-extended tbl 24 entries set
- * entry.
- */
- if (!lpm->tbl24[i].valid || (lpm->tbl24[i].valid_group == 0 &&
- lpm->tbl24[i].depth <= depth)) {
-
- struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- .valid = VALID,
- .valid_group = 0,
- .depth = depth,
- };
- new_tbl24_entry.next_hop = next_hop;
-
- /* Setting tbl24 entry in one go to avoid race
- * conditions
- */
- __atomic_store(&lpm->tbl24[i], &new_tbl24_entry,
- __ATOMIC_RELEASE);
-
- continue;
- }
-
- if (lpm->tbl24[i].valid_group == 1) {
- /* If tbl24 entry is valid and extended calculate the
- * index into tbl8.
- */
- tbl8_index = lpm->tbl24[i].group_idx *
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
- tbl8_group_end = tbl8_index +
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
-
- for (j = tbl8_index; j < tbl8_group_end; j++) {
- if (!lpm->tbl8[j].valid ||
- lpm->tbl8[j].depth <= depth) {
- struct rte_lpm_tbl_entry_v20
- new_tbl8_entry = {
- .valid = VALID,
- .valid_group = VALID,
- .depth = depth,
- };
- new_tbl8_entry.next_hop = next_hop;
-
- /*
- * Setting tbl8 entry in one go to avoid
- * race conditions
- */
- __atomic_store(&lpm->tbl8[j],
- &new_tbl8_entry,
- __ATOMIC_RELAXED);
-
- continue;
- }
- }
- }
- }
-
- return 0;
-}
-
-static __rte_noinline int32_t
-add_depth_small_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
+add_depth_small(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t next_hop)
{
#define group_idx next_hop
@@ -882,150 +507,7 @@ add_depth_small_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
}
static __rte_noinline int32_t
-add_depth_big_v20(struct rte_lpm_v20 *lpm, uint32_t ip_masked, uint8_t depth,
- uint8_t next_hop)
-{
- uint32_t tbl24_index;
- int32_t tbl8_group_index, tbl8_group_start, tbl8_group_end, tbl8_index,
- tbl8_range, i;
-
- tbl24_index = (ip_masked >> 8);
- tbl8_range = depth_to_range(depth);
-
- if (!lpm->tbl24[tbl24_index].valid) {
- /* Search for a free tbl8 group. */
- tbl8_group_index = tbl8_alloc_v20(lpm->tbl8);
-
- /* Check tbl8 allocation was successful. */
- if (tbl8_group_index < 0) {
- return tbl8_group_index;
- }
-
- /* Find index into tbl8 and range. */
- tbl8_index = (tbl8_group_index *
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES) +
- (ip_masked & 0xFF);
-
- /* Set tbl8 entry. */
- for (i = tbl8_index; i < (tbl8_index + tbl8_range); i++) {
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = VALID,
- .depth = depth,
- .valid_group = lpm->tbl8[i].valid_group,
- };
- new_tbl8_entry.next_hop = next_hop;
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
- __ATOMIC_RELAXED);
- }
-
- /*
- * Update tbl24 entry to point to new tbl8 entry. Note: The
- * ext_flag and tbl8_index need to be updated simultaneously,
- * so assign whole structure in one go
- */
-
- struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- .group_idx = (uint8_t)tbl8_group_index,
- .valid = VALID,
- .valid_group = 1,
- .depth = 0,
- };
-
- __atomic_store(&lpm->tbl24[tbl24_index], &new_tbl24_entry,
- __ATOMIC_RELEASE);
-
- } /* If valid entry but not extended calculate the index into Table8. */
- else if (lpm->tbl24[tbl24_index].valid_group == 0) {
- /* Search for free tbl8 group. */
- tbl8_group_index = tbl8_alloc_v20(lpm->tbl8);
-
- if (tbl8_group_index < 0) {
- return tbl8_group_index;
- }
-
- tbl8_group_start = tbl8_group_index *
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
- tbl8_group_end = tbl8_group_start +
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
-
- /* Populate new tbl8 with tbl24 value. */
- for (i = tbl8_group_start; i < tbl8_group_end; i++) {
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = VALID,
- .depth = lpm->tbl24[tbl24_index].depth,
- .valid_group = lpm->tbl8[i].valid_group,
- };
- new_tbl8_entry.next_hop =
- lpm->tbl24[tbl24_index].next_hop;
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
- __ATOMIC_RELAXED);
- }
-
- tbl8_index = tbl8_group_start + (ip_masked & 0xFF);
-
- /* Insert new rule into the tbl8 entry. */
- for (i = tbl8_index; i < tbl8_index + tbl8_range; i++) {
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = VALID,
- .depth = depth,
- .valid_group = lpm->tbl8[i].valid_group,
- };
- new_tbl8_entry.next_hop = next_hop;
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
- __ATOMIC_RELAXED);
- }
-
- /*
- * Update tbl24 entry to point to new tbl8 entry. Note: The
- * ext_flag and tbl8_index need to be updated simultaneously,
- * so assign whole structure in one go.
- */
-
- struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- .group_idx = (uint8_t)tbl8_group_index,
- .valid = VALID,
- .valid_group = 1,
- .depth = 0,
- };
-
- __atomic_store(&lpm->tbl24[tbl24_index], &new_tbl24_entry,
- __ATOMIC_RELEASE);
-
- } else { /*
- * If it is valid, extended entry calculate the index into tbl8.
- */
- tbl8_group_index = lpm->tbl24[tbl24_index].group_idx;
- tbl8_group_start = tbl8_group_index *
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
- tbl8_index = tbl8_group_start + (ip_masked & 0xFF);
-
- for (i = tbl8_index; i < (tbl8_index + tbl8_range); i++) {
-
- if (!lpm->tbl8[i].valid ||
- lpm->tbl8[i].depth <= depth) {
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = VALID,
- .depth = depth,
- .valid_group = lpm->tbl8[i].valid_group,
- };
- new_tbl8_entry.next_hop = next_hop;
- /*
- * Setting tbl8 entry in one go to avoid race
- * condition
- */
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
- __ATOMIC_RELAXED);
-
- continue;
- }
- }
- }
-
- return 0;
-}
-
-static __rte_noinline int32_t
-add_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
+add_depth_big(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
uint32_t next_hop)
{
#define group_idx next_hop
@@ -1038,7 +520,7 @@ add_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
if (!lpm->tbl24[tbl24_index].valid) {
/* Search for a free tbl8 group. */
- tbl8_group_index = tbl8_alloc_v1604(lpm->tbl8, lpm->number_tbl8s);
+ tbl8_group_index = tbl8_alloc(lpm->tbl8, lpm->number_tbl8s);
/* Check tbl8 allocation was successful. */
if (tbl8_group_index < 0) {
@@ -1084,7 +566,7 @@ add_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
} /* If valid entry but not extended calculate the index into Table8. */
else if (lpm->tbl24[tbl24_index].valid_group == 0) {
/* Search for free tbl8 group. */
- tbl8_group_index = tbl8_alloc_v1604(lpm->tbl8, lpm->number_tbl8s);
+ tbl8_group_index = tbl8_alloc(lpm->tbl8, lpm->number_tbl8s);
if (tbl8_group_index < 0) {
return tbl8_group_index;
@@ -1178,48 +660,7 @@ add_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
* Add a route
*/
int
-rte_lpm_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
- uint8_t next_hop)
-{
- int32_t rule_index, status = 0;
- uint32_t ip_masked;
-
- /* Check user arguments. */
- if ((lpm == NULL) || (depth < 1) || (depth > RTE_LPM_MAX_DEPTH))
- return -EINVAL;
-
- ip_masked = ip & depth_to_mask(depth);
-
- /* Add the rule to the rule table. */
- rule_index = rule_add_v20(lpm, ip_masked, depth, next_hop);
-
- /* If the is no space available for new rule return error. */
- if (rule_index < 0) {
- return rule_index;
- }
-
- if (depth <= MAX_DEPTH_TBL24) {
- status = add_depth_small_v20(lpm, ip_masked, depth, next_hop);
- } else { /* If depth > RTE_LPM_MAX_DEPTH_TBL24 */
- status = add_depth_big_v20(lpm, ip_masked, depth, next_hop);
-
- /*
- * If add fails due to exhaustion of tbl8 extensions delete
- * rule that was added to rule table.
- */
- if (status < 0) {
- rule_delete_v20(lpm, rule_index, depth);
-
- return status;
- }
- }
-
- return 0;
-}
-VERSION_SYMBOL(rte_lpm_add, _v20, 2.0);
-
-int
-rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
+rte_lpm_add(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t next_hop)
{
int32_t rule_index, status = 0;
@@ -1232,7 +673,7 @@ rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
ip_masked = ip & depth_to_mask(depth);
/* Add the rule to the rule table. */
- rule_index = rule_add_v1604(lpm, ip_masked, depth, next_hop);
+ rule_index = rule_add(lpm, ip_masked, depth, next_hop);
/* If the is no space available for new rule return error. */
if (rule_index < 0) {
@@ -1240,16 +681,16 @@ rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
}
if (depth <= MAX_DEPTH_TBL24) {
- status = add_depth_small_v1604(lpm, ip_masked, depth, next_hop);
+ status = add_depth_small(lpm, ip_masked, depth, next_hop);
} else { /* If depth > RTE_LPM_MAX_DEPTH_TBL24 */
- status = add_depth_big_v1604(lpm, ip_masked, depth, next_hop);
+ status = add_depth_big(lpm, ip_masked, depth, next_hop);
/*
* If add fails due to exhaustion of tbl8 extensions delete
* rule that was added to rule table.
*/
if (status < 0) {
- rule_delete_v1604(lpm, rule_index, depth);
+ rule_delete(lpm, rule_index, depth);
return status;
}
@@ -1257,42 +698,12 @@ rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
return 0;
}
-BIND_DEFAULT_SYMBOL(rte_lpm_add, _v1604, 16.04);
-MAP_STATIC_SYMBOL(int rte_lpm_add(struct rte_lpm *lpm, uint32_t ip,
- uint8_t depth, uint32_t next_hop), rte_lpm_add_v1604);
/*
* Look for a rule in the high-level rules table
*/
int
-rte_lpm_is_rule_present_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
-uint8_t *next_hop)
-{
- uint32_t ip_masked;
- int32_t rule_index;
-
- /* Check user arguments. */
- if ((lpm == NULL) ||
- (next_hop == NULL) ||
- (depth < 1) || (depth > RTE_LPM_MAX_DEPTH))
- return -EINVAL;
-
- /* Look for the rule using rule_find. */
- ip_masked = ip & depth_to_mask(depth);
- rule_index = rule_find_v20(lpm, ip_masked, depth);
-
- if (rule_index >= 0) {
- *next_hop = lpm->rules_tbl[rule_index].next_hop;
- return 1;
- }
-
- /* If rule is not found return 0. */
- return 0;
-}
-VERSION_SYMBOL(rte_lpm_is_rule_present, _v20, 2.0);
-
-int
-rte_lpm_is_rule_present_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
+rte_lpm_is_rule_present(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t *next_hop)
{
uint32_t ip_masked;
@@ -1306,7 +717,7 @@ uint32_t *next_hop)
/* Look for the rule using rule_find. */
ip_masked = ip & depth_to_mask(depth);
- rule_index = rule_find_v1604(lpm, ip_masked, depth);
+ rule_index = rule_find(lpm, ip_masked, depth);
if (rule_index >= 0) {
*next_hop = lpm->rules_tbl[rule_index].next_hop;
@@ -1316,12 +727,9 @@ uint32_t *next_hop)
/* If rule is not found return 0. */
return 0;
}
-BIND_DEFAULT_SYMBOL(rte_lpm_is_rule_present, _v1604, 16.04);
-MAP_STATIC_SYMBOL(int rte_lpm_is_rule_present(struct rte_lpm *lpm, uint32_t ip,
- uint8_t depth, uint32_t *next_hop), rte_lpm_is_rule_present_v1604);
static int32_t
-find_previous_rule_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
+find_previous_rule(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint8_t *sub_rule_depth)
{
int32_t rule_index;
@@ -1331,7 +739,7 @@ find_previous_rule_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
for (prev_depth = (uint8_t)(depth - 1); prev_depth > 0; prev_depth--) {
ip_masked = ip & depth_to_mask(prev_depth);
- rule_index = rule_find_v20(lpm, ip_masked, prev_depth);
+ rule_index = rule_find(lpm, ip_masked, prev_depth);
if (rule_index >= 0) {
*sub_rule_depth = prev_depth;
@@ -1343,133 +751,7 @@ find_previous_rule_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
}
static int32_t
-find_previous_rule_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
- uint8_t *sub_rule_depth)
-{
- int32_t rule_index;
- uint32_t ip_masked;
- uint8_t prev_depth;
-
- for (prev_depth = (uint8_t)(depth - 1); prev_depth > 0; prev_depth--) {
- ip_masked = ip & depth_to_mask(prev_depth);
-
- rule_index = rule_find_v1604(lpm, ip_masked, prev_depth);
-
- if (rule_index >= 0) {
- *sub_rule_depth = prev_depth;
- return rule_index;
- }
- }
-
- return -1;
-}
-
-static int32_t
-delete_depth_small_v20(struct rte_lpm_v20 *lpm, uint32_t ip_masked,
- uint8_t depth, int32_t sub_rule_index, uint8_t sub_rule_depth)
-{
- uint32_t tbl24_range, tbl24_index, tbl8_group_index, tbl8_index, i, j;
-
- /* Calculate the range and index into Table24. */
- tbl24_range = depth_to_range(depth);
- tbl24_index = (ip_masked >> 8);
-
- /*
- * Firstly check the sub_rule_index. A -1 indicates no replacement rule
- * and a positive number indicates a sub_rule_index.
- */
- if (sub_rule_index < 0) {
- /*
- * If no replacement rule exists then invalidate entries
- * associated with this rule.
- */
- for (i = tbl24_index; i < (tbl24_index + tbl24_range); i++) {
-
- if (lpm->tbl24[i].valid_group == 0 &&
- lpm->tbl24[i].depth <= depth) {
- struct rte_lpm_tbl_entry_v20
- zero_tbl24_entry = {
- .valid = INVALID,
- .depth = 0,
- .valid_group = 0,
- };
- zero_tbl24_entry.next_hop = 0;
- __atomic_store(&lpm->tbl24[i],
- &zero_tbl24_entry, __ATOMIC_RELEASE);
- } else if (lpm->tbl24[i].valid_group == 1) {
- /*
- * If TBL24 entry is extended, then there has
- * to be a rule with depth >= 25 in the
- * associated TBL8 group.
- */
-
- tbl8_group_index = lpm->tbl24[i].group_idx;
- tbl8_index = tbl8_group_index *
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
-
- for (j = tbl8_index; j < (tbl8_index +
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES); j++) {
-
- if (lpm->tbl8[j].depth <= depth)
- lpm->tbl8[j].valid = INVALID;
- }
- }
- }
- } else {
- /*
- * If a replacement rule exists then modify entries
- * associated with this rule.
- */
-
- struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- .next_hop = lpm->rules_tbl[sub_rule_index].next_hop,
- .valid = VALID,
- .valid_group = 0,
- .depth = sub_rule_depth,
- };
-
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = VALID,
- .valid_group = VALID,
- .depth = sub_rule_depth,
- };
- new_tbl8_entry.next_hop =
- lpm->rules_tbl[sub_rule_index].next_hop;
-
- for (i = tbl24_index; i < (tbl24_index + tbl24_range); i++) {
-
- if (lpm->tbl24[i].valid_group == 0 &&
- lpm->tbl24[i].depth <= depth) {
- __atomic_store(&lpm->tbl24[i], &new_tbl24_entry,
- __ATOMIC_RELEASE);
- } else if (lpm->tbl24[i].valid_group == 1) {
- /*
- * If TBL24 entry is extended, then there has
- * to be a rule with depth >= 25 in the
- * associated TBL8 group.
- */
-
- tbl8_group_index = lpm->tbl24[i].group_idx;
- tbl8_index = tbl8_group_index *
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
-
- for (j = tbl8_index; j < (tbl8_index +
- RTE_LPM_TBL8_GROUP_NUM_ENTRIES); j++) {
-
- if (lpm->tbl8[j].depth <= depth)
- __atomic_store(&lpm->tbl8[j],
- &new_tbl8_entry,
- __ATOMIC_RELAXED);
- }
- }
- }
- }
-
- return 0;
-}
-
-static int32_t
-delete_depth_small_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
+delete_depth_small(struct rte_lpm *lpm, uint32_t ip_masked,
uint8_t depth, int32_t sub_rule_index, uint8_t sub_rule_depth)
{
#define group_idx next_hop
@@ -1576,7 +858,7 @@ delete_depth_small_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
* thus can be recycled
*/
static int32_t
-tbl8_recycle_check_v20(struct rte_lpm_tbl_entry_v20 *tbl8,
+tbl8_recycle_check(struct rte_lpm_tbl_entry *tbl8,
uint32_t tbl8_group_start)
{
uint32_t tbl8_group_end, i;
@@ -1623,140 +905,7 @@ tbl8_recycle_check_v20(struct rte_lpm_tbl_entry_v20 *tbl8,
}
static int32_t
-tbl8_recycle_check_v1604(struct rte_lpm_tbl_entry *tbl8,
- uint32_t tbl8_group_start)
-{
- uint32_t tbl8_group_end, i;
- tbl8_group_end = tbl8_group_start + RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
-
- /*
- * Check the first entry of the given tbl8. If it is invalid we know
- * this tbl8 does not contain any rule with a depth < RTE_LPM_MAX_DEPTH
- * (As they would affect all entries in a tbl8) and thus this table
- * can not be recycled.
- */
- if (tbl8[tbl8_group_start].valid) {
- /*
- * If first entry is valid check if the depth is less than 24
- * and if so check the rest of the entries to verify that they
- * are all of this depth.
- */
- if (tbl8[tbl8_group_start].depth <= MAX_DEPTH_TBL24) {
- for (i = (tbl8_group_start + 1); i < tbl8_group_end;
- i++) {
-
- if (tbl8[i].depth !=
- tbl8[tbl8_group_start].depth) {
-
- return -EEXIST;
- }
- }
- /* If all entries are the same return the tb8 index */
- return tbl8_group_start;
- }
-
- return -EEXIST;
- }
- /*
- * If the first entry is invalid check if the rest of the entries in
- * the tbl8 are invalid.
- */
- for (i = (tbl8_group_start + 1); i < tbl8_group_end; i++) {
- if (tbl8[i].valid)
- return -EEXIST;
- }
- /* If no valid entries are found then return -EINVAL. */
- return -EINVAL;
-}
-
-static int32_t
-delete_depth_big_v20(struct rte_lpm_v20 *lpm, uint32_t ip_masked,
- uint8_t depth, int32_t sub_rule_index, uint8_t sub_rule_depth)
-{
- uint32_t tbl24_index, tbl8_group_index, tbl8_group_start, tbl8_index,
- tbl8_range, i;
- int32_t tbl8_recycle_index;
-
- /*
- * Calculate the index into tbl24 and range. Note: All depths larger
- * than MAX_DEPTH_TBL24 are associated with only one tbl24 entry.
- */
- tbl24_index = ip_masked >> 8;
-
- /* Calculate the index into tbl8 and range. */
- tbl8_group_index = lpm->tbl24[tbl24_index].group_idx;
- tbl8_group_start = tbl8_group_index * RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
- tbl8_index = tbl8_group_start + (ip_masked & 0xFF);
- tbl8_range = depth_to_range(depth);
-
- if (sub_rule_index < 0) {
- /*
- * Loop through the range of entries on tbl8 for which the
- * rule_to_delete must be removed or modified.
- */
- for (i = tbl8_index; i < (tbl8_index + tbl8_range); i++) {
- if (lpm->tbl8[i].depth <= depth)
- lpm->tbl8[i].valid = INVALID;
- }
- } else {
- /* Set new tbl8 entry. */
- struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
- .valid = VALID,
- .depth = sub_rule_depth,
- .valid_group = lpm->tbl8[tbl8_group_start].valid_group,
- };
-
- new_tbl8_entry.next_hop =
- lpm->rules_tbl[sub_rule_index].next_hop;
- /*
- * Loop through the range of entries on tbl8 for which the
- * rule_to_delete must be modified.
- */
- for (i = tbl8_index; i < (tbl8_index + tbl8_range); i++) {
- if (lpm->tbl8[i].depth <= depth)
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
- __ATOMIC_RELAXED);
- }
- }
-
- /*
- * Check if there are any valid entries in this tbl8 group. If all
- * tbl8 entries are invalid we can free the tbl8 and invalidate the
- * associated tbl24 entry.
- */
-
- tbl8_recycle_index = tbl8_recycle_check_v20(lpm->tbl8, tbl8_group_start);
-
- if (tbl8_recycle_index == -EINVAL) {
- /* Set tbl24 before freeing tbl8 to avoid race condition.
- * Prevent the free of the tbl8 group from hoisting.
- */
- lpm->tbl24[tbl24_index].valid = 0;
- __atomic_thread_fence(__ATOMIC_RELEASE);
- tbl8_free_v20(lpm->tbl8, tbl8_group_start);
- } else if (tbl8_recycle_index > -1) {
- /* Update tbl24 entry. */
- struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- .next_hop = lpm->tbl8[tbl8_recycle_index].next_hop,
- .valid = VALID,
- .valid_group = 0,
- .depth = lpm->tbl8[tbl8_recycle_index].depth,
- };
-
- /* Set tbl24 before freeing tbl8 to avoid race condition.
- * Prevent the free of the tbl8 group from hoisting.
- */
- __atomic_store(&lpm->tbl24[tbl24_index], &new_tbl24_entry,
- __ATOMIC_RELAXED);
- __atomic_thread_fence(__ATOMIC_RELEASE);
- tbl8_free_v20(lpm->tbl8, tbl8_group_start);
- }
-
- return 0;
-}
-
-static int32_t
-delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
+delete_depth_big(struct rte_lpm *lpm, uint32_t ip_masked,
uint8_t depth, int32_t sub_rule_index, uint8_t sub_rule_depth)
{
#define group_idx next_hop
@@ -1811,7 +960,7 @@ delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
* associated tbl24 entry.
*/
- tbl8_recycle_index = tbl8_recycle_check_v1604(lpm->tbl8, tbl8_group_start);
+ tbl8_recycle_index = tbl8_recycle_check(lpm->tbl8, tbl8_group_start);
if (tbl8_recycle_index == -EINVAL) {
/* Set tbl24 before freeing tbl8 to avoid race condition.
@@ -1819,7 +968,7 @@ delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
*/
lpm->tbl24[tbl24_index].valid = 0;
__atomic_thread_fence(__ATOMIC_RELEASE);
- tbl8_free_v1604(lpm->tbl8, tbl8_group_start);
+ tbl8_free(lpm->tbl8, tbl8_group_start);
} else if (tbl8_recycle_index > -1) {
/* Update tbl24 entry. */
struct rte_lpm_tbl_entry new_tbl24_entry = {
@@ -1835,7 +984,7 @@ delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
__atomic_store(&lpm->tbl24[tbl24_index], &new_tbl24_entry,
__ATOMIC_RELAXED);
__atomic_thread_fence(__ATOMIC_RELEASE);
- tbl8_free_v1604(lpm->tbl8, tbl8_group_start);
+ tbl8_free(lpm->tbl8, tbl8_group_start);
}
#undef group_idx
return 0;
@@ -1845,7 +994,7 @@ delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
* Deletes a rule
*/
int
-rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
+rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
{
int32_t rule_to_delete_index, sub_rule_index;
uint32_t ip_masked;
@@ -1864,7 +1013,7 @@ rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
* Find the index of the input rule, that needs to be deleted, in the
* rule table.
*/
- rule_to_delete_index = rule_find_v20(lpm, ip_masked, depth);
+ rule_to_delete_index = rule_find(lpm, ip_masked, depth);
/*
* Check if rule_to_delete_index was found. If no rule was found the
@@ -1874,7 +1023,7 @@ rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
return -EINVAL;
/* Delete the rule from the rule table. */
- rule_delete_v20(lpm, rule_to_delete_index, depth);
+ rule_delete(lpm, rule_to_delete_index, depth);
/*
* Find rule to replace the rule_to_delete. If there is no rule to
@@ -1882,100 +1031,26 @@ rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
* entries associated with this rule.
*/
sub_rule_depth = 0;
- sub_rule_index = find_previous_rule_v20(lpm, ip, depth, &sub_rule_depth);
+ sub_rule_index = find_previous_rule(lpm, ip, depth, &sub_rule_depth);
/*
* If the input depth value is less than 25 use function
* delete_depth_small otherwise use delete_depth_big.
*/
if (depth <= MAX_DEPTH_TBL24) {
- return delete_depth_small_v20(lpm, ip_masked, depth,
+ return delete_depth_small(lpm, ip_masked, depth,
sub_rule_index, sub_rule_depth);
} else { /* If depth > MAX_DEPTH_TBL24 */
- return delete_depth_big_v20(lpm, ip_masked, depth, sub_rule_index,
+ return delete_depth_big(lpm, ip_masked, depth, sub_rule_index,
sub_rule_depth);
}
}
-VERSION_SYMBOL(rte_lpm_delete, _v20, 2.0);
-
-int
-rte_lpm_delete_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
-{
- int32_t rule_to_delete_index, sub_rule_index;
- uint32_t ip_masked;
- uint8_t sub_rule_depth;
- /*
- * Check input arguments. Note: IP must be a positive integer of 32
- * bits in length therefore it need not be checked.
- */
- if ((lpm == NULL) || (depth < 1) || (depth > RTE_LPM_MAX_DEPTH)) {
- return -EINVAL;
- }
-
- ip_masked = ip & depth_to_mask(depth);
-
- /*
- * Find the index of the input rule, that needs to be deleted, in the
- * rule table.
- */
- rule_to_delete_index = rule_find_v1604(lpm, ip_masked, depth);
-
- /*
- * Check if rule_to_delete_index was found. If no rule was found the
- * function rule_find returns -EINVAL.
- */
- if (rule_to_delete_index < 0)
- return -EINVAL;
-
- /* Delete the rule from the rule table. */
- rule_delete_v1604(lpm, rule_to_delete_index, depth);
-
- /*
- * Find rule to replace the rule_to_delete. If there is no rule to
- * replace the rule_to_delete we return -1 and invalidate the table
- * entries associated with this rule.
- */
- sub_rule_depth = 0;
- sub_rule_index = find_previous_rule_v1604(lpm, ip, depth, &sub_rule_depth);
-
- /*
- * If the input depth value is less than 25 use function
- * delete_depth_small otherwise use delete_depth_big.
- */
- if (depth <= MAX_DEPTH_TBL24) {
- return delete_depth_small_v1604(lpm, ip_masked, depth,
- sub_rule_index, sub_rule_depth);
- } else { /* If depth > MAX_DEPTH_TBL24 */
- return delete_depth_big_v1604(lpm, ip_masked, depth, sub_rule_index,
- sub_rule_depth);
- }
-}
-BIND_DEFAULT_SYMBOL(rte_lpm_delete, _v1604, 16.04);
-MAP_STATIC_SYMBOL(int rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip,
- uint8_t depth), rte_lpm_delete_v1604);
/*
* Delete all rules from the LPM table.
*/
void
-rte_lpm_delete_all_v20(struct rte_lpm_v20 *lpm)
-{
- /* Zero rule information. */
- memset(lpm->rule_info, 0, sizeof(lpm->rule_info));
-
- /* Zero tbl24. */
- memset(lpm->tbl24, 0, sizeof(lpm->tbl24));
-
- /* Zero tbl8. */
- memset(lpm->tbl8, 0, sizeof(lpm->tbl8));
-
- /* Delete all rules form the rules table. */
- memset(lpm->rules_tbl, 0, sizeof(lpm->rules_tbl[0]) * lpm->max_rules);
-}
-VERSION_SYMBOL(rte_lpm_delete_all, _v20, 2.0);
-
-void
-rte_lpm_delete_all_v1604(struct rte_lpm *lpm)
+rte_lpm_delete_all(struct rte_lpm *lpm)
{
/* Zero rule information. */
memset(lpm->rule_info, 0, sizeof(lpm->rule_info));
@@ -1990,6 +1065,3 @@ rte_lpm_delete_all_v1604(struct rte_lpm *lpm)
/* Delete all rules form the rules table. */
memset(lpm->rules_tbl, 0, sizeof(lpm->rules_tbl[0]) * lpm->max_rules);
}
-BIND_DEFAULT_SYMBOL(rte_lpm_delete_all, _v1604, 16.04);
-MAP_STATIC_SYMBOL(void rte_lpm_delete_all(struct rte_lpm *lpm),
- rte_lpm_delete_all_v1604);
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index 26303e6288..b9d49ac879 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -64,31 +64,6 @@ extern "C" {
#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
/** @internal Tbl24 entry structure. */
-__extension__
-struct rte_lpm_tbl_entry_v20 {
- /**
- * Stores Next hop (tbl8 or tbl24 when valid_group is not set) or
- * a group index pointing to a tbl8 structure (tbl24 only, when
- * valid_group is set)
- */
- RTE_STD_C11
- union {
- uint8_t next_hop;
- uint8_t group_idx;
- };
- /* Using single uint8_t to store 3 values. */
- uint8_t valid :1; /**< Validation flag. */
- /**
- * For tbl24:
- * - valid_group == 0: entry stores a next hop
- * - valid_group == 1: entry stores a group_index pointing to a tbl8
- * For tbl8:
- * - valid_group indicates whether the current tbl8 is in use or not
- */
- uint8_t valid_group :1;
- uint8_t depth :6; /**< Rule depth. */
-} __rte_aligned(sizeof(uint16_t));
-
__extension__
struct rte_lpm_tbl_entry {
/**
@@ -111,16 +86,6 @@ struct rte_lpm_tbl_entry {
};
#else
-__extension__
-struct rte_lpm_tbl_entry_v20 {
- uint8_t depth :6;
- uint8_t valid_group :1;
- uint8_t valid :1;
- union {
- uint8_t group_idx;
- uint8_t next_hop;
- };
-} __rte_aligned(sizeof(uint16_t));
__extension__
struct rte_lpm_tbl_entry {
@@ -141,11 +106,6 @@ struct rte_lpm_config {
};
/** @internal Rule structure. */
-struct rte_lpm_rule_v20 {
- uint32_t ip; /**< Rule IP address. */
- uint8_t next_hop; /**< Rule next hop. */
-};
-
struct rte_lpm_rule {
uint32_t ip; /**< Rule IP address. */
uint32_t next_hop; /**< Rule next hop. */
@@ -158,21 +118,6 @@ struct rte_lpm_rule_info {
};
/** @internal LPM structure. */
-struct rte_lpm_v20 {
- /* LPM metadata. */
- char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */
- uint32_t max_rules; /**< Max. balanced rules per lpm. */
- struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH]; /**< Rule info table. */
-
- /* LPM Tables. */
- struct rte_lpm_tbl_entry_v20 tbl24[RTE_LPM_TBL24_NUM_ENTRIES]
- __rte_cache_aligned; /**< LPM tbl24 table. */
- struct rte_lpm_tbl_entry_v20 tbl8[RTE_LPM_TBL8_NUM_ENTRIES]
- __rte_cache_aligned; /**< LPM tbl8 table. */
- struct rte_lpm_rule_v20 rules_tbl[]
- __rte_cache_aligned; /**< LPM rules. */
-};
-
struct rte_lpm {
/* LPM metadata. */
char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */
@@ -209,11 +154,6 @@ struct rte_lpm {
struct rte_lpm *
rte_lpm_create(const char *name, int socket_id,
const struct rte_lpm_config *config);
-struct rte_lpm_v20 *
-rte_lpm_create_v20(const char *name, int socket_id, int max_rules, int flags);
-struct rte_lpm *
-rte_lpm_create_v1604(const char *name, int socket_id,
- const struct rte_lpm_config *config);
/**
* Find an existing LPM object and return a pointer to it.
@@ -227,10 +167,6 @@ rte_lpm_create_v1604(const char *name, int socket_id,
*/
struct rte_lpm *
rte_lpm_find_existing(const char *name);
-struct rte_lpm_v20 *
-rte_lpm_find_existing_v20(const char *name);
-struct rte_lpm *
-rte_lpm_find_existing_v1604(const char *name);
/**
* Free an LPM object.
@@ -242,10 +178,6 @@ rte_lpm_find_existing_v1604(const char *name);
*/
void
rte_lpm_free(struct rte_lpm *lpm);
-void
-rte_lpm_free_v20(struct rte_lpm_v20 *lpm);
-void
-rte_lpm_free_v1604(struct rte_lpm *lpm);
/**
* Add a rule to the LPM table.
@@ -263,12 +195,6 @@ rte_lpm_free_v1604(struct rte_lpm *lpm);
*/
int
rte_lpm_add(struct rte_lpm *lpm, uint32_t ip, uint8_t depth, uint32_t next_hop);
-int
-rte_lpm_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
- uint8_t next_hop);
-int
-rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
- uint32_t next_hop);
/**
* Check if a rule is present in the LPM table,
@@ -288,12 +214,6 @@ rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
int
rte_lpm_is_rule_present(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t *next_hop);
-int
-rte_lpm_is_rule_present_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
-uint8_t *next_hop);
-int
-rte_lpm_is_rule_present_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
-uint32_t *next_hop);
/**
* Delete a rule from the LPM table.
@@ -309,10 +229,6 @@ uint32_t *next_hop);
*/
int
rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip, uint8_t depth);
-int
-rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth);
-int
-rte_lpm_delete_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth);
/**
* Delete all rules from the LPM table.
@@ -322,10 +238,6 @@ rte_lpm_delete_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth);
*/
void
rte_lpm_delete_all(struct rte_lpm *lpm);
-void
-rte_lpm_delete_all_v20(struct rte_lpm_v20 *lpm);
-void
-rte_lpm_delete_all_v1604(struct rte_lpm *lpm);
/**
* Lookup an IP into the LPM table.
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index e20f824602..c46e557e23 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -809,18 +809,6 @@ add_step(struct rte_lpm6 *lpm, struct rte_lpm6_tbl_entry *tbl,
return 1;
}
-/*
- * Add a route
- */
-int
-rte_lpm6_add_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint8_t next_hop)
-{
- return rte_lpm6_add_v1705(lpm, ip, depth, next_hop);
-}
-VERSION_SYMBOL(rte_lpm6_add, _v20, 2.0);
-
-
/*
* Simulate adding a route to LPM
*
@@ -842,7 +830,7 @@ simulate_add(struct rte_lpm6 *lpm, const uint8_t *masked_ip, uint8_t depth)
/* Inspect the first three bytes through tbl24 on the first step. */
ret = simulate_add_step(lpm, lpm->tbl24, &tbl_next, masked_ip,
- ADD_FIRST_BYTE, 1, depth, &need_tbl_nb);
+ ADD_FIRST_BYTE, 1, depth, &need_tbl_nb);
total_need_tbl_nb = need_tbl_nb;
/*
* Inspect one by one the rest of the bytes until
@@ -851,7 +839,7 @@ simulate_add(struct rte_lpm6 *lpm, const uint8_t *masked_ip, uint8_t depth)
for (i = ADD_FIRST_BYTE; i < RTE_LPM6_IPV6_ADDR_SIZE && ret == 1; i++) {
tbl = tbl_next;
ret = simulate_add_step(lpm, tbl, &tbl_next, masked_ip, 1,
- (uint8_t)(i+1), depth, &need_tbl_nb);
+ (uint8_t)(i + 1), depth, &need_tbl_nb);
total_need_tbl_nb += need_tbl_nb;
}
@@ -862,9 +850,12 @@ simulate_add(struct rte_lpm6 *lpm, const uint8_t *masked_ip, uint8_t depth)
return 0;
}
+/*
+ * Add a route
+ */
int
-rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint32_t next_hop)
+rte_lpm6_add(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
+ uint32_t next_hop)
{
struct rte_lpm6_tbl_entry *tbl;
struct rte_lpm6_tbl_entry *tbl_next = NULL;
@@ -896,8 +887,8 @@ rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
/* Inspect the first three bytes through tbl24 on the first step. */
tbl = lpm->tbl24;
status = add_step(lpm, tbl, TBL24_IND, &tbl_next, &tbl_next_num,
- masked_ip, ADD_FIRST_BYTE, 1, depth, next_hop,
- is_new_rule);
+ masked_ip, ADD_FIRST_BYTE, 1, depth, next_hop,
+ is_new_rule);
assert(status >= 0);
/*
@@ -907,17 +898,13 @@ rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
for (i = ADD_FIRST_BYTE; i < RTE_LPM6_IPV6_ADDR_SIZE && status == 1; i++) {
tbl = tbl_next;
status = add_step(lpm, tbl, tbl_next_num, &tbl_next,
- &tbl_next_num, masked_ip, 1, (uint8_t)(i+1),
- depth, next_hop, is_new_rule);
+ &tbl_next_num, masked_ip, 1, (uint8_t)(i + 1),
+ depth, next_hop, is_new_rule);
assert(status >= 0);
}
return status;
}
-BIND_DEFAULT_SYMBOL(rte_lpm6_add, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_lpm6_add(struct rte_lpm6 *lpm, uint8_t *ip,
- uint8_t depth, uint32_t next_hop),
- rte_lpm6_add_v1705);
/*
* Takes a pointer to a table entry and inspect one level.
@@ -956,25 +943,7 @@ lookup_step(const struct rte_lpm6 *lpm, const struct rte_lpm6_tbl_entry *tbl,
* Looks up an IP
*/
int
-rte_lpm6_lookup_v20(const struct rte_lpm6 *lpm, uint8_t *ip, uint8_t *next_hop)
-{
- uint32_t next_hop32 = 0;
- int32_t status;
-
- /* DEBUG: Check user input arguments. */
- if (next_hop == NULL)
- return -EINVAL;
-
- status = rte_lpm6_lookup_v1705(lpm, ip, &next_hop32);
- if (status == 0)
- *next_hop = (uint8_t)next_hop32;
-
- return status;
-}
-VERSION_SYMBOL(rte_lpm6_lookup, _v20, 2.0);
-
-int
-rte_lpm6_lookup_v1705(const struct rte_lpm6 *lpm, uint8_t *ip,
+rte_lpm6_lookup(const struct rte_lpm6 *lpm, uint8_t *ip,
uint32_t *next_hop)
{
const struct rte_lpm6_tbl_entry *tbl;
@@ -1001,56 +970,12 @@ rte_lpm6_lookup_v1705(const struct rte_lpm6 *lpm, uint8_t *ip,
return status;
}
-BIND_DEFAULT_SYMBOL(rte_lpm6_lookup, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_lpm6_lookup(const struct rte_lpm6 *lpm, uint8_t *ip,
- uint32_t *next_hop), rte_lpm6_lookup_v1705);
/*
* Looks up a group of IP addresses
*/
int
-rte_lpm6_lookup_bulk_func_v20(const struct rte_lpm6 *lpm,
- uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
- int16_t * next_hops, unsigned n)
-{
- unsigned i;
- const struct rte_lpm6_tbl_entry *tbl;
- const struct rte_lpm6_tbl_entry *tbl_next = NULL;
- uint32_t tbl24_index, next_hop;
- uint8_t first_byte;
- int status;
-
- /* DEBUG: Check user input arguments. */
- if ((lpm == NULL) || (ips == NULL) || (next_hops == NULL))
- return -EINVAL;
-
- for (i = 0; i < n; i++) {
- first_byte = LOOKUP_FIRST_BYTE;
- tbl24_index = (ips[i][0] << BYTES2_SIZE) |
- (ips[i][1] << BYTE_SIZE) | ips[i][2];
-
- /* Calculate pointer to the first entry to be inspected */
- tbl = &lpm->tbl24[tbl24_index];
-
- do {
- /* Continue inspecting following levels until success or failure */
- status = lookup_step(lpm, tbl, &tbl_next, ips[i], first_byte++,
- &next_hop);
- tbl = tbl_next;
- } while (status == 1);
-
- if (status < 0)
- next_hops[i] = -1;
- else
- next_hops[i] = (int16_t)next_hop;
- }
-
- return 0;
-}
-VERSION_SYMBOL(rte_lpm6_lookup_bulk_func, _v20, 2.0);
-
-int
-rte_lpm6_lookup_bulk_func_v1705(const struct rte_lpm6 *lpm,
+rte_lpm6_lookup_bulk_func(const struct rte_lpm6 *lpm,
uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
int32_t *next_hops, unsigned int n)
{
@@ -1090,37 +1015,12 @@ rte_lpm6_lookup_bulk_func_v1705(const struct rte_lpm6 *lpm,
return 0;
}
-BIND_DEFAULT_SYMBOL(rte_lpm6_lookup_bulk_func, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_lpm6_lookup_bulk_func(const struct rte_lpm6 *lpm,
- uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
- int32_t *next_hops, unsigned int n),
- rte_lpm6_lookup_bulk_func_v1705);
/*
* Look for a rule in the high-level rules table
*/
int
-rte_lpm6_is_rule_present_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint8_t *next_hop)
-{
- uint32_t next_hop32 = 0;
- int32_t status;
-
- /* DEBUG: Check user input arguments. */
- if (next_hop == NULL)
- return -EINVAL;
-
- status = rte_lpm6_is_rule_present_v1705(lpm, ip, depth, &next_hop32);
- if (status > 0)
- *next_hop = (uint8_t)next_hop32;
-
- return status;
-
-}
-VERSION_SYMBOL(rte_lpm6_is_rule_present, _v20, 2.0);
-
-int
-rte_lpm6_is_rule_present_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
+rte_lpm6_is_rule_present(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint32_t *next_hop)
{
uint8_t masked_ip[RTE_LPM6_IPV6_ADDR_SIZE];
@@ -1136,10 +1036,6 @@ rte_lpm6_is_rule_present_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
return rule_find(lpm, masked_ip, depth, next_hop);
}
-BIND_DEFAULT_SYMBOL(rte_lpm6_is_rule_present, _v1705, 17.05);
-MAP_STATIC_SYMBOL(int rte_lpm6_is_rule_present(struct rte_lpm6 *lpm,
- uint8_t *ip, uint8_t depth, uint32_t *next_hop),
- rte_lpm6_is_rule_present_v1705);
/*
* Delete a rule from the rule table.
diff --git a/lib/librte_lpm/rte_lpm6.h b/lib/librte_lpm/rte_lpm6.h
index 5d59ccb1fe..37dfb20249 100644
--- a/lib/librte_lpm/rte_lpm6.h
+++ b/lib/librte_lpm/rte_lpm6.h
@@ -96,12 +96,6 @@ rte_lpm6_free(struct rte_lpm6 *lpm);
int
rte_lpm6_add(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint32_t next_hop);
-int
-rte_lpm6_add_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint8_t next_hop);
-int
-rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint32_t next_hop);
/**
* Check if a rule is present in the LPM table,
@@ -121,12 +115,6 @@ rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
int
rte_lpm6_is_rule_present(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint32_t *next_hop);
-int
-rte_lpm6_is_rule_present_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint8_t *next_hop);
-int
-rte_lpm6_is_rule_present_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint32_t *next_hop);
/**
* Delete a rule from the LPM table.
@@ -184,11 +172,6 @@ rte_lpm6_delete_all(struct rte_lpm6 *lpm);
*/
int
rte_lpm6_lookup(const struct rte_lpm6 *lpm, uint8_t *ip, uint32_t *next_hop);
-int
-rte_lpm6_lookup_v20(const struct rte_lpm6 *lpm, uint8_t *ip, uint8_t *next_hop);
-int
-rte_lpm6_lookup_v1705(const struct rte_lpm6 *lpm, uint8_t *ip,
- uint32_t *next_hop);
/**
* Lookup multiple IP addresses in an LPM table.
@@ -210,14 +193,6 @@ int
rte_lpm6_lookup_bulk_func(const struct rte_lpm6 *lpm,
uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
int32_t *next_hops, unsigned int n);
-int
-rte_lpm6_lookup_bulk_func_v20(const struct rte_lpm6 *lpm,
- uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
- int16_t *next_hops, unsigned int n);
-int
-rte_lpm6_lookup_bulk_func_v1705(const struct rte_lpm6 *lpm,
- uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
- int32_t *next_hops, unsigned int n);
#ifdef __cplusplus
}
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v6 04/10] timer: remove deprecated code
` (5 preceding siblings ...)
2019-11-06 16:54 23% ` [dpdk-dev] [PATCH v6 03/10] buildtools: add ABI update shell script Anatoly Burakov
@ 2019-11-06 16:54 4% ` Anatoly Burakov
2019-11-06 16:54 2% ` [dpdk-dev] [PATCH v6 05/10] lpm: " Anatoly Burakov
` (5 subsequent siblings)
12 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-06 16:54 UTC (permalink / raw)
To: dev
Cc: Marcin Baran, Robert Sanford, Erik Gabriel Carrillo,
john.mcnamara, ray.kinsella, bruce.richardson, thomas,
david.marchand
From: Marcin Baran <marcinx.baran@intel.com>
Remove code for old ABI versions ahead of ABI version bump.
Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
---
Notes:
v2:
- Moved this to before ABI version bump to avoid compile breakage
lib/librte_timer/rte_timer.c | 90 ++----------------------------------
lib/librte_timer/rte_timer.h | 15 ------
2 files changed, 5 insertions(+), 100 deletions(-)
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 3834c94732..ca88454ff6 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -68,9 +68,6 @@ static struct rte_timer_data *rte_timer_data_arr;
static const uint32_t default_data_id;
static uint32_t rte_timer_subsystem_initialized;
-/* For maintaining older interfaces for a period */
-static struct rte_timer_data default_timer_data;
-
/* when debug is enabled, store some statistics */
#ifdef RTE_LIBRTE_TIMER_DEBUG
#define __TIMER_STAT_ADD(priv_timer, name, n) do { \
@@ -131,22 +128,6 @@ rte_timer_data_dealloc(uint32_t id)
return 0;
}
-void
-rte_timer_subsystem_init_v20(void)
-{
- unsigned lcore_id;
- struct priv_timer *priv_timer = default_timer_data.priv_timer;
-
- /* since priv_timer is static, it's zeroed by default, so only init some
- * fields.
- */
- for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id ++) {
- rte_spinlock_init(&priv_timer[lcore_id].list_lock);
- priv_timer[lcore_id].prev_lcore = lcore_id;
- }
-}
-VERSION_SYMBOL(rte_timer_subsystem_init, _v20, 2.0);
-
/* Init the timer library. Allocate an array of timer data structs in shared
* memory, and allocate the zeroth entry for use with original timer
* APIs. Since the intersection of the sets of lcore ids in primary and
@@ -154,7 +135,7 @@ VERSION_SYMBOL(rte_timer_subsystem_init, _v20, 2.0);
* multiple processes.
*/
int
-rte_timer_subsystem_init_v1905(void)
+rte_timer_subsystem_init(void)
{
const struct rte_memzone *mz;
struct rte_timer_data *data;
@@ -209,9 +190,6 @@ rte_timer_subsystem_init_v1905(void)
return 0;
}
-MAP_STATIC_SYMBOL(int rte_timer_subsystem_init(void),
- rte_timer_subsystem_init_v1905);
-BIND_DEFAULT_SYMBOL(rte_timer_subsystem_init, _v1905, 19.05);
void
rte_timer_subsystem_finalize(void)
@@ -552,42 +530,13 @@ __rte_timer_reset(struct rte_timer *tim, uint64_t expire,
/* Reset and start the timer associated with the timer handle tim */
int
-rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
- enum rte_timer_type type, unsigned int tim_lcore,
- rte_timer_cb_t fct, void *arg)
-{
- uint64_t cur_time = rte_get_timer_cycles();
- uint64_t period;
-
- if (unlikely((tim_lcore != (unsigned)LCORE_ID_ANY) &&
- !(rte_lcore_is_enabled(tim_lcore) ||
- rte_lcore_has_role(tim_lcore, ROLE_SERVICE))))
- return -1;
-
- if (type == PERIODICAL)
- period = ticks;
- else
- period = 0;
-
- return __rte_timer_reset(tim, cur_time + ticks, period, tim_lcore,
- fct, arg, 0, &default_timer_data);
-}
-VERSION_SYMBOL(rte_timer_reset, _v20, 2.0);
-
-int
-rte_timer_reset_v1905(struct rte_timer *tim, uint64_t ticks,
+rte_timer_reset(struct rte_timer *tim, uint64_t ticks,
enum rte_timer_type type, unsigned int tim_lcore,
rte_timer_cb_t fct, void *arg)
{
return rte_timer_alt_reset(default_data_id, tim, ticks, type,
tim_lcore, fct, arg);
}
-MAP_STATIC_SYMBOL(int rte_timer_reset(struct rte_timer *tim, uint64_t ticks,
- enum rte_timer_type type,
- unsigned int tim_lcore,
- rte_timer_cb_t fct, void *arg),
- rte_timer_reset_v1905);
-BIND_DEFAULT_SYMBOL(rte_timer_reset, _v1905, 19.05);
int
rte_timer_alt_reset(uint32_t timer_data_id, struct rte_timer *tim,
@@ -658,20 +607,10 @@ __rte_timer_stop(struct rte_timer *tim, int local_is_locked,
/* Stop the timer associated with the timer handle tim */
int
-rte_timer_stop_v20(struct rte_timer *tim)
-{
- return __rte_timer_stop(tim, 0, &default_timer_data);
-}
-VERSION_SYMBOL(rte_timer_stop, _v20, 2.0);
-
-int
-rte_timer_stop_v1905(struct rte_timer *tim)
+rte_timer_stop(struct rte_timer *tim)
{
return rte_timer_alt_stop(default_data_id, tim);
}
-MAP_STATIC_SYMBOL(int rte_timer_stop(struct rte_timer *tim),
- rte_timer_stop_v1905);
-BIND_DEFAULT_SYMBOL(rte_timer_stop, _v1905, 19.05);
int
rte_timer_alt_stop(uint32_t timer_data_id, struct rte_timer *tim)
@@ -817,15 +756,8 @@ __rte_timer_manage(struct rte_timer_data *timer_data)
priv_timer[lcore_id].running_tim = NULL;
}
-void
-rte_timer_manage_v20(void)
-{
- __rte_timer_manage(&default_timer_data);
-}
-VERSION_SYMBOL(rte_timer_manage, _v20, 2.0);
-
int
-rte_timer_manage_v1905(void)
+rte_timer_manage(void)
{
struct rte_timer_data *timer_data;
@@ -835,8 +767,6 @@ rte_timer_manage_v1905(void)
return 0;
}
-MAP_STATIC_SYMBOL(int rte_timer_manage(void), rte_timer_manage_v1905);
-BIND_DEFAULT_SYMBOL(rte_timer_manage, _v1905, 19.05);
int
rte_timer_alt_manage(uint32_t timer_data_id,
@@ -1074,21 +1004,11 @@ __rte_timer_dump_stats(struct rte_timer_data *timer_data __rte_unused, FILE *f)
#endif
}
-void
-rte_timer_dump_stats_v20(FILE *f)
-{
- __rte_timer_dump_stats(&default_timer_data, f);
-}
-VERSION_SYMBOL(rte_timer_dump_stats, _v20, 2.0);
-
int
-rte_timer_dump_stats_v1905(FILE *f)
+rte_timer_dump_stats(FILE *f)
{
return rte_timer_alt_dump_stats(default_data_id, f);
}
-MAP_STATIC_SYMBOL(int rte_timer_dump_stats(FILE *f),
- rte_timer_dump_stats_v1905);
-BIND_DEFAULT_SYMBOL(rte_timer_dump_stats, _v1905, 19.05);
int
rte_timer_alt_dump_stats(uint32_t timer_data_id __rte_unused, FILE *f)
diff --git a/lib/librte_timer/rte_timer.h b/lib/librte_timer/rte_timer.h
index 05d287d8f2..9dc5fc3092 100644
--- a/lib/librte_timer/rte_timer.h
+++ b/lib/librte_timer/rte_timer.h
@@ -181,8 +181,6 @@ int rte_timer_data_dealloc(uint32_t id);
* subsystem
*/
int rte_timer_subsystem_init(void);
-int rte_timer_subsystem_init_v1905(void);
-void rte_timer_subsystem_init_v20(void);
/**
* @warning
@@ -250,13 +248,6 @@ void rte_timer_init(struct rte_timer *tim);
int rte_timer_reset(struct rte_timer *tim, uint64_t ticks,
enum rte_timer_type type, unsigned tim_lcore,
rte_timer_cb_t fct, void *arg);
-int rte_timer_reset_v1905(struct rte_timer *tim, uint64_t ticks,
- enum rte_timer_type type, unsigned int tim_lcore,
- rte_timer_cb_t fct, void *arg);
-int rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
- enum rte_timer_type type, unsigned int tim_lcore,
- rte_timer_cb_t fct, void *arg);
-
/**
* Loop until rte_timer_reset() succeeds.
@@ -313,8 +304,6 @@ rte_timer_reset_sync(struct rte_timer *tim, uint64_t ticks,
* - (-1): The timer is in the RUNNING or CONFIG state.
*/
int rte_timer_stop(struct rte_timer *tim);
-int rte_timer_stop_v1905(struct rte_timer *tim);
-int rte_timer_stop_v20(struct rte_timer *tim);
/**
* Loop until rte_timer_stop() succeeds.
@@ -358,8 +347,6 @@ int rte_timer_pending(struct rte_timer *tim);
* - -EINVAL: timer subsystem not yet initialized
*/
int rte_timer_manage(void);
-int rte_timer_manage_v1905(void);
-void rte_timer_manage_v20(void);
/**
* Dump statistics about timers.
@@ -371,8 +358,6 @@ void rte_timer_manage_v20(void);
* - -EINVAL: timer subsystem not yet initialized
*/
int rte_timer_dump_stats(FILE *f);
-int rte_timer_dump_stats_v1905(FILE *f);
-void rte_timer_dump_stats_v20(FILE *f);
/**
* @warning
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v6 03/10] buildtools: add ABI update shell script
` (4 preceding siblings ...)
2019-11-06 16:54 15% ` [dpdk-dev] [PATCH v6 02/10] buildtools: add script for updating symbols abi version Anatoly Burakov
@ 2019-11-06 16:54 23% ` Anatoly Burakov
2019-11-06 16:54 4% ` [dpdk-dev] [PATCH v6 04/10] timer: remove deprecated code Anatoly Burakov
` (6 subsequent siblings)
12 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-06 16:54 UTC (permalink / raw)
To: dev; +Cc: john.mcnamara, ray.kinsella, bruce.richardson, thomas, david.marchand
In order to facilitate mass updating of version files, add a shell
script that recurses into lib/ and drivers/ directories and calls
the ABI version update script.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
Notes:
v3:
- Switch to sh rather than bash, and remove bash-isms
- Address review comments
v2:
- Add this patch to split the shell script from previous commit
- Fixup miscellaneous bugs
buildtools/update-abi.sh | 42 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100755 buildtools/update-abi.sh
diff --git a/buildtools/update-abi.sh b/buildtools/update-abi.sh
new file mode 100755
index 0000000000..89ba5804a6
--- /dev/null
+++ b/buildtools/update-abi.sh
@@ -0,0 +1,42 @@
+#!/bin/sh
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+
+abi_version=$1
+abi_version_file="./config/ABI_VERSION"
+update_path="lib drivers"
+
+if [ -z "$1" ]; then
+ # output to stderr
+ >&2 echo "Please provide ABI version"
+ exit 1
+fi
+
+# check version string format
+echo $abi_version | grep -q -e "^[[:digit:]]\{1,2\}\.[[:digit:]]\{1,2\}$"
+if [ "$?" -ne 0 ]; then
+ # output to stderr
+ >&2 echo "ABI version must be formatted as MAJOR.MINOR version"
+ exit 1
+fi
+
+if [ -n "$2" ]; then
+ abi_version_file=$2
+fi
+
+if [ -n "$3" ]; then
+ # drop $1 and $2
+ shift 2
+ # assign all other arguments as update paths
+ update_path=$@
+fi
+
+echo "New ABI version:" $abi_version
+echo "ABI_VERSION path:" $abi_version_file
+echo "Path to update:" $update_path
+
+echo $abi_version > $abi_version_file
+
+find $update_path -name \*version.map -exec \
+ ./buildtools/update_version_map_abi.py {} \
+ $abi_version \; -print
--
2.17.1
^ permalink raw reply [relevance 23%]
* [dpdk-dev] [PATCH v6 02/10] buildtools: add script for updating symbols abi version
` (3 preceding siblings ...)
2019-11-06 16:54 7% ` [dpdk-dev] [PATCH v6 01/10] config: change ABI versioning to global Anatoly Burakov
@ 2019-11-06 16:54 15% ` Anatoly Burakov
2019-11-06 16:54 23% ` [dpdk-dev] [PATCH v6 03/10] buildtools: add ABI update shell script Anatoly Burakov
` (7 subsequent siblings)
12 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-06 16:54 UTC (permalink / raw)
To: dev
Cc: Pawel Modrak, john.mcnamara, ray.kinsella, bruce.richardson,
thomas, david.marchand
From: Pawel Modrak <pawelx.modrak@intel.com>
Add a script that automatically merges all stable ABI's under one
ABI section with the new version, while leaving experimental
section exactly as it is.
Signed-off-by: Pawel Modrak <pawelx.modrak@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
Notes:
v6:
- Split map file generation function in two
- Do not print stable ABI if it wasn't present
v3:
- Add comments to regex patterns
v2:
- Reworked script to be pep8-compliant and more reliable
buildtools/update_version_map_abi.py | 171 +++++++++++++++++++++++++++
1 file changed, 171 insertions(+)
create mode 100755 buildtools/update_version_map_abi.py
diff --git a/buildtools/update_version_map_abi.py b/buildtools/update_version_map_abi.py
new file mode 100755
index 0000000000..6dfc856ed3
--- /dev/null
+++ b/buildtools/update_version_map_abi.py
@@ -0,0 +1,171 @@
+#!/usr/bin/env python
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+
+"""
+A Python program to update the ABI version and function names in a DPDK
+lib_*_version.map file. Called from the buildtools/update_abi.sh utility.
+"""
+
+from __future__ import print_function
+import argparse
+import sys
+import re
+
+
+def __parse_map_file(f_in):
+ # match function name, followed by semicolon, followed by EOL, optionally
+ # with whitespace inbetween each item
+ func_line_regex = re.compile(r"\s*"
+ r"(?P<func>[a-zA-Z_0-9]+)"
+ r"\s*"
+ r";"
+ r"\s*"
+ r"$")
+ # match section name, followed by opening bracked, followed by EOL,
+ # optionally with whitespace inbetween each item
+ section_begin_regex = re.compile(r"\s*"
+ r"(?P<version>[a-zA-Z0-9_\.]+)"
+ r"\s*"
+ r"{"
+ r"\s*"
+ r"$")
+ # match closing bracket, optionally followed by section name (for when we
+ # inherit from another ABI version), followed by semicolon, followed by
+ # EOL, optionally with whitespace inbetween each item
+ section_end_regex = re.compile(r"\s*"
+ r"}"
+ r"\s*"
+ r"(?P<parent>[a-zA-Z0-9_\.]+)?"
+ r"\s*"
+ r";"
+ r"\s*"
+ r"$")
+
+ # for stable ABI, we don't care about which version introduced which
+ # function, we just flatten the list. there are dupes in certain files, so
+ # use a set instead of a list
+ stable_lines = set()
+ # copy experimental section as is
+ experimental_lines = []
+ is_experimental = False
+
+ # gather all functions
+ for line in f_in:
+ # clean up the line
+ line = line.strip('\n').strip()
+
+ # is this an end of section?
+ match = section_end_regex.match(line)
+ if match:
+ # whatever section this was, it's not active any more
+ is_experimental = False
+ continue
+
+ # if we're in the middle of experimental section, we need to copy
+ # the section verbatim, so just add the line
+ if is_experimental:
+ experimental_lines += [line]
+ continue
+
+ # skip empty lines
+ if not line:
+ continue
+
+ # is this a beginning of a new section?
+ match = section_begin_regex.match(line)
+ if match:
+ cur_section = match.group("version")
+ # is it experimental?
+ is_experimental = cur_section == "EXPERIMENTAL"
+ continue
+
+ # is this a function?
+ match = func_line_regex.match(line)
+ if match:
+ stable_lines.add(match.group("func"))
+
+ return stable_lines, experimental_lines
+
+
+def __generate_stable_abi(f_out, abi_version, lines):
+ # print ABI version header
+ print("DPDK_{} {{".format(abi_version), file=f_out)
+
+ # print global section if it exists
+ if lines:
+ print("\tglobal:", file=f_out)
+ # blank line
+ print(file=f_out)
+
+ # print all stable lines, alphabetically sorted
+ for line in sorted(lines):
+ print("\t{};".format(line), file=f_out)
+
+ # another blank line
+ print(file=f_out)
+
+ # print local section
+ print("\tlocal: *;", file=f_out)
+
+ # end stable version
+ print("};", file=f_out)
+
+
+def __generate_experimental_abi(f_out, lines, need_newline):
+ if need_newline:
+ # another blank line
+ print(file=f_out)
+
+ # start experimental section
+ print("EXPERIMENTAL {", file=f_out)
+
+ # print all experimental lines as they were
+ for line in lines:
+ # don't print empty whitespace
+ if not line:
+ print("", file=f_out)
+ else:
+ print("\t{}".format(line), file=f_out)
+
+ # end section
+ print("};", file=f_out)
+
+
+def __main():
+ arg_parser = argparse.ArgumentParser(
+ description='Merge versions in linker version script.')
+
+ arg_parser.add_argument("map_file", type=str,
+ help='path to linker version script file '
+ '(pattern: *version.map)')
+ arg_parser.add_argument("abi_version", type=str,
+ help='target ABI version (pattern: MAJOR.MINOR)')
+
+ parsed = arg_parser.parse_args()
+
+ if not parsed.map_file.endswith('version.map'):
+ print("Invalid input file: {}".format(parsed.map_file),
+ file=sys.stderr)
+ arg_parser.print_help()
+ sys.exit(1)
+
+ if not re.match(r"\d{1,2}\.\d{1,2}", parsed.abi_version):
+ print("Invalid ABI version: {}".format(parsed.abi_version),
+ file=sys.stderr)
+ arg_parser.print_help()
+ sys.exit(1)
+
+ with open(parsed.map_file) as f_in:
+ stable_lines, experimental_lines = __parse_map_file(f_in)
+
+ with open(parsed.map_file, 'w') as f_out:
+ if stable_lines or not experimental_lines:
+ __generate_stable_abi(f_out, parsed.abi_version, stable_lines)
+ if experimental_lines:
+ __generate_experimental_abi(f_out, experimental_lines,
+ bool(stable_lines))
+
+
+if __name__ == "__main__":
+ __main()
--
2.17.1
^ permalink raw reply [relevance 15%]
* [dpdk-dev] [PATCH v6 01/10] config: change ABI versioning to global
` (2 preceding siblings ...)
2019-11-06 16:54 8% ` [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
@ 2019-11-06 16:54 7% ` Anatoly Burakov
2019-11-06 16:54 15% ` [dpdk-dev] [PATCH v6 02/10] buildtools: add script for updating symbols abi version Anatoly Burakov
` (8 subsequent siblings)
12 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-11-06 16:54 UTC (permalink / raw)
To: dev
Cc: Marcin Baran, Thomas Monjalon, Bruce Richardson, john.mcnamara,
ray.kinsella, david.marchand, Pawel Modrak
From: Marcin Baran <marcinx.baran@intel.com>
As per new ABI policy, all of the libraries are now versioned using
one global ABI version. Changes in this patch implement the
necessary steps to enable that.
Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
Signed-off-by: Pawel Modrak <pawelx.modrak@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
Notes:
v6:
- Silenced grep error message on trying to grep a directory
v3:
- Removed Windows support from Makefile changes
- Removed unneeded path conversions from meson files
buildtools/meson.build | 2 ++
config/ABI_VERSION | 1 +
config/meson.build | 4 +++-
drivers/meson.build | 20 ++++++++++++--------
lib/meson.build | 18 ++++++++++++------
meson_options.txt | 2 --
mk/rte.lib.mk | 13 ++++---------
7 files changed, 34 insertions(+), 26 deletions(-)
create mode 100644 config/ABI_VERSION
diff --git a/buildtools/meson.build b/buildtools/meson.build
index 32c79c1308..78ce69977d 100644
--- a/buildtools/meson.build
+++ b/buildtools/meson.build
@@ -12,3 +12,5 @@ if python3.found()
else
map_to_def_cmd = ['meson', 'runpython', files('map_to_def.py')]
endif
+
+is_experimental_cmd = [find_program('grep', 'findstr'), '^DPDK_']
diff --git a/config/ABI_VERSION b/config/ABI_VERSION
new file mode 100644
index 0000000000..9a7c1e503f
--- /dev/null
+++ b/config/ABI_VERSION
@@ -0,0 +1 @@
+20.0
diff --git a/config/meson.build b/config/meson.build
index e1ebdad261..2278b12261 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -18,6 +18,8 @@ endforeach
# depending on the configuration options
pver = meson.project_version().split('.')
major_version = '@0@.@1@'.format(pver.get(0), pver.get(1))
+abi_version = run_command(find_program('cat', 'more'),
+ files('ABI_VERSION')).stdout().strip()
# extract all version information into the build configuration
dpdk_conf.set('RTE_VER_YEAR', pver.get(0).to_int())
@@ -37,7 +39,7 @@ endif
pmd_subdir_opt = get_option('drivers_install_subdir')
if pmd_subdir_opt.contains('<VERSION>')
- pmd_subdir_opt = major_version.join(pmd_subdir_opt.split('<VERSION>'))
+ pmd_subdir_opt = abi_version.join(pmd_subdir_opt.split('<VERSION>'))
endif
driver_install_path = join_paths(get_option('libdir'), pmd_subdir_opt)
eal_pmd_path = join_paths(get_option('prefix'), driver_install_path)
diff --git a/drivers/meson.build b/drivers/meson.build
index 156d2dc717..b03e0c3159 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -124,12 +124,19 @@ foreach class:dpdk_driver_classes
output: out_filename,
depends: [pmdinfogen, tmp_lib])
- if get_option('per_library_versions')
- lib_version = '@0@.1'.format(version)
- so_version = '@0@'.format(version)
+ version_map = '@0@/@1@/@2@_version.map'.format(
+ meson.current_source_dir(),
+ drv_path, lib_name)
+
+ is_experimental = run_command(is_experimental_cmd,
+ files(version_map)).returncode()
+
+ if is_experimental != 0
+ lib_version = '0.1'
+ so_version = '0'
else
- lib_version = major_version
- so_version = major_version
+ lib_version = abi_version
+ so_version = abi_version
endif
# now build the static driver
@@ -142,9 +149,6 @@ foreach class:dpdk_driver_classes
install: true)
# now build the shared driver
- version_map = '@0@/@1@/@2@_version.map'.format(
- meson.current_source_dir(),
- drv_path, lib_name)
shared_lib = shared_library(lib_name,
sources,
objects: objs,
diff --git a/lib/meson.build b/lib/meson.build
index b2ec9c09a9..3cff2482b1 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -106,12 +106,18 @@ foreach l:libraries
cflags += '-DRTE_USE_FUNCTION_VERSIONING'
endif
- if get_option('per_library_versions')
- lib_version = '@0@.1'.format(version)
- so_version = '@0@'.format(version)
+ version_map = '@0@/@1@/rte_@2@_version.map'.format(
+ meson.current_source_dir(), dir_name, name)
+
+ is_experimental = run_command(is_experimental_cmd,
+ files(version_map)).returncode()
+
+ if is_experimental != 0
+ lib_version = '0.1'
+ so_version = '0'
else
- lib_version = major_version
- so_version = major_version
+ lib_version = abi_version
+ so_version = abi_version
endif
# first build static lib
@@ -127,7 +133,7 @@ foreach l:libraries
dependencies: static_deps)
if not use_function_versioning
- # use pre-build objects to build shared lib
+ # then use pre-build objects to build shared lib
sources = []
objs += static_lib.extract_all_objects(recursive: false)
else
diff --git a/meson_options.txt b/meson_options.txt
index 89650b0e9c..da6a7f0302 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -30,8 +30,6 @@ option('max_lcores', type: 'integer', value: 128,
description: 'maximum number of cores/threads supported by EAL')
option('max_numa_nodes', type: 'integer', value: 4,
description: 'maximum number of NUMA nodes supported by EAL')
-option('per_library_versions', type: 'boolean', value: true,
- description: 'true: each lib gets its own version number, false: DPDK version used for each lib')
option('tests', type: 'boolean', value: true,
description: 'build unit tests')
option('use_hpet', type: 'boolean', value: false,
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index 4df8849a08..b49af9192b 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -11,20 +11,15 @@ EXTLIB_BUILD ?= n
# VPATH contains at least SRCDIR
VPATH += $(SRCDIR)
-ifneq ($(CONFIG_RTE_MAJOR_ABI),)
-ifneq ($(LIBABIVER),)
-LIBABIVER := $(CONFIG_RTE_MAJOR_ABI)
-endif
+ifneq ($(shell grep -s "^DPDK_" $(SRCDIR)/$(EXPORT_MAP)),)
+LIBABIVER := $(shell cat $(RTE_SRCDIR)/config/ABI_VERSION)
+else
+LIBABIVER := 0
endif
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
LIB := $(patsubst %.a,%.so.$(LIBABIVER),$(LIB))
ifeq ($(EXTLIB_BUILD),n)
-ifeq ($(CONFIG_RTE_MAJOR_ABI),)
-ifeq ($(CONFIG_RTE_NEXT_ABI),y)
-LIB := $(LIB).1
-endif
-endif
CPU_LDFLAGS += --version-script=$(SRCDIR)/$(EXPORT_MAP)
endif
endif
--
2.17.1
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts
@ 2019-11-06 16:54 8% ` Anatoly Burakov
2019-11-08 16:25 8% ` [dpdk-dev] [PATCH v7 " Anatoly Burakov
` (10 more replies)
2019-11-06 16:54 7% ` [dpdk-dev] [PATCH v6 01/10] config: change ABI versioning to global Anatoly Burakov
` (9 subsequent siblings)
12 siblings, 11 replies; 200+ results
From: Anatoly Burakov @ 2019-11-06 16:54 UTC (permalink / raw)
To: dev; +Cc: john.mcnamara, ray.kinsella, bruce.richardson, thomas, david.marchand
This patchset prepares the codebase for the new ABI policy and
adds a few helper scripts.
There are two new scripts for managing ABI versions added. The
first one is a Python script that will read in a .map file,
flatten it and update the ABI version to the ABI version
specified on the command-line.
The second one is a shell script that will run the above mentioned
Python script recursively over the source tree and set the ABI
version to either that which is defined in config/ABI_VERSION, or
a user-specified one.
Example of its usage: buildtools/update-abi.sh 20.0
This will recurse into lib/ and drivers/ directory and update
whatever .map files it can find.
The other shell script that's added is one that can take in a .so
file and ensure that its declared public ABI matches either
current ABI, next ABI, or EXPERIMENTAL. This was moved to the
last commit because it made no sense to have it beforehand.
The source tree was verified to follow the new ABI policy using
the following command (assuming built binaries are in build/):
find ./build/lib ./build/drivers -name \*.so \
-exec ./buildtools/check-abi-version.sh {} \; -print
This returns 0.
Changes since v5:
- Addressed David's comments regarding libtool error messages
- Fixed map file generation to not generate empty stable ABI if
it wasn't there before
Changes since v4:
- Fixed shared library build issue for distributor
Changes since v3:
- Put distributor code back and cleaned it up
- Rebased on latest master and regenerated commit 9
Changes since v2:
- Addressed Bruce's review comments
- Removed single distributor mode as per Dave's suggestion
Changes since v1:
- Reordered patchset to have removal of old ABI's before introducing
the new one to avoid compile breakages between patches
- Added a new patch fixing missing symbol in octeontx common
- Split script commits into multiple commits and reordered them
- Re-generated the ABI bump commit
- Verified all scripts to work
Anatoly Burakov (2):
buildtools: add ABI update shell script
drivers/octeontx: add missing public symbol
Marcin Baran (6):
config: change ABI versioning to global
timer: remove deprecated code
lpm: remove deprecated code
distributor: remove deprecated code
distributor: rename v2.0 ABI to _single suffix
buildtools: add ABI versioning check script
Pawel Modrak (2):
buildtools: add script for updating symbols abi version
build: change ABI version to 20.0
buildtools/check-abi-version.sh | 54 +
buildtools/meson.build | 2 +
buildtools/update-abi.sh | 42 +
buildtools/update_version_map_abi.py | 171 +++
config/ABI_VERSION | 1 +
config/meson.build | 4 +-
.../rte_pmd_bbdev_fpga_lte_fec_version.map | 8 +-
.../null/rte_pmd_bbdev_null_version.map | 2 +-
.../rte_pmd_bbdev_turbo_sw_version.map | 2 +-
drivers/bus/dpaa/rte_bus_dpaa_version.map | 113 +-
drivers/bus/fslmc/rte_bus_fslmc_version.map | 154 ++-
drivers/bus/ifpga/rte_bus_ifpga_version.map | 14 +-
drivers/bus/pci/rte_bus_pci_version.map | 2 +-
drivers/bus/vdev/rte_bus_vdev_version.map | 12 +-
drivers/bus/vmbus/rte_bus_vmbus_version.map | 12 +-
drivers/common/cpt/rte_common_cpt_version.map | 9 +-
.../common/dpaax/rte_common_dpaax_version.map | 14 +-
.../common/mvep/rte_common_mvep_version.map | 6 +-
.../octeontx/rte_common_octeontx_version.map | 7 +-
.../rte_common_octeontx2_version.map | 16 +-
.../compress/isal/rte_pmd_isal_version.map | 2 +-
.../rte_pmd_octeontx_compress_version.map | 2 +-
drivers/compress/qat/rte_pmd_qat_version.map | 2 +-
.../compress/zlib/rte_pmd_zlib_version.map | 2 +-
.../aesni_gcm/rte_pmd_aesni_gcm_version.map | 2 +-
.../aesni_mb/rte_pmd_aesni_mb_version.map | 2 +-
.../crypto/armv8/rte_pmd_armv8_version.map | 2 +-
.../caam_jr/rte_pmd_caam_jr_version.map | 3 +-
drivers/crypto/ccp/rte_pmd_ccp_version.map | 3 +-
.../dpaa2_sec/rte_pmd_dpaa2_sec_version.map | 10 +-
.../dpaa_sec/rte_pmd_dpaa_sec_version.map | 10 +-
.../crypto/kasumi/rte_pmd_kasumi_version.map | 2 +-
.../crypto/mvsam/rte_pmd_mvsam_version.map | 2 +-
.../crypto/nitrox/rte_pmd_nitrox_version.map | 2 +-
.../null/rte_pmd_null_crypto_version.map | 2 +-
.../rte_pmd_octeontx_crypto_version.map | 3 +-
.../rte_pmd_octeontx2_crypto_version.map | 3 +-
.../openssl/rte_pmd_openssl_version.map | 2 +-
.../rte_pmd_crypto_scheduler_version.map | 19 +-
.../crypto/snow3g/rte_pmd_snow3g_version.map | 2 +-
.../virtio/rte_pmd_virtio_crypto_version.map | 2 +-
drivers/crypto/zuc/rte_pmd_zuc_version.map | 2 +-
.../event/dpaa/rte_pmd_dpaa_event_version.map | 3 +-
.../dpaa2/rte_pmd_dpaa2_event_version.map | 2 +-
.../event/dsw/rte_pmd_dsw_event_version.map | 2 +-
.../rte_pmd_octeontx_event_version.map | 2 +-
.../rte_pmd_octeontx2_event_version.map | 3 +-
.../event/opdl/rte_pmd_opdl_event_version.map | 2 +-
.../rte_pmd_skeleton_event_version.map | 3 +-
drivers/event/sw/rte_pmd_sw_event_version.map | 2 +-
.../bucket/rte_mempool_bucket_version.map | 3 +-
.../mempool/dpaa/rte_mempool_dpaa_version.map | 2 +-
.../dpaa2/rte_mempool_dpaa2_version.map | 12 +-
.../octeontx/rte_mempool_octeontx_version.map | 2 +-
.../rte_mempool_octeontx2_version.map | 4 +-
.../mempool/ring/rte_mempool_ring_version.map | 3 +-
.../stack/rte_mempool_stack_version.map | 3 +-
drivers/meson.build | 20 +-
.../af_packet/rte_pmd_af_packet_version.map | 3 +-
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 2 +-
drivers/net/ark/rte_pmd_ark_version.map | 5 +-
.../net/atlantic/rte_pmd_atlantic_version.map | 6 -
drivers/net/avp/rte_pmd_avp_version.map | 2 +-
drivers/net/axgbe/rte_pmd_axgbe_version.map | 2 +-
drivers/net/bnx2x/rte_pmd_bnx2x_version.map | 3 +-
drivers/net/bnxt/rte_pmd_bnxt_version.map | 4 +-
drivers/net/bonding/rte_pmd_bond_version.map | 47 +-
drivers/net/cxgbe/rte_pmd_cxgbe_version.map | 3 +-
drivers/net/dpaa/rte_pmd_dpaa_version.map | 11 +-
drivers/net/dpaa2/rte_pmd_dpaa2_version.map | 12 +-
drivers/net/e1000/rte_pmd_e1000_version.map | 3 +-
drivers/net/ena/rte_pmd_ena_version.map | 3 +-
drivers/net/enetc/rte_pmd_enetc_version.map | 3 +-
drivers/net/enic/rte_pmd_enic_version.map | 3 +-
.../net/failsafe/rte_pmd_failsafe_version.map | 3 +-
drivers/net/fm10k/rte_pmd_fm10k_version.map | 3 +-
drivers/net/hinic/rte_pmd_hinic_version.map | 3 +-
drivers/net/hns3/rte_pmd_hns3_version.map | 4 +-
drivers/net/i40e/rte_pmd_i40e_version.map | 65 +-
drivers/net/iavf/rte_pmd_iavf_version.map | 3 +-
drivers/net/ice/rte_pmd_ice_version.map | 3 +-
drivers/net/ifc/rte_pmd_ifc_version.map | 3 +-
drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map | 3 +-
drivers/net/ixgbe/rte_pmd_ixgbe_version.map | 62 +-
drivers/net/kni/rte_pmd_kni_version.map | 3 +-
.../net/liquidio/rte_pmd_liquidio_version.map | 3 +-
drivers/net/memif/rte_pmd_memif_version.map | 5 +-
drivers/net/mlx4/rte_pmd_mlx4_version.map | 3 +-
drivers/net/mlx5/rte_pmd_mlx5_version.map | 2 +-
drivers/net/mvneta/rte_pmd_mvneta_version.map | 2 +-
drivers/net/mvpp2/rte_pmd_mvpp2_version.map | 2 +-
drivers/net/netvsc/rte_pmd_netvsc_version.map | 4 +-
drivers/net/nfb/rte_pmd_nfb_version.map | 3 +-
drivers/net/nfp/rte_pmd_nfp_version.map | 2 +-
drivers/net/null/rte_pmd_null_version.map | 3 +-
.../net/octeontx/rte_pmd_octeontx_version.map | 10 +-
.../octeontx2/rte_pmd_octeontx2_version.map | 3 +-
drivers/net/pcap/rte_pmd_pcap_version.map | 3 +-
drivers/net/pfe/rte_pmd_pfe_version.map | 3 +-
drivers/net/qede/rte_pmd_qede_version.map | 3 +-
drivers/net/ring/rte_pmd_ring_version.map | 10 +-
drivers/net/sfc/rte_pmd_sfc_version.map | 3 +-
.../net/softnic/rte_pmd_softnic_version.map | 2 +-
.../net/szedata2/rte_pmd_szedata2_version.map | 2 +-
drivers/net/tap/rte_pmd_tap_version.map | 3 +-
.../net/thunderx/rte_pmd_thunderx_version.map | 3 +-
.../rte_pmd_vdev_netvsc_version.map | 3 +-
drivers/net/vhost/rte_pmd_vhost_version.map | 11 +-
drivers/net/virtio/rte_pmd_virtio_version.map | 3 +-
.../net/vmxnet3/rte_pmd_vmxnet3_version.map | 3 +-
.../rte_rawdev_dpaa2_cmdif_version.map | 3 +-
.../rte_rawdev_dpaa2_qdma_version.map | 4 +-
.../raw/ifpga/rte_rawdev_ifpga_version.map | 3 +-
drivers/raw/ioat/rte_rawdev_ioat_version.map | 3 +-
drivers/raw/ntb/rte_rawdev_ntb_version.map | 5 +-
.../rte_rawdev_octeontx2_dma_version.map | 3 +-
.../skeleton/rte_rawdev_skeleton_version.map | 3 +-
lib/librte_acl/rte_acl_version.map | 2 +-
.../rte_bitratestats_version.map | 2 +-
lib/librte_cfgfile/rte_cfgfile_version.map | 34 +-
lib/librte_cmdline/rte_cmdline_version.map | 10 +-
.../rte_cryptodev_version.map | 102 +-
lib/librte_distributor/Makefile | 2 +-
lib/librte_distributor/distributor_private.h | 10 +-
lib/librte_distributor/meson.build | 2 +-
lib/librte_distributor/rte_distributor.c | 80 +-
...ributor_v20.c => rte_distributor_single.c} | 57 +-
...ributor_v20.h => rte_distributor_single.h} | 26 +-
.../rte_distributor_v1705.h | 61 --
.../rte_distributor_version.map | 16 +-
lib/librte_eal/rte_eal_version.map | 324 ++----
lib/librte_efd/rte_efd_version.map | 2 +-
lib/librte_ethdev/rte_ethdev_version.map | 160 +--
lib/librte_eventdev/rte_eventdev_version.map | 130 +--
lib/librte_gro/rte_gro_version.map | 2 +-
lib/librte_gso/rte_gso_version.map | 2 +-
lib/librte_hash/rte_hash_version.map | 43 +-
lib/librte_ip_frag/rte_ip_frag_version.map | 10 +-
lib/librte_jobstats/rte_jobstats_version.map | 10 +-
lib/librte_kni/rte_kni_version.map | 2 +-
lib/librte_kvargs/rte_kvargs_version.map | 4 +-
.../rte_latencystats_version.map | 2 +-
lib/librte_lpm/rte_lpm.c | 996 +-----------------
lib/librte_lpm/rte_lpm.h | 88 --
lib/librte_lpm/rte_lpm6.c | 132 +--
lib/librte_lpm/rte_lpm6.h | 25 -
lib/librte_lpm/rte_lpm_version.map | 39 +-
lib/librte_mbuf/rte_mbuf_version.map | 49 +-
lib/librte_member/rte_member_version.map | 2 +-
lib/librte_mempool/rte_mempool_version.map | 44 +-
lib/librte_meter/rte_meter_version.map | 13 +-
lib/librte_metrics/rte_metrics_version.map | 2 +-
lib/librte_net/rte_net_version.map | 23 +-
lib/librte_pci/rte_pci_version.map | 2 +-
lib/librte_pdump/rte_pdump_version.map | 2 +-
lib/librte_pipeline/rte_pipeline_version.map | 36 +-
lib/librte_port/rte_port_version.map | 64 +-
lib/librte_power/rte_power_version.map | 24 +-
lib/librte_rawdev/rte_rawdev_version.map | 4 +-
lib/librte_reorder/rte_reorder_version.map | 8 +-
lib/librte_ring/rte_ring_version.map | 10 +-
lib/librte_sched/rte_sched_version.map | 14 +-
lib/librte_security/rte_security_version.map | 2 +-
lib/librte_table/rte_table_version.map | 2 +-
lib/librte_timer/rte_timer.c | 90 +-
lib/librte_timer/rte_timer.h | 15 -
lib/librte_timer/rte_timer_version.map | 12 +-
lib/librte_vhost/rte_vhost_version.map | 52 +-
lib/meson.build | 18 +-
meson_options.txt | 2 -
mk/rte.lib.mk | 13 +-
171 files changed, 1114 insertions(+), 2943 deletions(-)
create mode 100755 buildtools/check-abi-version.sh
create mode 100755 buildtools/update-abi.sh
create mode 100755 buildtools/update_version_map_abi.py
create mode 100644 config/ABI_VERSION
rename lib/librte_distributor/{rte_distributor_v20.c => rte_distributor_single.c} (85%)
rename lib/librte_distributor/{rte_distributor_v20.h => rte_distributor_single.h} (89%)
delete mode 100644 lib/librte_distributor/rte_distributor_v1705.h
--
2.17.1
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v8 4/4] doc: add maintainer for abi policy
2019-11-05 15:24 13% ` [dpdk-dev] [PATCH v8 4/4] doc: add maintainer for abi policy Ray Kinsella
@ 2019-11-06 16:13 4% ` Mcnamara, John
0 siblings, 0 replies; 200+ results
From: Mcnamara, John @ 2019-11-06 16:13 UTC (permalink / raw)
To: Ray Kinsella, dev
Cc: thomas, stephen, Richardson, Bruce, Yigit, Ferruh, Ananyev,
Konstantin, jerinj, olivier.matz, nhorman, maxime.coquelin,
Kovacevic, Marko, hemant.agrawal, ktraynor, aconole
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Tuesday, November 5, 2019 3:24 PM
> To: dev@dpdk.org
> Cc: mdr@ashroe.eu; thomas@monjalon.net; stephen@networkplumber.org;
> Richardson, Bruce <bruce.richardson@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; jerinj@marvell.com;
> olivier.matz@6wind.com; nhorman@tuxdriver.com;
> maxime.coquelin@redhat.com; Mcnamara, John <john.mcnamara@intel.com>;
> Kovacevic, Marko <marko.kovacevic@intel.com>; hemant.agrawal@nxp.com;
> ktraynor@redhat.com; aconole@redhat.com
> Subject: [PATCH v8 4/4] doc: add maintainer for abi policy
>
> Add an entry to the maintainer file for the abi policy.
>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v8 3/4] doc: updates to versioning guide for abi versions
2019-11-05 15:24 35% ` [dpdk-dev] [PATCH v8 3/4] doc: updates to versioning guide for " Ray Kinsella
2019-11-05 17:37 4% ` Stephen Hemminger
@ 2019-11-06 16:13 4% ` Mcnamara, John
1 sibling, 0 replies; 200+ results
From: Mcnamara, John @ 2019-11-06 16:13 UTC (permalink / raw)
To: Ray Kinsella, dev
Cc: thomas, stephen, Richardson, Bruce, Yigit, Ferruh, Ananyev,
Konstantin, jerinj, olivier.matz, nhorman, maxime.coquelin,
Kovacevic, Marko, hemant.agrawal, ktraynor, aconole
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Tuesday, November 5, 2019 3:24 PM
> To: dev@dpdk.org
> Cc: mdr@ashroe.eu; thomas@monjalon.net; stephen@networkplumber.org;
> Richardson, Bruce <bruce.richardson@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; jerinj@marvell.com;
> olivier.matz@6wind.com; nhorman@tuxdriver.com;
> maxime.coquelin@redhat.com; Mcnamara, John <john.mcnamara@intel.com>;
> Kovacevic, Marko <marko.kovacevic@intel.com>; hemant.agrawal@nxp.com;
> ktraynor@redhat.com; aconole@redhat.com
> Subject: [PATCH v8 3/4] doc: updates to versioning guide for abi versions
>
> Updates to the ABI versioning guide, to account for the changes to the
> DPDK ABI/API policy. Fixes for references to abi versioning and policy
> guides.
>
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions
2019-11-05 15:24 23% ` [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-11-05 17:37 5% ` Stephen Hemminger
2019-11-06 0:11 11% ` Thomas Monjalon
@ 2019-11-06 16:12 5% ` Mcnamara, John
2 siblings, 0 replies; 200+ results
From: Mcnamara, John @ 2019-11-06 16:12 UTC (permalink / raw)
To: Ray Kinsella, dev
Cc: thomas, stephen, Richardson, Bruce, Yigit, Ferruh, Ananyev,
Konstantin, jerinj, olivier.matz, nhorman, maxime.coquelin,
Kovacevic, Marko, hemant.agrawal, ktraynor, aconole
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Tuesday, November 5, 2019 3:24 PM
> To: dev@dpdk.org
> Cc: mdr@ashroe.eu; thomas@monjalon.net; stephen@networkplumber.org;
> Richardson, Bruce <bruce.richardson@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; jerinj@marvell.com;
> olivier.matz@6wind.com; nhorman@tuxdriver.com;
> maxime.coquelin@redhat.com; Mcnamara, John <john.mcnamara@intel.com>;
> Kovacevic, Marko <marko.kovacevic@intel.com>; hemant.agrawal@nxp.com;
> ktraynor@redhat.com; aconole@redhat.com
> Subject: [PATCH v8 2/4] doc: changes to abi policy introducing major abi
> versions
>
> This policy change introduces major ABI versions, these are
> declared every year, typically aligned with the LTS release
> and are supported by subsequent releases in the following year.
> This change is intended to improve ABI stabilty for those projects
> consuming DPDK.
>
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v8 1/4] doc: separate versioning.rst into version and policy
2019-11-05 15:24 18% ` [dpdk-dev] [PATCH v8 1/4] doc: separate versioning.rst into version and policy Ray Kinsella
2019-11-05 17:37 0% ` Stephen Hemminger
@ 2019-11-06 16:11 0% ` Mcnamara, John
1 sibling, 0 replies; 200+ results
From: Mcnamara, John @ 2019-11-06 16:11 UTC (permalink / raw)
To: Ray Kinsella, dev
Cc: thomas, stephen, Richardson, Bruce, Yigit, Ferruh, Ananyev,
Konstantin, jerinj, olivier.matz, nhorman, maxime.coquelin,
Kovacevic, Marko, hemant.agrawal, ktraynor, aconole
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Tuesday, November 5, 2019 3:24 PM
> To: dev@dpdk.org
> Cc: mdr@ashroe.eu; thomas@monjalon.net; stephen@networkplumber.org;
> Richardson, Bruce <bruce.richardson@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; jerinj@marvell.com;
> olivier.matz@6wind.com; nhorman@tuxdriver.com;
> maxime.coquelin@redhat.com; Mcnamara, John <john.mcnamara@intel.com>;
> Kovacevic, Marko <marko.kovacevic@intel.com>; hemant.agrawal@nxp.com;
> ktraynor@redhat.com; aconole@redhat.com
> Subject: [PATCH v8 1/4] doc: separate versioning.rst into version and
> policy
>
> Separate versioning.rst into abi versioning and abi policy guidance, in
> preparation for adding more detail to the abi policy.
>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 02/10] buildtools: add script for updating symbols abi version
@ 2019-11-06 15:38 8% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-11-06 15:38 UTC (permalink / raw)
To: Anatoly Burakov
Cc: dev, Pawel Modrak, Mcnamara, John, Kinsella, Ray,
Bruce Richardson, Thomas Monjalon
On Thu, Oct 24, 2019 at 11:46 AM Anatoly Burakov
<anatoly.burakov@intel.com> wrote:
>
> From: Pawel Modrak <pawelx.modrak@intel.com>
>
> Add a script that automatically merges all stable ABI's under one
> ABI section with the new version, while leaving experimental
> section exactly as it is.
>
> Signed-off-by: Pawel Modrak <pawelx.modrak@intel.com>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
>
> Notes:
> v3:
> - Add comments to regex patterns
>
> v2:
> - Reworked script to be pep8-compliant and more reliable
>
> buildtools/update_version_map_abi.py | 170 +++++++++++++++++++++++++++
> 1 file changed, 170 insertions(+)
> create mode 100755 buildtools/update_version_map_abi.py
>
> diff --git a/buildtools/update_version_map_abi.py b/buildtools/update_version_map_abi.py
> new file mode 100755
> index 0000000000..50283e6a3d
> --- /dev/null
> +++ b/buildtools/update_version_map_abi.py
> @@ -0,0 +1,170 @@
> +#!/usr/bin/env python
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright(c) 2019 Intel Corporation
> +
> +"""
> +A Python program to update the ABI version and function names in a DPDK
> +lib_*_version.map file. Called from the buildtools/update_abi.sh utility.
> +"""
> +
> +from __future__ import print_function
> +import argparse
> +import sys
> +import re
> +
> +
> +def __parse_map_file(f_in):
> + # match function name, followed by semicolon, followed by EOL, optionally
> + # with whitespace inbetween each item
> + func_line_regex = re.compile(r"\s*"
> + r"(?P<func>[a-zA-Z_0-9]+)"
> + r"\s*"
> + r";"
> + r"\s*"
> + r"$")
> + # match section name, followed by opening bracked, followed by EOL,
> + # optionally with whitespace inbetween each item
> + section_begin_regex = re.compile(r"\s*"
> + r"(?P<version>[a-zA-Z0-9_\.]+)"
> + r"\s*"
> + r"{"
> + r"\s*"
> + r"$")
> + # match closing bracket, optionally followed by section name (for when we
> + # inherit from another ABI version), followed by semicolon, followed by
> + # EOL, optionally with whitespace inbetween each item
> + section_end_regex = re.compile(r"\s*"
> + r"}"
> + r"\s*"
> + r"(?P<parent>[a-zA-Z0-9_\.]+)?"
> + r"\s*"
> + r";"
> + r"\s*"
> + r"$")
> +
> + # for stable ABI, we don't care about which version introduced which
> + # function, we just flatten the list. there are dupes in certain files, so
> + # use a set instead of a list
> + stable_lines = set()
> + # copy experimental section as is
> + experimental_lines = []
> + is_experimental = False
> +
> + # gather all functions
> + for line in f_in:
> + # clean up the line
> + line = line.strip('\n').strip()
> +
> + # is this an end of section?
> + match = section_end_regex.match(line)
> + if match:
> + # whatever section this was, it's not active any more
> + is_experimental = False
> + continue
> +
> + # if we're in the middle of experimental section, we need to copy
> + # the section verbatim, so just add the line
> + if is_experimental:
> + experimental_lines += [line]
> + continue
> +
> + # skip empty lines
> + if not line:
> + continue
> +
> + # is this a beginning of a new section?
> + match = section_begin_regex.match(line)
> + if match:
> + cur_section = match.group("version")
> + # is it experimental?
> + is_experimental = cur_section == "EXPERIMENTAL"
> + continue
> +
> + # is this a function?
> + match = func_line_regex.match(line)
> + if match:
> + stable_lines.add(match.group("func"))
> +
> + return stable_lines, experimental_lines
> +
> +
> +def __regenerate_map_file(f_out, abi_version, stable_lines,
> + experimental_lines):
> + # print ABI version header
> + print("DPDK_{} {{".format(abi_version), file=f_out)
Some libraries are entirely experimental (librte_bpf for example).
https://patchwork.dpdk.org/patch/62018/
+Libraries marked as ``experimental`` are entirely not considered part of an ABI
+version, and may change without warning at any time. Experimental libraries
+always have a major version of ``0`` to indicate they exist outside of
+:ref:`abi_versioning` , with the minor version incremented with each ABI change
+to library.
So you must create a DPDK_XX "stable" block only if the map file
contained a non empty "stable" block before.
--
David Marchand
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v6 2/3] ipsec: remove redundant replay_win_sz
2019-11-06 14:27 0% ` Ananyev, Konstantin
@ 2019-11-06 14:29 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2019-11-06 14:29 UTC (permalink / raw)
To: Ananyev, Konstantin, Hemant Agrawal, dev
>
> > > > The rte_security lib has introduced replay_win_sz,
> > > > so it can be removed from the rte_ipsec lib.
> > > >
> > > > The relaved tests,app are also update to reflect
> > > > the usages.
> > > >
> > > > Note that esn and anti-replay fileds were earlier used
> > > > only for ipsec library, they were enabling the libipsec
> > > > by default. With this change esn and anti-replay setting
> > > > will not automatically enabled libipsec.
> > > >
> > > > Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > ---
> > > > app/test/test_ipsec.c | 2 +-
> > > > doc/guides/rel_notes/release_19_11.rst | 7 +++++--
> > > > examples/ipsec-secgw/ipsec-secgw.c | 5 -----
> > > > examples/ipsec-secgw/ipsec.c | 4 ++++
> > > > examples/ipsec-secgw/sa.c | 2 +-
> > > > lib/librte_ipsec/Makefile | 2 +-
> > > > lib/librte_ipsec/meson.build | 1 +
> > > > lib/librte_ipsec/rte_ipsec_sa.h | 6 ------
> > > > lib/librte_ipsec/sa.c | 4 ++--
> > > > 9 files changed, 15 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
> > > > index 4007eff19..7dc83fee7 100644
> > > > --- a/app/test/test_ipsec.c
> > > > +++ b/app/test/test_ipsec.c
> > > > @@ -689,11 +689,11 @@ fill_ipsec_param(uint32_t replay_win_sz,
> uint64_t
> > > flags)
> > > >
> > > > prm->userdata = 1;
> > > > prm->flags = flags;
> > > > - prm->replay_win_sz = replay_win_sz;
> > > >
> > > > /* setup ipsec xform */
> > > > prm->ipsec_xform = ut_params->ipsec_xform;
> > > > prm->ipsec_xform.salt = (uint32_t)rte_rand();
> > > > + prm->ipsec_xform.replay_win_sz = replay_win_sz;
> > > >
> > > > /* setup tunnel related fields */
> > > > prm->tun.hdr_len = sizeof(ipv4_outer);
> > > > diff --git a/doc/guides/rel_notes/release_19_11.rst
> > > b/doc/guides/rel_notes/release_19_11.rst
> > > > index dcae08002..0504a3443 100644
> > > > --- a/doc/guides/rel_notes/release_19_11.rst
> > > > +++ b/doc/guides/rel_notes/release_19_11.rst
> > > > @@ -369,10 +369,13 @@ ABI Changes
> > > > align the Ethernet header on receive and all known encapsulations
> > > > preserve the alignment of the header.
> > > >
> > > > -* security: A new field ''replay_win_sz'' has been added to the structure
> > > > +* security: The field ''replay_win_sz'' has been moved from ipsec library
> > > > + based ''rte_ipsec_sa_prm'' structure to security library based structure
> > > > ``rte_security_ipsec_xform``, which specify the Anti replay window size
> > > > to enable sequence replay attack handling.
> > > >
> > > > +* ipsec: The field ''replay_win_sz'' has been removed from the structure
> > > > + ''rte_ipsec_sa_prm'' as it has been added to the security library.
> > > >
> > > > Shared Library Versions
> > > > -----------------------
> > > > @@ -415,7 +418,7 @@ The libraries prepended with a plus sign were
> > > incremented in this version.
> > > > librte_gso.so.1
> > > > librte_hash.so.2
> > > > librte_ip_frag.so.1
> > > > - librte_ipsec.so.1
> > > > + + librte_ipsec.so.2
> > > > librte_jobstats.so.1
> > > > librte_kni.so.2
> > > > librte_kvargs.so.1
> > > > diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-
> > > secgw/ipsec-secgw.c
> > > > index b12936470..3b5aaf683 100644
> > > > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > > > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > > > @@ -1424,9 +1424,6 @@ print_app_sa_prm(const struct app_sa_prm
> *prm)
> > > > printf("librte_ipsec usage: %s\n",
> > > > (prm->enable == 0) ? "disabled" : "enabled");
> > > >
> > > > - if (prm->enable == 0)
> > > > - return;
> > > > -
> > > > printf("replay window size: %u\n", prm->window_size);
> > > > printf("ESN: %s\n", (prm->enable_esn == 0) ? "disabled" : "enabled");
> > > > printf("SA flags: %#" PRIx64 "\n", prm->flags);
> > > > @@ -1495,11 +1492,9 @@ parse_args(int32_t argc, char **argv)
> > > > app_sa_prm.enable = 1;
> > > > break;
> > > > case 'w':
> > > > - app_sa_prm.enable = 1;
> > >
> > > That actually will break lib-mode functional tests at:
> > > examples/ipsec-secgw/test/
> > > Due to my laziness I enabled in them library mode via '-w' option,
> > > as that moment legacy mode didn't support replay window...
> > > As these patches already applied, I'll send the fix in a new one in next few.
> >
> > No issues, I will squash your changes with the original patch as it is not applied
> > On master.
>
> Ok, thanks.
> Patch at:
> http://patches.dpdk.org/patch/62540/
Removed the fixes line for this patch. Rebased the tree so that script patch is just after this patch.
Applied
>
> >
> > >
> > > > app_sa_prm.window_size = parse_decimal(optarg);
> > > > break;
> > > > case 'e':
> > > > - app_sa_prm.enable = 1;
> > > > app_sa_prm.enable_esn = 1;
> > > > break;
> > > > case 'a':
> > > > diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> > > > index d7761e966..d4b57121a 100644
> > > > --- a/examples/ipsec-secgw/ipsec.c
> > > > +++ b/examples/ipsec-secgw/ipsec.c
> > > > @@ -49,6 +49,8 @@ set_ipsec_conf(struct ipsec_sa *sa, struct
> > > rte_security_ipsec_xform *ipsec)
> > > > /* TODO support for Transport */
> > > > }
> > > > ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
> > > > + ipsec->replay_win_sz = app_sa_prm.window_size;
> > > > + ipsec->options.esn = app_sa_prm.enable_esn;
> > >
> > > Ok, but what to do for the devices that don't support esn or replay_win_sz?
> > > Should we add some check? Either to the app, or preferably into rte_security
> > > level at rte_security_session_create()?
> >
> > Ideally app should check the capability of the device before setting it.
>
> Yes... after another thought - as right now we do create session at run-time,
> probably we need to check these device capabilities at init stage and report an
> error.
Agreed
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3 1/3] ethdev: support API to set max LRO packet size
@ 2019-11-06 14:28 3% ` Dekel Peled
1 sibling, 0 replies; 200+ results
From: Dekel Peled @ 2019-11-06 14:28 UTC (permalink / raw)
To: john.mcnamara, marko.kovacevic, nhorman, ajit.khaparde,
somnath.kotur, anatoly.burakov, xuanziyang2, cloud.wangxiaoyun,
zhouguoyang, wenzhuo.lu, konstantin.ananyev, matan, shahafs,
viacheslavo, rmody, shshaikh, maxime.coquelin, tiwei.bie,
zhihong.wang, yongwang, thomas, ferruh.yigit, arybchenko,
jingjing.wu, bernard.iremonger
Cc: dev
This patch implements [1], to support API for configuration and
validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11
are updated accordingly.
Various PMDs using LRO offload are updated, the new data members are
initialized to ensure they don't fail validation.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/
Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
---
doc/guides/nics/features.rst | 2 ++
doc/guides/rel_notes/deprecation.rst | 4 ---
doc/guides/rel_notes/release_19_11.rst | 8 ++++++
drivers/net/bnxt/bnxt_ethdev.c | 1 +
drivers/net/hinic/hinic_pmd_ethdev.c | 1 +
drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++
drivers/net/ixgbe/ixgbe_vf_representor.c | 1 +
drivers/net/mlx5/mlx5.h | 3 +++
drivers/net/mlx5/mlx5_ethdev.c | 1 +
drivers/net/mlx5/mlx5_rxq.c | 1 -
drivers/net/qede/qede_ethdev.c | 1 +
drivers/net/virtio/virtio_ethdev.c | 1 +
drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 +
lib/librte_ethdev/rte_ethdev.c | 44 ++++++++++++++++++++++++++++++++
lib/librte_ethdev/rte_ethdev.h | 4 +++
15 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index d966968..4d1bb5a 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -193,10 +193,12 @@ LRO
Supports Large Receive Offload.
* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_TCP_LRO``.
+ ``dev_conf.rxmode.max_lro_pkt_size``.
* **[implements] datapath**: ``LRO functionality``.
* **[implements] rte_eth_dev_data**: ``lro``.
* **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``.
* **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``.
+* **[provides] rte_eth_dev_info**: ``max_lro_pkt_size``.
.. _nic_features_tso:
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index c10dc30..fdec33d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -87,10 +87,6 @@ Deprecation Notices
This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and
thereby improve Rx performance if application wishes do so.
-* ethdev: New 32-bit fields may be added for maximum LRO session size, in
- struct ``rte_eth_dev_info`` for the port capability and in struct
- ``rte_eth_rxmode`` for the port configuration.
-
* cryptodev: support for using IV with all sizes is added, J0 still can
be used but only when IV length in following structs ``rte_crypto_auth_xform``,
``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index f96ac38..9bffb16 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -380,6 +380,14 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
+* ethdev: Added 32-bit fields for maximum LRO aggregated packet size, in
+ struct ``rte_eth_dev_info`` for the port capability and in struct
+ ``rte_eth_rxmode`` for the port configuration.
+ Application should use the new field in struct ``rte_eth_rxmode`` to configure
+ the requested size.
+ PMD should use the new field in struct ``rte_eth_dev_info`` to report the
+ supported port capability.
+
Shared Library Versions
-----------------------
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 7d9459f..88af61b 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -535,6 +535,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,
/* Fast path specifics */
dev_info->min_rx_bufsize = 1;
dev_info->max_rx_pktlen = BNXT_MAX_PKT_LEN;
+ dev_info->max_lro_pkt_size = BNXT_MAX_PKT_LEN;
dev_info->rx_offload_capa = BNXT_DEV_RX_OFFLOAD_SUPPORT;
if (bp->flags & BNXT_FLAG_PTP_SUPPORTED)
diff --git a/drivers/net/hinic/hinic_pmd_ethdev.c b/drivers/net/hinic/hinic_pmd_ethdev.c
index 9f37a40..b33b2cf 100644
--- a/drivers/net/hinic/hinic_pmd_ethdev.c
+++ b/drivers/net/hinic/hinic_pmd_ethdev.c
@@ -727,6 +727,7 @@ static void hinic_get_speed_capa(struct rte_eth_dev *dev, uint32_t *speed_capa)
info->max_tx_queues = nic_dev->nic_cap.max_sqs;
info->min_rx_bufsize = HINIC_MIN_RX_BUF_SIZE;
info->max_rx_pktlen = HINIC_MAX_JUMBO_FRAME_SIZE;
+ info->max_lro_pkt_size = HINIC_MAX_JUMBO_FRAME_SIZE;
info->max_mac_addrs = HINIC_MAX_UC_MAC_ADDRS;
info->min_mtu = HINIC_MIN_MTU_SIZE;
info->max_mtu = HINIC_MAX_MTU_SIZE;
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 3c7624f..863e3b1 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3804,6 +3804,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
}
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL register */
dev_info->max_rx_pktlen = 15872; /* includes CRC, cf MAXFRS register */
+ dev_info->max_lro_pkt_size = 15872;
dev_info->max_mac_addrs = hw->mac.num_rar_entries;
dev_info->max_hash_mac_addrs = IXGBE_VMDQ_NUM_UC_MAC;
dev_info->max_vfs = pci_dev->max_vfs;
@@ -3927,6 +3928,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues;
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL reg */
dev_info->max_rx_pktlen = 9728; /* includes CRC, cf MAXFRS reg */
+ dev_info->max_lro_pkt_size = 9728;
dev_info->max_mtu = dev_info->max_rx_pktlen - IXGBE_ETH_OVERHEAD;
dev_info->max_mac_addrs = hw->mac.num_rar_entries;
dev_info->max_hash_mac_addrs = IXGBE_VMDQ_NUM_UC_MAC;
diff --git a/drivers/net/ixgbe/ixgbe_vf_representor.c b/drivers/net/ixgbe/ixgbe_vf_representor.c
index dbbef29..28dfa3a 100644
--- a/drivers/net/ixgbe/ixgbe_vf_representor.c
+++ b/drivers/net/ixgbe/ixgbe_vf_representor.c
@@ -48,6 +48,7 @@
dev_info->min_rx_bufsize = 1024;
/**< Minimum size of RX buffer. */
dev_info->max_rx_pktlen = 9728;
+ dev_info->max_lro_pkt_size = 9728;
/**< Maximum configurable length of RX pkt. */
dev_info->max_rx_queues = IXGBE_VF_MAX_RX_QUEUES;
/**< Maximum number of RX queues. */
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index f644998..fdfc99b 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -203,6 +203,9 @@ struct mlx5_hca_attr {
#define MLX5_LRO_SUPPORTED(dev) \
(((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported)
+/* Maximal size of aggregated LRO packet. */
+#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)
+
/* LRO configurations structure. */
struct mlx5_lro_config {
uint32_t supported:1; /* Whether LRO is supported. */
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index c2bed2f..1443faa 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -606,6 +606,7 @@ struct ethtool_link_settings {
/* FIXME: we should ask the device for these values. */
info->min_rx_bufsize = 32;
info->max_rx_pktlen = 65536;
+ info->max_lro_pkt_size = MLX5_MAX_LRO_SIZE;
/*
* Since we need one CQ per QP, the limit is the minimum number
* between the two values.
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index 24d0eaa..9423e7b 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -1701,7 +1701,6 @@ struct mlx5_rxq_obj *
return 0;
}
-#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)
#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \
sizeof(struct rte_vlan_hdr) * 2 + \
sizeof(struct rte_ipv6_hdr)))
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 575982f..9c960cd 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev)
dev_info->min_rx_bufsize = (uint32_t)QEDE_MIN_RX_BUFF_SIZE;
dev_info->max_rx_pktlen = (uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
+ dev_info->max_lro_pkt_size = (uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
dev_info->rx_desc_lim = qede_rx_desc_lim;
dev_info->tx_desc_lim = qede_tx_desc_lim;
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 646de99..fa33c45 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -2435,6 +2435,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)
RTE_MIN(hw->max_queue_pairs, VIRTIO_MAX_TX_QUEUES);
dev_info->min_rx_bufsize = VIRTIO_MIN_RX_BUFSIZE;
dev_info->max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN;
+ dev_info->max_lro_pkt_size = VIRTIO_MAX_RX_PKTLEN;
dev_info->max_mac_addrs = VIRTIO_MAX_MAC_ADDRS;
host_features = VTPCI_OPS(hw)->get_features(hw);
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index d1faeaa..d18e8bc 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -1161,6 +1161,7 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device *pci_dev)
dev_info->max_tx_queues = VMXNET3_MAX_TX_QUEUES;
dev_info->min_rx_bufsize = 1518 + RTE_PKTMBUF_HEADROOM;
dev_info->max_rx_pktlen = 16384; /* includes CRC, cf MAXFRS register */
+ dev_info->max_lro_pkt_size = 16384;
dev_info->speed_capa = ETH_LINK_SPEED_10G;
dev_info->max_mac_addrs = VMXNET3_MAX_MAC_ADDRS;
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 85ab5f0..9cdb4a1 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -1156,6 +1156,26 @@ struct rte_eth_dev *
return name;
}
+static inline int
+check_lro_pkt_size(uint16_t port_id, uint32_t config_size,
+ uint32_t dev_info_size)
+{
+ int ret = 0;
+
+ if (config_size > dev_info_size) {
+ RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d max_lro_pkt_size %u "
+ "> max allowed value %u\n", port_id, config_size,
+ dev_info_size);
+ ret = -EINVAL;
+ } else if (config_size < RTE_ETHER_MIN_LEN) {
+ RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d max_lro_pkt_size %u "
+ "< min allowed value %u\n", port_id, config_size,
+ (unsigned int)RTE_ETHER_MIN_LEN);
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
int
rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
const struct rte_eth_conf *dev_conf)
@@ -1286,6 +1306,18 @@ struct rte_eth_dev *
RTE_ETHER_MAX_LEN;
}
+ /*
+ * If LRO is enabled, check that the maximum aggregated packet
+ * size is supported by the configured device.
+ */
+ if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
+ ret = check_lro_pkt_size(
+ port_id, dev_conf->rxmode.max_lro_pkt_size,
+ dev_info.max_lro_pkt_size);
+ if (ret != 0)
+ goto rollback;
+ }
+
/* Any requested offloading must be within its device capabilities */
if ((dev_conf->rxmode.offloads & dev_info.rx_offload_capa) !=
dev_conf->rxmode.offloads) {
@@ -1790,6 +1822,18 @@ struct rte_eth_dev *
return -EINVAL;
}
+ /*
+ * If LRO is enabled, check that the maximum aggregated packet
+ * size is supported by the configured device.
+ */
+ if (local_conf.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
+ int ret = check_lro_pkt_size(port_id,
+ dev->data->dev_conf.rxmode.max_lro_pkt_size,
+ dev_info.max_lro_pkt_size);
+ if (ret != 0)
+ return ret;
+ }
+
ret = (*dev->dev_ops->rx_queue_setup)(dev, rx_queue_id, nb_rx_desc,
socket_id, &local_conf, mp);
if (!ret) {
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index f0df03d..f3ef253 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -395,6 +395,8 @@ struct rte_eth_rxmode {
/** The multi-queue packet distribution mode to be used, e.g. RSS. */
enum rte_eth_rx_mq_mode mq_mode;
uint32_t max_rx_pkt_len; /**< Only used if JUMBO_FRAME enabled. */
+ /** Maximum allowed size of LRO aggregated packet. */
+ uint32_t max_lro_pkt_size;
uint16_t split_hdr_size; /**< hdr buf size (header_split enabled).*/
/**
* Per-port Rx offloads to be set using DEV_RX_OFFLOAD_* flags.
@@ -1223,6 +1225,8 @@ struct rte_eth_dev_info {
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
+ /** Maximum configurable size of LRO aggregated packet. */
+ uint32_t max_lro_pkt_size;
uint16_t max_rx_queues; /**< Maximum number of RX queues. */
uint16_t max_tx_queues; /**< Maximum number of TX queues. */
uint32_t max_mac_addrs; /**< Maximum number of MAC addresses. */
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 2/3] ipsec: remove redundant replay_win_sz
2019-11-06 13:40 0% ` Akhil Goyal
@ 2019-11-06 14:27 0% ` Ananyev, Konstantin
2019-11-06 14:29 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2019-11-06 14:27 UTC (permalink / raw)
To: Akhil Goyal, Hemant Agrawal, dev
> > > The rte_security lib has introduced replay_win_sz,
> > > so it can be removed from the rte_ipsec lib.
> > >
> > > The relaved tests,app are also update to reflect
> > > the usages.
> > >
> > > Note that esn and anti-replay fileds were earlier used
> > > only for ipsec library, they were enabling the libipsec
> > > by default. With this change esn and anti-replay setting
> > > will not automatically enabled libipsec.
> > >
> > > Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > ---
> > > app/test/test_ipsec.c | 2 +-
> > > doc/guides/rel_notes/release_19_11.rst | 7 +++++--
> > > examples/ipsec-secgw/ipsec-secgw.c | 5 -----
> > > examples/ipsec-secgw/ipsec.c | 4 ++++
> > > examples/ipsec-secgw/sa.c | 2 +-
> > > lib/librte_ipsec/Makefile | 2 +-
> > > lib/librte_ipsec/meson.build | 1 +
> > > lib/librte_ipsec/rte_ipsec_sa.h | 6 ------
> > > lib/librte_ipsec/sa.c | 4 ++--
> > > 9 files changed, 15 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
> > > index 4007eff19..7dc83fee7 100644
> > > --- a/app/test/test_ipsec.c
> > > +++ b/app/test/test_ipsec.c
> > > @@ -689,11 +689,11 @@ fill_ipsec_param(uint32_t replay_win_sz, uint64_t
> > flags)
> > >
> > > prm->userdata = 1;
> > > prm->flags = flags;
> > > - prm->replay_win_sz = replay_win_sz;
> > >
> > > /* setup ipsec xform */
> > > prm->ipsec_xform = ut_params->ipsec_xform;
> > > prm->ipsec_xform.salt = (uint32_t)rte_rand();
> > > + prm->ipsec_xform.replay_win_sz = replay_win_sz;
> > >
> > > /* setup tunnel related fields */
> > > prm->tun.hdr_len = sizeof(ipv4_outer);
> > > diff --git a/doc/guides/rel_notes/release_19_11.rst
> > b/doc/guides/rel_notes/release_19_11.rst
> > > index dcae08002..0504a3443 100644
> > > --- a/doc/guides/rel_notes/release_19_11.rst
> > > +++ b/doc/guides/rel_notes/release_19_11.rst
> > > @@ -369,10 +369,13 @@ ABI Changes
> > > align the Ethernet header on receive and all known encapsulations
> > > preserve the alignment of the header.
> > >
> > > -* security: A new field ''replay_win_sz'' has been added to the structure
> > > +* security: The field ''replay_win_sz'' has been moved from ipsec library
> > > + based ''rte_ipsec_sa_prm'' structure to security library based structure
> > > ``rte_security_ipsec_xform``, which specify the Anti replay window size
> > > to enable sequence replay attack handling.
> > >
> > > +* ipsec: The field ''replay_win_sz'' has been removed from the structure
> > > + ''rte_ipsec_sa_prm'' as it has been added to the security library.
> > >
> > > Shared Library Versions
> > > -----------------------
> > > @@ -415,7 +418,7 @@ The libraries prepended with a plus sign were
> > incremented in this version.
> > > librte_gso.so.1
> > > librte_hash.so.2
> > > librte_ip_frag.so.1
> > > - librte_ipsec.so.1
> > > + + librte_ipsec.so.2
> > > librte_jobstats.so.1
> > > librte_kni.so.2
> > > librte_kvargs.so.1
> > > diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-
> > secgw/ipsec-secgw.c
> > > index b12936470..3b5aaf683 100644
> > > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > > @@ -1424,9 +1424,6 @@ print_app_sa_prm(const struct app_sa_prm *prm)
> > > printf("librte_ipsec usage: %s\n",
> > > (prm->enable == 0) ? "disabled" : "enabled");
> > >
> > > - if (prm->enable == 0)
> > > - return;
> > > -
> > > printf("replay window size: %u\n", prm->window_size);
> > > printf("ESN: %s\n", (prm->enable_esn == 0) ? "disabled" : "enabled");
> > > printf("SA flags: %#" PRIx64 "\n", prm->flags);
> > > @@ -1495,11 +1492,9 @@ parse_args(int32_t argc, char **argv)
> > > app_sa_prm.enable = 1;
> > > break;
> > > case 'w':
> > > - app_sa_prm.enable = 1;
> >
> > That actually will break lib-mode functional tests at:
> > examples/ipsec-secgw/test/
> > Due to my laziness I enabled in them library mode via '-w' option,
> > as that moment legacy mode didn't support replay window...
> > As these patches already applied, I'll send the fix in a new one in next few.
>
> No issues, I will squash your changes with the original patch as it is not applied
> On master.
Ok, thanks.
Patch at:
http://patches.dpdk.org/patch/62540/
>
> >
> > > app_sa_prm.window_size = parse_decimal(optarg);
> > > break;
> > > case 'e':
> > > - app_sa_prm.enable = 1;
> > > app_sa_prm.enable_esn = 1;
> > > break;
> > > case 'a':
> > > diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> > > index d7761e966..d4b57121a 100644
> > > --- a/examples/ipsec-secgw/ipsec.c
> > > +++ b/examples/ipsec-secgw/ipsec.c
> > > @@ -49,6 +49,8 @@ set_ipsec_conf(struct ipsec_sa *sa, struct
> > rte_security_ipsec_xform *ipsec)
> > > /* TODO support for Transport */
> > > }
> > > ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
> > > + ipsec->replay_win_sz = app_sa_prm.window_size;
> > > + ipsec->options.esn = app_sa_prm.enable_esn;
> >
> > Ok, but what to do for the devices that don't support esn or replay_win_sz?
> > Should we add some check? Either to the app, or preferably into rte_security
> > level at rte_security_session_create()?
>
> Ideally app should check the capability of the device before setting it.
Yes... after another thought - as right now we do create session at run-time,
probably we need to check these device capabilities at init stage and report an error.
Konstantin
>
>
> > > }
> > >
> > > int
> > > @@ -92,6 +94,7 @@ create_lookaside_session(struct ipsec_ctx *ipsec_ctx,
> > struct ipsec_sa *sa,
> > > .spi = sa->spi,
> > > .salt = sa->salt,
> > > .options = { 0 },
> > > + .replay_win_sz = 0,
> > > .direction = sa->direction,
> > > .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
> > > .mode = (IS_TUNNEL(sa->flags)) ?
> > > @@ -151,6 +154,7 @@ create_inline_session(struct socket_ctx *skt_ctx,
> > struct ipsec_sa *sa,
> > > .spi = sa->spi,
> > > .salt = sa->salt,
> > > .options = { 0 },
> > > + .replay_win_sz = 0,
> > > .direction = sa->direction,
> > > .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
> > > .mode = (sa->flags == IP4_TUNNEL ||
> > > diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
> > > index a8dee342e..4605a3a6c 100644
> > > --- a/examples/ipsec-secgw/sa.c
> > > +++ b/examples/ipsec-secgw/sa.c
> > > @@ -1115,7 +1115,7 @@ fill_ipsec_app_sa_prm(struct rte_ipsec_sa_prm
> > *prm,
> > >
> > > prm->flags = app_prm->flags;
> > > prm->ipsec_xform.options.esn = app_prm->enable_esn;
> > > - prm->replay_win_sz = app_prm->window_size;
> > > + prm->ipsec_xform.replay_win_sz = app_prm->window_size;
> > > }
> > >
> > > static int
> > > diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile
> > > index 81fb99980..161ea9e3d 100644
> > > --- a/lib/librte_ipsec/Makefile
> > > +++ b/lib/librte_ipsec/Makefile
> > > @@ -14,7 +14,7 @@ LDLIBS += -lrte_cryptodev -lrte_security -lrte_hash
> > >
> > > EXPORT_MAP := rte_ipsec_version.map
> > >
> > > -LIBABIVER := 1
> > > +LIBABIVER := 2
> > >
> > > # all source are stored in SRCS-y
> > > SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) += esp_inb.c
> > > diff --git a/lib/librte_ipsec/meson.build b/lib/librte_ipsec/meson.build
> > > index 70358526b..e8604dadd 100644
> > > --- a/lib/librte_ipsec/meson.build
> > > +++ b/lib/librte_ipsec/meson.build
> > > @@ -1,6 +1,7 @@
> > > # SPDX-License-Identifier: BSD-3-Clause
> > > # Copyright(c) 2018 Intel Corporation
> > >
> > > +version = 2
> > > allow_experimental_apis = true
> > >
> > > sources = files('esp_inb.c', 'esp_outb.c', 'sa.c', 'ses.c', 'ipsec_sad.c')
> > > diff --git a/lib/librte_ipsec/rte_ipsec_sa.h b/lib/librte_ipsec/rte_ipsec_sa.h
> > > index 47ce169d2..1cfde5874 100644
> > > --- a/lib/librte_ipsec/rte_ipsec_sa.h
> > > +++ b/lib/librte_ipsec/rte_ipsec_sa.h
> > > @@ -47,12 +47,6 @@ struct rte_ipsec_sa_prm {
> > > uint8_t proto; /**< next header protocol */
> > > } trs; /**< transport mode related parameters */
> > > };
> > > -
> > > - /**
> > > - * window size to enable sequence replay attack handling.
> > > - * replay checking is disabled if the window size is 0.
> > > - */
> > > - uint32_t replay_win_sz;
> > > };
> > >
> > > /**
> > > diff --git a/lib/librte_ipsec/sa.c b/lib/librte_ipsec/sa.c
> > > index 23d394b46..6f1d92c3c 100644
> > > --- a/lib/librte_ipsec/sa.c
> > > +++ b/lib/librte_ipsec/sa.c
> > > @@ -439,7 +439,7 @@ rte_ipsec_sa_size(const struct rte_ipsec_sa_prm *prm)
> > > return rc;
> > >
> > > /* determine required size */
> > > - wsz = prm->replay_win_sz;
> > > + wsz = prm->ipsec_xform.replay_win_sz;
> > > return ipsec_sa_size(type, &wsz, &nb);
> > > }
> > >
> > > @@ -461,7 +461,7 @@ rte_ipsec_sa_init(struct rte_ipsec_sa *sa, const struct
> > rte_ipsec_sa_prm *prm,
> > > return rc;
> > >
> > > /* determine required size */
> > > - wsz = prm->replay_win_sz;
> > > + wsz = prm->ipsec_xform.replay_win_sz;
> > > sz = ipsec_sa_size(type, &wsz, &nb);
> > > if (sz < 0)
> > > return sz;
> > > --
> > > 2.17.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps
2019-11-05 17:15 0% ` Burakov, Anatoly
@ 2019-11-06 13:58 3% ` David Marchand
2019-11-06 15:27 0% ` Rajesh Ravi
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-11-06 13:58 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: dev, Bruce Richardson, Rajesh Ravi, Ajit Khaparde,
Jonathan Richardson, Scott Branden, Vikram Mysore Prakash,
Srinath Mannam, Thomas Monjalon
On Tue, Nov 5, 2019 at 6:15 PM Burakov, Anatoly
<anatoly.burakov@intel.com> wrote:
>
> On 05-Nov-19 3:15 PM, Anatoly Burakov wrote:
> > Currently, externally created heaps are supposed to be automatically
> > mapped for VFIO DMA by EAL, however they only do so if, at the time of
> > heap creation, VFIO is initialized and has at least one device
> > available. If no devices are available at the time of heap creation (or
> > if devices were available, but were since hot-unplugged, thus dropping
> > all VFIO container mappings), then VFIO mapping code would have skipped
> > over externally allocated heaps.
> >
> > The fix is two-fold. First, we allow externally allocated memory
> > segments to be marked as "heap" segments. This allows us to distinguish
> > between external memory segments that were created via heap API, from
> > those that were created via rte_extmem_register() API.
> >
> > Then, we fix the VFIO code to only skip non-heap external segments.
> > Also, since external heaps are not guaranteed to have valid IOVA
> > addresses, we will skip those which have invalid IOVA addresses as well.
> >
> > Fixes: 0f526d674f8e ("malloc: separate creating memseg list and malloc heap")
> >
> > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > ---
> >
> > Notes:
> > This cannot be backported to older releases as it breaks the
> > API and ABI. A separate fix is in the works for stable.
> >
>
> Alternative, non-breaking implementation available (which will be slower
> due to O(N) memseg list heaps lookups):
>
> http://patches.dpdk.org/patch/62486/
>
> I'm fine with either option being merged.
>
> The more perfect solution would've been to rename "msl->external" into
> "msl->flags" and have various flags for memseg lists, but it's too late
> to break the API now.
Either way is fine for me (between the 18.11 and the master patches you sent).
Breaking the ABI is acceptable, but I agree the API is another story.
If the code seems better to you with the additional heap flag, let's go for it.
I would still like to hear from Rajesh though, since he seems to be
the first to hit this issue.
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 2/3] ipsec: remove redundant replay_win_sz
2019-11-06 13:31 0% ` Ananyev, Konstantin
@ 2019-11-06 13:40 0% ` Akhil Goyal
2019-11-06 14:27 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2019-11-06 13:40 UTC (permalink / raw)
To: Ananyev, Konstantin, Hemant Agrawal, dev
Hi Konstantin,
>
> Hi guys,
>
> > The rte_security lib has introduced replay_win_sz,
> > so it can be removed from the rte_ipsec lib.
> >
> > The relaved tests,app are also update to reflect
> > the usages.
> >
> > Note that esn and anti-replay fileds were earlier used
> > only for ipsec library, they were enabling the libipsec
> > by default. With this change esn and anti-replay setting
> > will not automatically enabled libipsec.
> >
> > Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > ---
> > app/test/test_ipsec.c | 2 +-
> > doc/guides/rel_notes/release_19_11.rst | 7 +++++--
> > examples/ipsec-secgw/ipsec-secgw.c | 5 -----
> > examples/ipsec-secgw/ipsec.c | 4 ++++
> > examples/ipsec-secgw/sa.c | 2 +-
> > lib/librte_ipsec/Makefile | 2 +-
> > lib/librte_ipsec/meson.build | 1 +
> > lib/librte_ipsec/rte_ipsec_sa.h | 6 ------
> > lib/librte_ipsec/sa.c | 4 ++--
> > 9 files changed, 15 insertions(+), 18 deletions(-)
> >
> > diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
> > index 4007eff19..7dc83fee7 100644
> > --- a/app/test/test_ipsec.c
> > +++ b/app/test/test_ipsec.c
> > @@ -689,11 +689,11 @@ fill_ipsec_param(uint32_t replay_win_sz, uint64_t
> flags)
> >
> > prm->userdata = 1;
> > prm->flags = flags;
> > - prm->replay_win_sz = replay_win_sz;
> >
> > /* setup ipsec xform */
> > prm->ipsec_xform = ut_params->ipsec_xform;
> > prm->ipsec_xform.salt = (uint32_t)rte_rand();
> > + prm->ipsec_xform.replay_win_sz = replay_win_sz;
> >
> > /* setup tunnel related fields */
> > prm->tun.hdr_len = sizeof(ipv4_outer);
> > diff --git a/doc/guides/rel_notes/release_19_11.rst
> b/doc/guides/rel_notes/release_19_11.rst
> > index dcae08002..0504a3443 100644
> > --- a/doc/guides/rel_notes/release_19_11.rst
> > +++ b/doc/guides/rel_notes/release_19_11.rst
> > @@ -369,10 +369,13 @@ ABI Changes
> > align the Ethernet header on receive and all known encapsulations
> > preserve the alignment of the header.
> >
> > -* security: A new field ''replay_win_sz'' has been added to the structure
> > +* security: The field ''replay_win_sz'' has been moved from ipsec library
> > + based ''rte_ipsec_sa_prm'' structure to security library based structure
> > ``rte_security_ipsec_xform``, which specify the Anti replay window size
> > to enable sequence replay attack handling.
> >
> > +* ipsec: The field ''replay_win_sz'' has been removed from the structure
> > + ''rte_ipsec_sa_prm'' as it has been added to the security library.
> >
> > Shared Library Versions
> > -----------------------
> > @@ -415,7 +418,7 @@ The libraries prepended with a plus sign were
> incremented in this version.
> > librte_gso.so.1
> > librte_hash.so.2
> > librte_ip_frag.so.1
> > - librte_ipsec.so.1
> > + + librte_ipsec.so.2
> > librte_jobstats.so.1
> > librte_kni.so.2
> > librte_kvargs.so.1
> > diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-
> secgw/ipsec-secgw.c
> > index b12936470..3b5aaf683 100644
> > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > @@ -1424,9 +1424,6 @@ print_app_sa_prm(const struct app_sa_prm *prm)
> > printf("librte_ipsec usage: %s\n",
> > (prm->enable == 0) ? "disabled" : "enabled");
> >
> > - if (prm->enable == 0)
> > - return;
> > -
> > printf("replay window size: %u\n", prm->window_size);
> > printf("ESN: %s\n", (prm->enable_esn == 0) ? "disabled" : "enabled");
> > printf("SA flags: %#" PRIx64 "\n", prm->flags);
> > @@ -1495,11 +1492,9 @@ parse_args(int32_t argc, char **argv)
> > app_sa_prm.enable = 1;
> > break;
> > case 'w':
> > - app_sa_prm.enable = 1;
>
> That actually will break lib-mode functional tests at:
> examples/ipsec-secgw/test/
> Due to my laziness I enabled in them library mode via '-w' option,
> as that moment legacy mode didn't support replay window...
> As these patches already applied, I'll send the fix in a new one in next few.
No issues, I will squash your changes with the original patch as it is not applied
On master.
>
> > app_sa_prm.window_size = parse_decimal(optarg);
> > break;
> > case 'e':
> > - app_sa_prm.enable = 1;
> > app_sa_prm.enable_esn = 1;
> > break;
> > case 'a':
> > diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> > index d7761e966..d4b57121a 100644
> > --- a/examples/ipsec-secgw/ipsec.c
> > +++ b/examples/ipsec-secgw/ipsec.c
> > @@ -49,6 +49,8 @@ set_ipsec_conf(struct ipsec_sa *sa, struct
> rte_security_ipsec_xform *ipsec)
> > /* TODO support for Transport */
> > }
> > ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
> > + ipsec->replay_win_sz = app_sa_prm.window_size;
> > + ipsec->options.esn = app_sa_prm.enable_esn;
>
> Ok, but what to do for the devices that don't support esn or replay_win_sz?
> Should we add some check? Either to the app, or preferably into rte_security
> level at rte_security_session_create()?
Ideally app should check the capability of the device before setting it.
> > }
> >
> > int
> > @@ -92,6 +94,7 @@ create_lookaside_session(struct ipsec_ctx *ipsec_ctx,
> struct ipsec_sa *sa,
> > .spi = sa->spi,
> > .salt = sa->salt,
> > .options = { 0 },
> > + .replay_win_sz = 0,
> > .direction = sa->direction,
> > .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
> > .mode = (IS_TUNNEL(sa->flags)) ?
> > @@ -151,6 +154,7 @@ create_inline_session(struct socket_ctx *skt_ctx,
> struct ipsec_sa *sa,
> > .spi = sa->spi,
> > .salt = sa->salt,
> > .options = { 0 },
> > + .replay_win_sz = 0,
> > .direction = sa->direction,
> > .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
> > .mode = (sa->flags == IP4_TUNNEL ||
> > diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
> > index a8dee342e..4605a3a6c 100644
> > --- a/examples/ipsec-secgw/sa.c
> > +++ b/examples/ipsec-secgw/sa.c
> > @@ -1115,7 +1115,7 @@ fill_ipsec_app_sa_prm(struct rte_ipsec_sa_prm
> *prm,
> >
> > prm->flags = app_prm->flags;
> > prm->ipsec_xform.options.esn = app_prm->enable_esn;
> > - prm->replay_win_sz = app_prm->window_size;
> > + prm->ipsec_xform.replay_win_sz = app_prm->window_size;
> > }
> >
> > static int
> > diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile
> > index 81fb99980..161ea9e3d 100644
> > --- a/lib/librte_ipsec/Makefile
> > +++ b/lib/librte_ipsec/Makefile
> > @@ -14,7 +14,7 @@ LDLIBS += -lrte_cryptodev -lrte_security -lrte_hash
> >
> > EXPORT_MAP := rte_ipsec_version.map
> >
> > -LIBABIVER := 1
> > +LIBABIVER := 2
> >
> > # all source are stored in SRCS-y
> > SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) += esp_inb.c
> > diff --git a/lib/librte_ipsec/meson.build b/lib/librte_ipsec/meson.build
> > index 70358526b..e8604dadd 100644
> > --- a/lib/librte_ipsec/meson.build
> > +++ b/lib/librte_ipsec/meson.build
> > @@ -1,6 +1,7 @@
> > # SPDX-License-Identifier: BSD-3-Clause
> > # Copyright(c) 2018 Intel Corporation
> >
> > +version = 2
> > allow_experimental_apis = true
> >
> > sources = files('esp_inb.c', 'esp_outb.c', 'sa.c', 'ses.c', 'ipsec_sad.c')
> > diff --git a/lib/librte_ipsec/rte_ipsec_sa.h b/lib/librte_ipsec/rte_ipsec_sa.h
> > index 47ce169d2..1cfde5874 100644
> > --- a/lib/librte_ipsec/rte_ipsec_sa.h
> > +++ b/lib/librte_ipsec/rte_ipsec_sa.h
> > @@ -47,12 +47,6 @@ struct rte_ipsec_sa_prm {
> > uint8_t proto; /**< next header protocol */
> > } trs; /**< transport mode related parameters */
> > };
> > -
> > - /**
> > - * window size to enable sequence replay attack handling.
> > - * replay checking is disabled if the window size is 0.
> > - */
> > - uint32_t replay_win_sz;
> > };
> >
> > /**
> > diff --git a/lib/librte_ipsec/sa.c b/lib/librte_ipsec/sa.c
> > index 23d394b46..6f1d92c3c 100644
> > --- a/lib/librte_ipsec/sa.c
> > +++ b/lib/librte_ipsec/sa.c
> > @@ -439,7 +439,7 @@ rte_ipsec_sa_size(const struct rte_ipsec_sa_prm *prm)
> > return rc;
> >
> > /* determine required size */
> > - wsz = prm->replay_win_sz;
> > + wsz = prm->ipsec_xform.replay_win_sz;
> > return ipsec_sa_size(type, &wsz, &nb);
> > }
> >
> > @@ -461,7 +461,7 @@ rte_ipsec_sa_init(struct rte_ipsec_sa *sa, const struct
> rte_ipsec_sa_prm *prm,
> > return rc;
> >
> > /* determine required size */
> > - wsz = prm->replay_win_sz;
> > + wsz = prm->ipsec_xform.replay_win_sz;
> > sz = ipsec_sa_size(type, &wsz, &nb);
> > if (sz < 0)
> > return sz;
> > --
> > 2.17.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 2/3] ipsec: remove redundant replay_win_sz
2019-11-06 6:54 4% ` [dpdk-dev] [PATCH v6 2/3] ipsec: remove redundant replay_win_sz Hemant Agrawal
2019-11-06 7:00 0% ` Akhil Goyal
@ 2019-11-06 13:31 0% ` Ananyev, Konstantin
2019-11-06 13:40 0% ` Akhil Goyal
1 sibling, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2019-11-06 13:31 UTC (permalink / raw)
To: Hemant Agrawal, dev; +Cc: akhil.goyal
Hi guys,
> The rte_security lib has introduced replay_win_sz,
> so it can be removed from the rte_ipsec lib.
>
> The relaved tests,app are also update to reflect
> the usages.
>
> Note that esn and anti-replay fileds were earlier used
> only for ipsec library, they were enabling the libipsec
> by default. With this change esn and anti-replay setting
> will not automatically enabled libipsec.
>
> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> app/test/test_ipsec.c | 2 +-
> doc/guides/rel_notes/release_19_11.rst | 7 +++++--
> examples/ipsec-secgw/ipsec-secgw.c | 5 -----
> examples/ipsec-secgw/ipsec.c | 4 ++++
> examples/ipsec-secgw/sa.c | 2 +-
> lib/librte_ipsec/Makefile | 2 +-
> lib/librte_ipsec/meson.build | 1 +
> lib/librte_ipsec/rte_ipsec_sa.h | 6 ------
> lib/librte_ipsec/sa.c | 4 ++--
> 9 files changed, 15 insertions(+), 18 deletions(-)
>
> diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
> index 4007eff19..7dc83fee7 100644
> --- a/app/test/test_ipsec.c
> +++ b/app/test/test_ipsec.c
> @@ -689,11 +689,11 @@ fill_ipsec_param(uint32_t replay_win_sz, uint64_t flags)
>
> prm->userdata = 1;
> prm->flags = flags;
> - prm->replay_win_sz = replay_win_sz;
>
> /* setup ipsec xform */
> prm->ipsec_xform = ut_params->ipsec_xform;
> prm->ipsec_xform.salt = (uint32_t)rte_rand();
> + prm->ipsec_xform.replay_win_sz = replay_win_sz;
>
> /* setup tunnel related fields */
> prm->tun.hdr_len = sizeof(ipv4_outer);
> diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
> index dcae08002..0504a3443 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -369,10 +369,13 @@ ABI Changes
> align the Ethernet header on receive and all known encapsulations
> preserve the alignment of the header.
>
> -* security: A new field ''replay_win_sz'' has been added to the structure
> +* security: The field ''replay_win_sz'' has been moved from ipsec library
> + based ''rte_ipsec_sa_prm'' structure to security library based structure
> ``rte_security_ipsec_xform``, which specify the Anti replay window size
> to enable sequence replay attack handling.
>
> +* ipsec: The field ''replay_win_sz'' has been removed from the structure
> + ''rte_ipsec_sa_prm'' as it has been added to the security library.
>
> Shared Library Versions
> -----------------------
> @@ -415,7 +418,7 @@ The libraries prepended with a plus sign were incremented in this version.
> librte_gso.so.1
> librte_hash.so.2
> librte_ip_frag.so.1
> - librte_ipsec.so.1
> + + librte_ipsec.so.2
> librte_jobstats.so.1
> librte_kni.so.2
> librte_kvargs.so.1
> diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
> index b12936470..3b5aaf683 100644
> --- a/examples/ipsec-secgw/ipsec-secgw.c
> +++ b/examples/ipsec-secgw/ipsec-secgw.c
> @@ -1424,9 +1424,6 @@ print_app_sa_prm(const struct app_sa_prm *prm)
> printf("librte_ipsec usage: %s\n",
> (prm->enable == 0) ? "disabled" : "enabled");
>
> - if (prm->enable == 0)
> - return;
> -
> printf("replay window size: %u\n", prm->window_size);
> printf("ESN: %s\n", (prm->enable_esn == 0) ? "disabled" : "enabled");
> printf("SA flags: %#" PRIx64 "\n", prm->flags);
> @@ -1495,11 +1492,9 @@ parse_args(int32_t argc, char **argv)
> app_sa_prm.enable = 1;
> break;
> case 'w':
> - app_sa_prm.enable = 1;
That actually will break lib-mode functional tests at:
examples/ipsec-secgw/test/
Due to my laziness I enabled in them library mode via '-w' option,
as that moment legacy mode didn't support replay window...
As these patches already applied, I'll send the fix in a new one in next few.
> app_sa_prm.window_size = parse_decimal(optarg);
> break;
> case 'e':
> - app_sa_prm.enable = 1;
> app_sa_prm.enable_esn = 1;
> break;
> case 'a':
> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> index d7761e966..d4b57121a 100644
> --- a/examples/ipsec-secgw/ipsec.c
> +++ b/examples/ipsec-secgw/ipsec.c
> @@ -49,6 +49,8 @@ set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
> /* TODO support for Transport */
> }
> ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
> + ipsec->replay_win_sz = app_sa_prm.window_size;
> + ipsec->options.esn = app_sa_prm.enable_esn;
Ok, but what to do for the devices that don't support esn or replay_win_sz?
Should we add some check? Either to the app, or preferably into rte_security
level at rte_security_session_create()?
> }
>
> int
> @@ -92,6 +94,7 @@ create_lookaside_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa,
> .spi = sa->spi,
> .salt = sa->salt,
> .options = { 0 },
> + .replay_win_sz = 0,
> .direction = sa->direction,
> .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
> .mode = (IS_TUNNEL(sa->flags)) ?
> @@ -151,6 +154,7 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
> .spi = sa->spi,
> .salt = sa->salt,
> .options = { 0 },
> + .replay_win_sz = 0,
> .direction = sa->direction,
> .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
> .mode = (sa->flags == IP4_TUNNEL ||
> diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
> index a8dee342e..4605a3a6c 100644
> --- a/examples/ipsec-secgw/sa.c
> +++ b/examples/ipsec-secgw/sa.c
> @@ -1115,7 +1115,7 @@ fill_ipsec_app_sa_prm(struct rte_ipsec_sa_prm *prm,
>
> prm->flags = app_prm->flags;
> prm->ipsec_xform.options.esn = app_prm->enable_esn;
> - prm->replay_win_sz = app_prm->window_size;
> + prm->ipsec_xform.replay_win_sz = app_prm->window_size;
> }
>
> static int
> diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile
> index 81fb99980..161ea9e3d 100644
> --- a/lib/librte_ipsec/Makefile
> +++ b/lib/librte_ipsec/Makefile
> @@ -14,7 +14,7 @@ LDLIBS += -lrte_cryptodev -lrte_security -lrte_hash
>
> EXPORT_MAP := rte_ipsec_version.map
>
> -LIBABIVER := 1
> +LIBABIVER := 2
>
> # all source are stored in SRCS-y
> SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) += esp_inb.c
> diff --git a/lib/librte_ipsec/meson.build b/lib/librte_ipsec/meson.build
> index 70358526b..e8604dadd 100644
> --- a/lib/librte_ipsec/meson.build
> +++ b/lib/librte_ipsec/meson.build
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2018 Intel Corporation
>
> +version = 2
> allow_experimental_apis = true
>
> sources = files('esp_inb.c', 'esp_outb.c', 'sa.c', 'ses.c', 'ipsec_sad.c')
> diff --git a/lib/librte_ipsec/rte_ipsec_sa.h b/lib/librte_ipsec/rte_ipsec_sa.h
> index 47ce169d2..1cfde5874 100644
> --- a/lib/librte_ipsec/rte_ipsec_sa.h
> +++ b/lib/librte_ipsec/rte_ipsec_sa.h
> @@ -47,12 +47,6 @@ struct rte_ipsec_sa_prm {
> uint8_t proto; /**< next header protocol */
> } trs; /**< transport mode related parameters */
> };
> -
> - /**
> - * window size to enable sequence replay attack handling.
> - * replay checking is disabled if the window size is 0.
> - */
> - uint32_t replay_win_sz;
> };
>
> /**
> diff --git a/lib/librte_ipsec/sa.c b/lib/librte_ipsec/sa.c
> index 23d394b46..6f1d92c3c 100644
> --- a/lib/librte_ipsec/sa.c
> +++ b/lib/librte_ipsec/sa.c
> @@ -439,7 +439,7 @@ rte_ipsec_sa_size(const struct rte_ipsec_sa_prm *prm)
> return rc;
>
> /* determine required size */
> - wsz = prm->replay_win_sz;
> + wsz = prm->ipsec_xform.replay_win_sz;
> return ipsec_sa_size(type, &wsz, &nb);
> }
>
> @@ -461,7 +461,7 @@ rte_ipsec_sa_init(struct rte_ipsec_sa *sa, const struct rte_ipsec_sa_prm *prm,
> return rc;
>
> /* determine required size */
> - wsz = prm->replay_win_sz;
> + wsz = prm->ipsec_xform.replay_win_sz;
> sz = ipsec_sa_size(type, &wsz, &nb);
> if (sz < 0)
> return sz;
> --
> 2.17.1
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 1/3] ethdev: support API to set max LRO packet size
@ 2019-11-06 11:34 3% ` Dekel Peled
1 sibling, 0 replies; 200+ results
From: Dekel Peled @ 2019-11-06 11:34 UTC (permalink / raw)
To: john.mcnamara, marko.kovacevic, nhorman, ajit.khaparde,
somnath.kotur, anatoly.burakov, xuanziyang2, cloud.wangxiaoyun,
zhouguoyang, wenzhuo.lu, konstantin.ananyev, matan, shahafs,
viacheslavo, rmody, shshaikh, maxime.coquelin, tiwei.bie,
zhihong.wang, yongwang, thomas, ferruh.yigit, arybchenko,
jingjing.wu, bernard.iremonger
Cc: dev
This patch implements [1], to support API for configuration and
validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11
are updated accordingly.
Various PMDs using LRO offload are updated, the new data members are
initialized to ensure they don't fail validation.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/
Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
---
doc/guides/nics/features.rst | 2 ++
doc/guides/rel_notes/deprecation.rst | 4 ---
doc/guides/rel_notes/release_19_11.rst | 8 ++++++
drivers/net/bnxt/bnxt_ethdev.c | 1 +
drivers/net/hinic/hinic_pmd_ethdev.c | 1 +
drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++
drivers/net/ixgbe/ixgbe_vf_representor.c | 1 +
drivers/net/mlx5/mlx5.h | 3 +++
drivers/net/mlx5/mlx5_ethdev.c | 1 +
drivers/net/mlx5/mlx5_rxq.c | 1 -
drivers/net/qede/qede_ethdev.c | 1 +
drivers/net/virtio/virtio_ethdev.c | 1 +
drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 +
lib/librte_ethdev/rte_ethdev.c | 44 ++++++++++++++++++++++++++++++++
lib/librte_ethdev/rte_ethdev.h | 4 +++
15 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index d966968..4d1bb5a 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -193,10 +193,12 @@ LRO
Supports Large Receive Offload.
* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_TCP_LRO``.
+ ``dev_conf.rxmode.max_lro_pkt_size``.
* **[implements] datapath**: ``LRO functionality``.
* **[implements] rte_eth_dev_data**: ``lro``.
* **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``.
* **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``.
+* **[provides] rte_eth_dev_info**: ``max_lro_pkt_size``.
.. _nic_features_tso:
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index c10dc30..fdec33d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -87,10 +87,6 @@ Deprecation Notices
This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and
thereby improve Rx performance if application wishes do so.
-* ethdev: New 32-bit fields may be added for maximum LRO session size, in
- struct ``rte_eth_dev_info`` for the port capability and in struct
- ``rte_eth_rxmode`` for the port configuration.
-
* cryptodev: support for using IV with all sizes is added, J0 still can
be used but only when IV length in following structs ``rte_crypto_auth_xform``,
``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index f96ac38..9bffb16 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -380,6 +380,14 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
+* ethdev: Added 32-bit fields for maximum LRO aggregated packet size, in
+ struct ``rte_eth_dev_info`` for the port capability and in struct
+ ``rte_eth_rxmode`` for the port configuration.
+ Application should use the new field in struct ``rte_eth_rxmode`` to configure
+ the requested size.
+ PMD should use the new field in struct ``rte_eth_dev_info`` to report the
+ supported port capability.
+
Shared Library Versions
-----------------------
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 7d9459f..88af61b 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -535,6 +535,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,
/* Fast path specifics */
dev_info->min_rx_bufsize = 1;
dev_info->max_rx_pktlen = BNXT_MAX_PKT_LEN;
+ dev_info->max_lro_pkt_size = BNXT_MAX_PKT_LEN;
dev_info->rx_offload_capa = BNXT_DEV_RX_OFFLOAD_SUPPORT;
if (bp->flags & BNXT_FLAG_PTP_SUPPORTED)
diff --git a/drivers/net/hinic/hinic_pmd_ethdev.c b/drivers/net/hinic/hinic_pmd_ethdev.c
index 9f37a40..b33b2cf 100644
--- a/drivers/net/hinic/hinic_pmd_ethdev.c
+++ b/drivers/net/hinic/hinic_pmd_ethdev.c
@@ -727,6 +727,7 @@ static void hinic_get_speed_capa(struct rte_eth_dev *dev, uint32_t *speed_capa)
info->max_tx_queues = nic_dev->nic_cap.max_sqs;
info->min_rx_bufsize = HINIC_MIN_RX_BUF_SIZE;
info->max_rx_pktlen = HINIC_MAX_JUMBO_FRAME_SIZE;
+ info->max_lro_pkt_size = HINIC_MAX_JUMBO_FRAME_SIZE;
info->max_mac_addrs = HINIC_MAX_UC_MAC_ADDRS;
info->min_mtu = HINIC_MIN_MTU_SIZE;
info->max_mtu = HINIC_MAX_MTU_SIZE;
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 3c7624f..863e3b1 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3804,6 +3804,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
}
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL register */
dev_info->max_rx_pktlen = 15872; /* includes CRC, cf MAXFRS register */
+ dev_info->max_lro_pkt_size = 15872;
dev_info->max_mac_addrs = hw->mac.num_rar_entries;
dev_info->max_hash_mac_addrs = IXGBE_VMDQ_NUM_UC_MAC;
dev_info->max_vfs = pci_dev->max_vfs;
@@ -3927,6 +3928,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues;
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL reg */
dev_info->max_rx_pktlen = 9728; /* includes CRC, cf MAXFRS reg */
+ dev_info->max_lro_pkt_size = 9728;
dev_info->max_mtu = dev_info->max_rx_pktlen - IXGBE_ETH_OVERHEAD;
dev_info->max_mac_addrs = hw->mac.num_rar_entries;
dev_info->max_hash_mac_addrs = IXGBE_VMDQ_NUM_UC_MAC;
diff --git a/drivers/net/ixgbe/ixgbe_vf_representor.c b/drivers/net/ixgbe/ixgbe_vf_representor.c
index dbbef29..28dfa3a 100644
--- a/drivers/net/ixgbe/ixgbe_vf_representor.c
+++ b/drivers/net/ixgbe/ixgbe_vf_representor.c
@@ -48,6 +48,7 @@
dev_info->min_rx_bufsize = 1024;
/**< Minimum size of RX buffer. */
dev_info->max_rx_pktlen = 9728;
+ dev_info->max_lro_pkt_size = 9728;
/**< Maximum configurable length of RX pkt. */
dev_info->max_rx_queues = IXGBE_VF_MAX_RX_QUEUES;
/**< Maximum number of RX queues. */
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index f644998..fdfc99b 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -203,6 +203,9 @@ struct mlx5_hca_attr {
#define MLX5_LRO_SUPPORTED(dev) \
(((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported)
+/* Maximal size of aggregated LRO packet. */
+#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)
+
/* LRO configurations structure. */
struct mlx5_lro_config {
uint32_t supported:1; /* Whether LRO is supported. */
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index c2bed2f..1443faa 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -606,6 +606,7 @@ struct ethtool_link_settings {
/* FIXME: we should ask the device for these values. */
info->min_rx_bufsize = 32;
info->max_rx_pktlen = 65536;
+ info->max_lro_pkt_size = MLX5_MAX_LRO_SIZE;
/*
* Since we need one CQ per QP, the limit is the minimum number
* between the two values.
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index 24d0eaa..9423e7b 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -1701,7 +1701,6 @@ struct mlx5_rxq_obj *
return 0;
}
-#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)
#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \
sizeof(struct rte_vlan_hdr) * 2 + \
sizeof(struct rte_ipv6_hdr)))
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 575982f..9c960cd 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev)
dev_info->min_rx_bufsize = (uint32_t)QEDE_MIN_RX_BUFF_SIZE;
dev_info->max_rx_pktlen = (uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
+ dev_info->max_lro_pkt_size = (uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
dev_info->rx_desc_lim = qede_rx_desc_lim;
dev_info->tx_desc_lim = qede_tx_desc_lim;
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 646de99..fa33c45 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -2435,6 +2435,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)
RTE_MIN(hw->max_queue_pairs, VIRTIO_MAX_TX_QUEUES);
dev_info->min_rx_bufsize = VIRTIO_MIN_RX_BUFSIZE;
dev_info->max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN;
+ dev_info->max_lro_pkt_size = VIRTIO_MAX_RX_PKTLEN;
dev_info->max_mac_addrs = VIRTIO_MAX_MAC_ADDRS;
host_features = VTPCI_OPS(hw)->get_features(hw);
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index d1faeaa..d18e8bc 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -1161,6 +1161,7 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device *pci_dev)
dev_info->max_tx_queues = VMXNET3_MAX_TX_QUEUES;
dev_info->min_rx_bufsize = 1518 + RTE_PKTMBUF_HEADROOM;
dev_info->max_rx_pktlen = 16384; /* includes CRC, cf MAXFRS register */
+ dev_info->max_lro_pkt_size = 16384;
dev_info->speed_capa = ETH_LINK_SPEED_10G;
dev_info->max_mac_addrs = VMXNET3_MAX_MAC_ADDRS;
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 85ab5f0..7d8d1ed 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -1156,6 +1156,26 @@ struct rte_eth_dev *
return name;
}
+static inline int
+check_lro_pkt_size(uint16_t port_id, uint32_t config_size,
+ uint32_t dev_info_size)
+{
+ int ret = 0;
+
+ if (config_size > dev_info_size) {
+ RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d max_lro_pkt_size %u > "
+ "max allowed value %u\n",
+ port_id, config_size, dev_info_size);
+ ret = -EINVAL;
+ } else if (config_size < RTE_ETHER_MIN_LEN) {
+ RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d max_lro_pkt_size %u < "
+ "min allowed value %u\n", port_id, config_size,
+ (unsigned int)RTE_ETHER_MIN_LEN);
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
int
rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
const struct rte_eth_conf *dev_conf)
@@ -1286,6 +1306,18 @@ struct rte_eth_dev *
RTE_ETHER_MAX_LEN;
}
+ /*
+ * If LRO is enabled, check that the maximum aggregated packet
+ * size is supported by the configured device.
+ */
+ if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
+ ret = check_lro_pkt_size(
+ port_id, dev_conf->rxmode.max_lro_pkt_size,
+ dev_info.max_lro_pkt_size);
+ if (ret != 0)
+ goto rollback;
+ }
+
/* Any requested offloading must be within its device capabilities */
if ((dev_conf->rxmode.offloads & dev_info.rx_offload_capa) !=
dev_conf->rxmode.offloads) {
@@ -1790,6 +1822,18 @@ struct rte_eth_dev *
return -EINVAL;
}
+ /*
+ * If LRO is enabled, check that the maximum aggregated packet
+ * size is supported by the configured device.
+ */
+ if (local_conf.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
+ int ret = check_lro_pkt_size(port_id,
+ dev->data->dev_conf.rxmode.max_lro_pkt_size,
+ dev_info.max_lro_pkt_size);
+ if (ret != 0)
+ return ret;
+ }
+
ret = (*dev->dev_ops->rx_queue_setup)(dev, rx_queue_id, nb_rx_desc,
socket_id, &local_conf, mp);
if (!ret) {
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index f0df03d..0a1e490 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -395,6 +395,8 @@ struct rte_eth_rxmode {
/** The multi-queue packet distribution mode to be used, e.g. RSS. */
enum rte_eth_rx_mq_mode mq_mode;
uint32_t max_rx_pkt_len; /**< Only used if JUMBO_FRAME enabled. */
+ /** Maximal allowed size of LRO aggregated packet. */
+ uint32_t max_lro_pkt_size;
uint16_t split_hdr_size; /**< hdr buf size (header_split enabled).*/
/**
* Per-port Rx offloads to be set using DEV_RX_OFFLOAD_* flags.
@@ -1223,6 +1225,8 @@ struct rte_eth_dev_info {
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
+ /** Maximum configurable size of LRO aggregated packet. */
+ uint32_t max_lro_pkt_size;
uint16_t max_rx_queues; /**< Maximum number of RX queues. */
uint16_t max_tx_queues; /**< Maximum number of TX queues. */
uint32_t max_mac_addrs; /**< Maximum number of MAC addresses. */
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 1/1] fbarray: fix duplicated fbarray file in secondary
2019-11-05 11:41 0% ` Ananyev, Konstantin
@ 2019-11-06 10:37 0% ` Burakov, Anatoly
2019-11-08 3:19 3% ` Yasufumi Ogawa
0 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-11-06 10:37 UTC (permalink / raw)
To: Ananyev, Konstantin, David Marchand, Yasufumi Ogawa
Cc: dev, dpdk stable, Yasufumi Ogawa
On 05-Nov-19 11:41 AM, Ananyev, Konstantin wrote:
>
>
>> -----Original Message-----
>> From: Burakov, Anatoly <anatoly.burakov@intel.com>
>> Sent: Tuesday, November 5, 2019 11:31 AM
>> To: David Marchand <david.marchand@redhat.com>; Yasufumi Ogawa <yasufum.o@gmail.com>
>> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev <dev@dpdk.org>; dpdk stable <stable@dpdk.org>; Yasufumi Ogawa
>> <ogawa.yasufumi@lab.ntt.co.jp>
>> Subject: Re: [PATCH v6 1/1] fbarray: fix duplicated fbarray file in secondary
>>
>> On 05-Nov-19 10:13 AM, David Marchand wrote:
>>> Hello Anatoly, Yasufumi,
>>>
>>> On Mon, Nov 4, 2019 at 11:20 AM Burakov, Anatoly
>>> <anatoly.burakov@intel.com> wrote:
>>>>
>>>> On 01-Nov-19 9:04 AM, yasufum.o@gmail.com wrote:
>>>>> From: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp>
>>>>>
>>>>> In secondary_msl_create_walk(), it creates a file for fbarrays with its
>>>>> PID for reserving unique name among secondary processes. However, it
>>>>> does not work if several secondaries run as app containers because each
>>>>> of containerized secondary has PID 1, and failed to reserve unique name
>>>>> other than first one. To reserve unique name in each of containers, use
>>>>> hostname in addition to PID.
>>>>>
>>>>> Cc: stable@dpdk.org
>>>
>>> We can't backport this as is, see below.
>>>
>>>
>>>>>
>>>>> Signed-off-by: Yasufumi Ogawa <yasufum.o@gmail.com>
>>>>> ---
>>>>> lib/librte_eal/common/include/rte_fbarray.h | 2 +-
>>>>> lib/librte_eal/linux/eal/eal_memalloc.c | 11 ++++++++---
>>>>> 2 files changed, 9 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/lib/librte_eal/common/include/rte_fbarray.h b/lib/librte_eal/common/include/rte_fbarray.h
>>>>> index 6dccdbec9..5c2815093 100644
>>>>> --- a/lib/librte_eal/common/include/rte_fbarray.h
>>>>> +++ b/lib/librte_eal/common/include/rte_fbarray.h
>>>>> @@ -39,7 +39,7 @@ extern "C" {
>>>>> #include <rte_compat.h>
>>>>> #include <rte_rwlock.h>
>>>>>
>>>>> -#define RTE_FBARRAY_NAME_LEN 64
>>>>> +#define RTE_FBARRAY_NAME_LEN NAME_MAX
>>>
>>> The change on RTE_FBARRAY_NAME_LEN breaks the ABI, so we cannot
>>> backport this as is.
>>> For 19.11, we can allow this breakage, but we need an update of the
>>> release notes.
>>>
>>> Besides, what is the impact in terms of memory consumption?
>>>
>>>
>>>>>
>>>>> struct rte_fbarray {
>>>>> char name[RTE_FBARRAY_NAME_LEN]; /**< name associated with an array */
>>>>> diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c b/lib/librte_eal/linux/eal/eal_memalloc.c
>>>>> index af6d0d023..24f0275c9 100644
>>>>> --- a/lib/librte_eal/linux/eal/eal_memalloc.c
>>>>> +++ b/lib/librte_eal/linux/eal/eal_memalloc.c
>>>>> @@ -1365,6 +1365,7 @@ secondary_msl_create_walk(const struct rte_memseg_list *msl,
>>>>> struct rte_memseg_list *primary_msl, *local_msl;
>>>>> char name[PATH_MAX];
>>>>> int msl_idx, ret;
>>>>> + char hostname[HOST_NAME_MAX] = { 0 };
>>>>>
>>>>> if (msl->external)
>>>>> return 0;
>>>>> @@ -1373,9 +1374,13 @@ secondary_msl_create_walk(const struct rte_memseg_list *msl,
>>>>> primary_msl = &mcfg->memsegs[msl_idx];
>>>>> local_msl = &local_memsegs[msl_idx];
>>>>>
>>>>> - /* create distinct fbarrays for each secondary */
>>>>> - snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%i",
>>>>> - primary_msl->memseg_arr.name, getpid());
>>>>> + /* Create distinct fbarrays for each secondary by using PID and
>>>>> + * hostname. The reason why using hostname is because PID could be
>>>>> + * duplicated among secondaries if it is launched in a container.
>>>>> + */
>>>>> + gethostname(hostname, HOST_NAME_MAX);
>>>
>>> Personal preference, s/HOST_NAME_MAX/sizeof(hostname)/.
>>>
>>>
>>> hostname[] is HOST_NAME_MAX bytes long.
>>> In the worst case, we can get a non NULL terminated hostname string.
>>> "
>>> gethostname() returns the null-terminated hostname in the
>>> character array name, which has a length of len bytes. If the
>>> null-terminated hostname is too large to fit, then the name is
>>> truncated, and
>>> no error is returned (but see NOTES below). POSIX.1-2001 says
>>> that if such truncation occurs, then it is unspecified whether the
>>> returned buffer includes a terminating null byte.
>>> ...
>>> NOTES
>>> SUSv2 guarantees that "Host names are limited to 255 bytes".
>>> POSIX.1-2001 guarantees that "Host names (not including the
>>> terminating null byte) are limited to HOST_NAME_MAX bytes". On
>>> Linux,
>>> HOST_NAME_MAX is defined with the value 64, which has been the
>>> limit since Linux 1.0 (earlier kernels imposed a limit of 8 bytes).
>>> "
>>>
>>> How about making hostname[] HOST_NAME_MAX+1 bytes long?
>>>
>>>>> + snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%s_%d",
>>>>> + primary_msl->memseg_arr.name, hostname, (int)getpid());
>>>>>
>>>>> ret = rte_fbarray_init(&local_msl->memseg_arr, name,
>>>>> primary_msl->memseg_arr.len,
>>>>>
>>>>
>>>> I think the order should be reversed. Both containers and non-containers
>>>> can have their hostname set, and RTE_FBARRAY_NAME_LEN is of fairly
>>>> limited length, so if the hostname is long enough, the PID never gets
>>>> into the name string, resulting in duplicates. It is better have pid first.
>>>
>>> Anatoly,
>>>
>>> On the principle, it seems better, yes.
>>> Just the comment on RTE_FBARRAY_NAME_LEN indicates that you missed the
>>> change at the top of the patch.
>>> What do you think of this change?
>>>
>>
>> Yes, i did miss that, apologies.
>>
>> I don't have a strong opinion on this change, however the above comment
>> would still be true if we make fbarray size to be hostname_max + 1 - we
>> still potentially get no space for a pid. So if we're going to have pid
>> in there as well, it should be hostname_max + pid_max (5 digits?) +
>> whatever underscores we have + null terminator, to ensure it fits under
>> any and all circumstances.#
>
> I think that at least on linux we have more than enough space here:
>
> $ find /usr/include -type f | xargs grep ' NAME_MAX' | grep define
> /usr/include/linux/limits.h:#define NAME_MAX 255 /* # chars in a file name */
>
> $ find /usr/include -type f | xargs grep ' HOST_NAME_MAX' | grep define
> /usr/include/i386-linux-gnu/bits/local_lim.h:#define HOST_NAME_MAX 64
> /usr/include/x86_64-linux-gnu/bits/local_lim.h:#define HOST_NAME_MAX 64
>
Okay, works for me :)
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions
2019-11-06 9:06 10% ` Thomas Monjalon
2019-11-06 9:21 5% ` David Marchand
@ 2019-11-06 9:22 9% ` Ray Kinsella
2019-11-06 21:07 10% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Ray Kinsella @ 2019-11-06 9:22 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, stephen, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
On 06/11/2019 09:06, Thomas Monjalon wrote:
> 06/11/2019 09:49, Ray Kinsella:
>> On 06/11/2019 00:11, Thomas Monjalon wrote:
>>> 05/11/2019 16:24, Ray Kinsella:
>>>> +#. Major ABI versions are declared every **year** and are then supported for one
>>>> + year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
>>>
>>> As discussed earlier, a major ABI version can be declared less often
>>> than one year in the future.
>>> An ABI is supported more than one year, because of the LTS branches.
>>> That's why I propose to replace with this sentence:
>>> "
>>> Major ABI versions are declared regularly and are then supported for
>>> at least one year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
>>> "
>>
>> So look, this one was a decision of the technical board.
>
> The techboard didn't decide to change the ABI every year.
> We decided to review the duration after the first year, with a plan to extend.
>
>> My position is still what was agreed was, "declared every year, and supported for one year".
>> I like it, it's crystal clear what is the policy, until we change the policy.
>
> I think it gives a wrong message.
>
>> That said, I can make the change no problem, but I need some others to chime in to ok it.
>> Perhaps at the head of the Techboard today?
>
> Yes I add it to the techboard meeting.
>
>>>> +#. The ABI version is managed at a project level in DPDK, with the ABI version
>>>> + reflected in all library's soname.
>>>
>>> Yes, even the experimental libraries should have the same version,
>>> with the minor number incremented at each release.
>>> (just a comment to change a policy at the end of this patch)
>>
>> It's described elsewhere in the document, experimental libraries have a major
>> ABI version of 0, to indicate they exist outside of ABI management.
>> Minor number then changes as the experimental library changes as before.
>
> Yes, but you cannot say "reflected in all library's soname".
ACK - I will clarify
>
>>>> + In 2019, the DPDK community stated its intention to move to ABI stable
>>>> + releases, over a number of release cycles. This change begins with
>>>> + maintaining ABI stability through one year of DPDK releases starting from
>>>> + DPDK 19.11. This policy will be reviewed in 2020, with intention of
>>>> + lengthening the stability period.
>>>
>>> Great, the schedule is clear here.
>>>
>>>> +A major ABI version is declared every year, aligned with that year's LTS
>>>> +release, e.g. v19.11. This ABI version is then supported for one year by all
>>>> +subsequent releases within that time period, until the next LTS release, e.g.
>>>> +v20.11.
>>>
>>> Let's reword like this:
>>> "
>>> A new major ABI version can be declared when a new LTS branch is started,
>>> e.g. ABI 19 for DPDK 19.11.0.
>>> This major ABI version is then supported until the next one,
>>> e.g. ABI 20 for DPDK 20.11.0.
>>> All ABI changes must be detailed in the release notes.
>>> "
>>
>> This is more ambiguous, although what I said above stands.
>
> What you said is wrong because of 2 reasons:
> - it is not always one year for an major ABI
Well that is a point of disagreement.
> - it is always longer because of LTS branch
Well I was pretty careful to qualify the ABI policy applies to releases over the year.
To distinguish it from LTS branch.
>
>> If there is general agreement with changing this part of the policy, I am ok to make
>> the change.
>
> Yes let's review with the techboard.
>
>>>> + ABI breakages due to changes such as reorganizing public
>>>> + structure fields for aesthetic or readability purposes should be avoided.
>>>
>>> Why it should be avoided?
>>> If the ABI is broken anyway, I don't see any reason to not break it more.
>>
>> This is text from the original ABI Policy - I think the general sentiment still stands.
>> Just because you have an ABI Breakage window doesn't mean you should feel free to break
>> the ABI. The 3 ACKs required from Technical Board member to change the ABI, are another
>> reflection of this.
>>
>> As a general rule.
>> Unnecessary changes should still be avoided, to reduce ABI churn between ABI versions.
>
> I agree we must avoid unnecessary API changes because it requires apps to adapt.
> But if the change is only ABI, and we are in an ABI-change window,
> I don't see any issue>
>>>> +#. ABI breaking changes (including an alternative map file) can be included with
>>>> + deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option, to provide
>>>> + more details about oncoming changes. ``RTE_NEXT_ABI`` wrapper will be removed
>>>> + at the declaration of the next major ABI version.
>>>
>>> I missed that in discussions.
>>> I thought we wanted to wait for the next major ABI.
>>> If we allow NEXT_ABI ifdef, we will have 2 DPDK versions
>>> (stable and next ABI) to test.
>>
>> This is text from the original ABI Policy - the purpose remains the same.
>> If you add an ABI breaking change in say 20.02, that clearly can't see the light of day until 20.11
>>
>> You may still opt to prepare the community for the change, by putting your code out wrapped
>> in a NEXT_ABI and flagging it. You then get the option for people, so inclined, to build and try your code.
>>
>> I can't see it being used often, but it is another tool in the box of managing ABI change.
>
> OK, let's keep this tool.
>
>>>> +Libraries marked as ``experimental`` are entirely not considered part of an ABI
>>>> +version, and may change without warning at any time. Experimental libraries
>>>> +always have a major version of ``0`` to indicate they exist outside of
>>>> +ABI Versioning, with the minor version incremented with each ABI change
>>>> +to library.
>>>
>>> It means not all libraries will have the same ABI version.
>>> It is contrary of "ABI version is managed at a project level",
>>> and I don't see a real benefit of a different version number.
>>
>> There is a benefit, major version 0 is a very clear indication that
>> the library exists outside of ABI management.
>> A library isn't in the ABI, until it is in the ABI - an then it gets
>> added to the major version number.
>>
>>> Anyway, some experimental functions can live inside a library
>>> with a stable ABI version number
>>
>> True, but if an entire library is experimental - let's be crystal
>> clear about that.
>
> I would like to see what others think.
>
>
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions
2019-11-06 9:06 10% ` Thomas Monjalon
@ 2019-11-06 9:21 5% ` David Marchand
2019-11-06 9:22 9% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-11-06 9:21 UTC (permalink / raw)
To: Thomas Monjalon, Ray Kinsella
Cc: dev, Stephen Hemminger, Bruce Richardson, Yigit, Ferruh, Ananyev,
Konstantin, Jerin Jacob Kollanukkaran, Olivier Matz, Neil Horman,
Maxime Coquelin, Mcnamara, John, Kovacevic, Marko,
Hemant Agrawal, Kevin Traynor, Aaron Conole
On Wed, Nov 6, 2019 at 10:06 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> > >> +Libraries marked as ``experimental`` are entirely not considered part of an ABI
> > >> +version, and may change without warning at any time. Experimental libraries
> > >> +always have a major version of ``0`` to indicate they exist outside of
> > >> +ABI Versioning, with the minor version incremented with each ABI change
> > >> +to library.
> > >
> > > It means not all libraries will have the same ABI version.
> > > It is contrary of "ABI version is managed at a project level",
> > > and I don't see a real benefit of a different version number.
> >
> > There is a benefit, major version 0 is a very clear indication that
> > the library exists outside of ABI management.
> > A library isn't in the ABI, until it is in the ABI - an then it gets
> > added to the major version number.
The user must already set ALLOW_EXPERIMENTAL_API when using api from
such a library.
This is visible to him when developping.
On the contrary a 0 ABIVER is an (almost) internal thing.
> >
> > > Anyway, some experimental functions can live inside a library
> > > with a stable ABI version number
> >
> > True, but if an entire library is experimental - let's be crystal
> > clear about that.
Having this special case means that the library soname will contain a .0.
Won't it prevent us from having two versions of dpdk installed?
--
David Marchand
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions
2019-11-06 8:49 11% ` Ray Kinsella
@ 2019-11-06 9:06 10% ` Thomas Monjalon
2019-11-06 9:21 5% ` David Marchand
2019-11-06 9:22 9% ` Ray Kinsella
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-11-06 9:06 UTC (permalink / raw)
To: Ray Kinsella
Cc: dev, stephen, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
06/11/2019 09:49, Ray Kinsella:
> On 06/11/2019 00:11, Thomas Monjalon wrote:
> > 05/11/2019 16:24, Ray Kinsella:
> >> +#. Major ABI versions are declared every **year** and are then supported for one
> >> + year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
> >
> > As discussed earlier, a major ABI version can be declared less often
> > than one year in the future.
> > An ABI is supported more than one year, because of the LTS branches.
> > That's why I propose to replace with this sentence:
> > "
> > Major ABI versions are declared regularly and are then supported for
> > at least one year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
> > "
>
> So look, this one was a decision of the technical board.
The techboard didn't decide to change the ABI every year.
We decided to review the duration after the first year, with a plan to extend.
> My position is still what was agreed was, "declared every year, and supported for one year".
> I like it, it's crystal clear what is the policy, until we change the policy.
I think it gives a wrong message.
> That said, I can make the change no problem, but I need some others to chime in to ok it.
> Perhaps at the head of the Techboard today?
Yes I add it to the techboard meeting.
> >> +#. The ABI version is managed at a project level in DPDK, with the ABI version
> >> + reflected in all library's soname.
> >
> > Yes, even the experimental libraries should have the same version,
> > with the minor number incremented at each release.
> > (just a comment to change a policy at the end of this patch)
>
> It's described elsewhere in the document, experimental libraries have a major
> ABI version of 0, to indicate they exist outside of ABI management.
> Minor number then changes as the experimental library changes as before.
Yes, but you cannot say "reflected in all library's soname".
> >> + In 2019, the DPDK community stated its intention to move to ABI stable
> >> + releases, over a number of release cycles. This change begins with
> >> + maintaining ABI stability through one year of DPDK releases starting from
> >> + DPDK 19.11. This policy will be reviewed in 2020, with intention of
> >> + lengthening the stability period.
> >
> > Great, the schedule is clear here.
> >
> >> +A major ABI version is declared every year, aligned with that year's LTS
> >> +release, e.g. v19.11. This ABI version is then supported for one year by all
> >> +subsequent releases within that time period, until the next LTS release, e.g.
> >> +v20.11.
> >
> > Let's reword like this:
> > "
> > A new major ABI version can be declared when a new LTS branch is started,
> > e.g. ABI 19 for DPDK 19.11.0.
> > This major ABI version is then supported until the next one,
> > e.g. ABI 20 for DPDK 20.11.0.
> > All ABI changes must be detailed in the release notes.
> > "
>
> This is more ambiguous, although what I said above stands.
What you said is wrong because of 2 reasons:
- it is not always one year for an major ABI
- it is always longer because of LTS branch
> If there is general agreement with changing this part of the policy, I am ok to make
> the change.
Yes let's review with the techboard.
> >> + ABI breakages due to changes such as reorganizing public
> >> + structure fields for aesthetic or readability purposes should be avoided.
> >
> > Why it should be avoided?
> > If the ABI is broken anyway, I don't see any reason to not break it more.
>
> This is text from the original ABI Policy - I think the general sentiment still stands.
> Just because you have an ABI Breakage window doesn't mean you should feel free to break
> the ABI. The 3 ACKs required from Technical Board member to change the ABI, are another
> reflection of this.
>
> As a general rule.
> Unnecessary changes should still be avoided, to reduce ABI churn between ABI versions.
I agree we must avoid unnecessary API changes because it requires apps to adapt.
But if the change is only ABI, and we are in an ABI-change window,
I don't see any issue.
> >> +#. ABI breaking changes (including an alternative map file) can be included with
> >> + deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option, to provide
> >> + more details about oncoming changes. ``RTE_NEXT_ABI`` wrapper will be removed
> >> + at the declaration of the next major ABI version.
> >
> > I missed that in discussions.
> > I thought we wanted to wait for the next major ABI.
> > If we allow NEXT_ABI ifdef, we will have 2 DPDK versions
> > (stable and next ABI) to test.
>
> This is text from the original ABI Policy - the purpose remains the same.
> If you add an ABI breaking change in say 20.02, that clearly can't see the light of day until 20.11
>
> You may still opt to prepare the community for the change, by putting your code out wrapped
> in a NEXT_ABI and flagging it. You then get the option for people, so inclined, to build and try your code.
>
> I can't see it being used often, but it is another tool in the box of managing ABI change.
OK, let's keep this tool.
> >> +Libraries marked as ``experimental`` are entirely not considered part of an ABI
> >> +version, and may change without warning at any time. Experimental libraries
> >> +always have a major version of ``0`` to indicate they exist outside of
> >> +ABI Versioning, with the minor version incremented with each ABI change
> >> +to library.
> >
> > It means not all libraries will have the same ABI version.
> > It is contrary of "ABI version is managed at a project level",
> > and I don't see a real benefit of a different version number.
>
> There is a benefit, major version 0 is a very clear indication that
> the library exists outside of ABI management.
> A library isn't in the ABI, until it is in the ABI - an then it gets
> added to the major version number.
>
> > Anyway, some experimental functions can live inside a library
> > with a stable ABI version number
>
> True, but if an entire library is experimental - let's be crystal
> clear about that.
I would like to see what others think.
^ permalink raw reply [relevance 10%]
* Re: [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions
2019-11-06 0:11 11% ` Thomas Monjalon
@ 2019-11-06 8:49 11% ` Ray Kinsella
2019-11-06 9:06 10% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-11-06 8:49 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, stephen, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
On 06/11/2019 00:11, Thomas Monjalon wrote:
> I'm sorry I still have some comments.
> But on the positive side, you can see that I carefuly read this doc.
no worries.
>
> 05/11/2019 16:24, Ray Kinsella:
>> +#. Major ABI versions are declared every **year** and are then supported for one
>> + year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
>
> As discussed earlier, a major ABI version can be declared less often
> than one year in the future.
> An ABI is supported more than one year, because of the LTS branches.
> That's why I propose to replace with this sentence:
> "
> Major ABI versions are declared regularly and are then supported for
> at least one year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
> "
So look, this one was a decision of the technical board.
My position is still what was agreed was, "declared every year, and supported for one year".
I like it, it's crystal clear what is the policy, until we change the policy.
That said, I can make the change no problem, but I need some others to chime in to ok it.
Perhaps at the head of the Techboard today?
>
>> +#. The ABI version is managed at a project level in DPDK, with the ABI version
>> + reflected in all library's soname.
>
> Yes, even the experimental libraries should have the same version,
> with the minor number incremented at each release.
> (just a comment to change a policy at the end of this patch)
It's described elsewhere in the document, experimental libraries have a major
ABI version of 0, to indicate they exist outside of ABI management.
Minor number then changes as the experimental library changes as before.
>
>> + In 2019, the DPDK community stated its intention to move to ABI stable
>> + releases, over a number of release cycles. This change begins with
>> + maintaining ABI stability through one year of DPDK releases starting from
>> + DPDK 19.11. This policy will be reviewed in 2020, with intention of
>> + lengthening the stability period.
>
> Great, the schedule is clear here.
>
>> +A major ABI version is declared every year, aligned with that year's LTS
>> +release, e.g. v19.11. This ABI version is then supported for one year by all
>> +subsequent releases within that time period, until the next LTS release, e.g.
>> +v20.11.
>
> Let's reword like this:
> "
> A new major ABI version can be declared when a new LTS branch is started,
> e.g. ABI 19 for DPDK 19.11.0.
> This major ABI version is then supported until the next one,
> e.g. ABI 20 for DPDK 20.11.0.
> All ABI changes must be detailed in the release notes.
> "
This is more ambiguous, although what I said above stands.
If there is general agreement with changing this part of the policy, I am ok to make
the change.
>
>> +At the declaration of a major ABI version, major version numbers encoded in
>> +libraries' sonames are bumped to indicate the new version, with the minor
>> +version reset to ``0``. An example would be ``librte_eal.so.20.3`` would become
>> +``librte_eal.so.21.0``.
>>
>> +Minor versions are incremented to indicate the release of a new ABI compatible
>> +DPDK release, typically the DPDK quarterly releases. An example of this, might
>> +be that ``librte_eal.so.20.1`` would indicate the first ABI compatible DPDK
>> +release, following the declaration of the new major ABI version ``20``.
>>
>> +An ABI version is supported in all new releases until the next major ABI version
>> +is declared.
>
> This sentence is repetitive.
ACK
>> When changing the major ABI version, the release notes will detail
>> +all ABI changes.
>
> I suggest to move and reword this sentence above (as in my above reword).
ACK
>
>> + ABI breakages due to changes such as reorganizing public
>> + structure fields for aesthetic or readability purposes should be avoided.
>
> Why it should be avoided?
> If the ABI is broken anyway, I don't see any reason to not break it more.
This is text from the original ABI Policy - I think the general sentiment still stands.
Just because you have an ABI Breakage window doesn't mean you should feel free to break
the ABI. The 3 ACKs required from Technical Board member to change the ABI, are another
reflection of this.
As a general rule.
Unnecessary changes should still be avoided, to reduce ABI churn between ABI versions.
>> +#. ABI breaking changes (including an alternative map file) can be included with
>> + deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option, to provide
>> + more details about oncoming changes. ``RTE_NEXT_ABI`` wrapper will be removed
>> + at the declaration of the next major ABI version.
>
> I missed that in discussions.
> I thought we wanted to wait for the next major ABI.
> If we allow NEXT_ABI ifdef, we will have 2 DPDK versions
> (stable and next ABI) to test.
This is text from the original ABI Policy - the purpose remains the same.
If you add an ABI breaking change in say 20.02, that clearly can't see the light of day until 20.11
You may still opt to prepare the community for the change, by putting your code out wrapped
in a NEXT_ABI and flagging it. You then get the option for people, so inclined, to build and try your code.
I can't see it being used often, but it is another tool in the box of managing ABI change.
>
>> +Libraries marked as ``experimental`` are entirely not considered part of an ABI
>> +version, and may change without warning at any time. Experimental libraries
>> +always have a major version of ``0`` to indicate they exist outside of
>> +ABI Versioning, with the minor version incremented with each ABI change
>> +to library.
>
> It means not all libraries will have the same ABI version.
> It is contrary of "ABI version is managed at a project level",
> and I don't see a real benefit of a different version number.
There is a benefit, major version 0 is a very clear indication that
the library exists outside of ABI management.
A library isn't in the ABI, until it is in the ABI - an then it gets
added to the major version number.
> Anyway, some experimental functions can live inside a library
> with a stable ABI version number
True, but if an entire library is experimental - let's be crystal
clear about that.
^ permalink raw reply [relevance 11%]
* Re: [dpdk-dev] [PATCH v6 2/3] ipsec: remove redundant replay_win_sz
2019-11-06 6:54 4% ` [dpdk-dev] [PATCH v6 2/3] ipsec: remove redundant replay_win_sz Hemant Agrawal
@ 2019-11-06 7:00 0% ` Akhil Goyal
2019-11-06 13:31 0% ` Ananyev, Konstantin
1 sibling, 0 replies; 200+ results
From: Akhil Goyal @ 2019-11-06 7:00 UTC (permalink / raw)
To: Hemant Agrawal, dev, konstantin.ananyev; +Cc: anoobj
Hi Konstantin,
I had requested some changes in v5 which are there in this patch.
Could you please review this again? I plan to merge it today.
Thanks,
Akhil
> The rte_security lib has introduced replay_win_sz,
> so it can be removed from the rte_ipsec lib.
>
> The relaved tests,app are also update to reflect
> the usages.
>
> Note that esn and anti-replay fileds were earlier used
> only for ipsec library, they were enabling the libipsec
> by default. With this change esn and anti-replay setting
> will not automatically enabled libipsec.
>
> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> app/test/test_ipsec.c | 2 +-
> doc/guides/rel_notes/release_19_11.rst | 7 +++++--
> examples/ipsec-secgw/ipsec-secgw.c | 5 -----
> examples/ipsec-secgw/ipsec.c | 4 ++++
> examples/ipsec-secgw/sa.c | 2 +-
> lib/librte_ipsec/Makefile | 2 +-
> lib/librte_ipsec/meson.build | 1 +
> lib/librte_ipsec/rte_ipsec_sa.h | 6 ------
> lib/librte_ipsec/sa.c | 4 ++--
> 9 files changed, 15 insertions(+), 18 deletions(-)
>
> diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
> index 4007eff19..7dc83fee7 100644
> --- a/app/test/test_ipsec.c
> +++ b/app/test/test_ipsec.c
> @@ -689,11 +689,11 @@ fill_ipsec_param(uint32_t replay_win_sz, uint64_t
> flags)
>
> prm->userdata = 1;
> prm->flags = flags;
> - prm->replay_win_sz = replay_win_sz;
>
> /* setup ipsec xform */
> prm->ipsec_xform = ut_params->ipsec_xform;
> prm->ipsec_xform.salt = (uint32_t)rte_rand();
> + prm->ipsec_xform.replay_win_sz = replay_win_sz;
>
> /* setup tunnel related fields */
> prm->tun.hdr_len = sizeof(ipv4_outer);
> diff --git a/doc/guides/rel_notes/release_19_11.rst
> b/doc/guides/rel_notes/release_19_11.rst
> index dcae08002..0504a3443 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -369,10 +369,13 @@ ABI Changes
> align the Ethernet header on receive and all known encapsulations
> preserve the alignment of the header.
>
> -* security: A new field ''replay_win_sz'' has been added to the structure
> +* security: The field ''replay_win_sz'' has been moved from ipsec library
> + based ''rte_ipsec_sa_prm'' structure to security library based structure
> ``rte_security_ipsec_xform``, which specify the Anti replay window size
> to enable sequence replay attack handling.
>
> +* ipsec: The field ''replay_win_sz'' has been removed from the structure
> + ''rte_ipsec_sa_prm'' as it has been added to the security library.
>
> Shared Library Versions
> -----------------------
> @@ -415,7 +418,7 @@ The libraries prepended with a plus sign were
> incremented in this version.
> librte_gso.so.1
> librte_hash.so.2
> librte_ip_frag.so.1
> - librte_ipsec.so.1
> + + librte_ipsec.so.2
> librte_jobstats.so.1
> librte_kni.so.2
> librte_kvargs.so.1
> diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-
> secgw/ipsec-secgw.c
> index b12936470..3b5aaf683 100644
> --- a/examples/ipsec-secgw/ipsec-secgw.c
> +++ b/examples/ipsec-secgw/ipsec-secgw.c
> @@ -1424,9 +1424,6 @@ print_app_sa_prm(const struct app_sa_prm *prm)
> printf("librte_ipsec usage: %s\n",
> (prm->enable == 0) ? "disabled" : "enabled");
>
> - if (prm->enable == 0)
> - return;
> -
> printf("replay window size: %u\n", prm->window_size);
> printf("ESN: %s\n", (prm->enable_esn == 0) ? "disabled" : "enabled");
> printf("SA flags: %#" PRIx64 "\n", prm->flags);
> @@ -1495,11 +1492,9 @@ parse_args(int32_t argc, char **argv)
> app_sa_prm.enable = 1;
> break;
> case 'w':
> - app_sa_prm.enable = 1;
> app_sa_prm.window_size = parse_decimal(optarg);
> break;
> case 'e':
> - app_sa_prm.enable = 1;
> app_sa_prm.enable_esn = 1;
> break;
> case 'a':
> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> index d7761e966..d4b57121a 100644
> --- a/examples/ipsec-secgw/ipsec.c
> +++ b/examples/ipsec-secgw/ipsec.c
> @@ -49,6 +49,8 @@ set_ipsec_conf(struct ipsec_sa *sa, struct
> rte_security_ipsec_xform *ipsec)
> /* TODO support for Transport */
> }
> ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
> + ipsec->replay_win_sz = app_sa_prm.window_size;
> + ipsec->options.esn = app_sa_prm.enable_esn;
> }
>
> int
> @@ -92,6 +94,7 @@ create_lookaside_session(struct ipsec_ctx *ipsec_ctx,
> struct ipsec_sa *sa,
> .spi = sa->spi,
> .salt = sa->salt,
> .options = { 0 },
> + .replay_win_sz = 0,
> .direction = sa->direction,
> .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
> .mode = (IS_TUNNEL(sa->flags)) ?
> @@ -151,6 +154,7 @@ create_inline_session(struct socket_ctx *skt_ctx, struct
> ipsec_sa *sa,
> .spi = sa->spi,
> .salt = sa->salt,
> .options = { 0 },
> + .replay_win_sz = 0,
> .direction = sa->direction,
> .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
> .mode = (sa->flags == IP4_TUNNEL ||
> diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
> index a8dee342e..4605a3a6c 100644
> --- a/examples/ipsec-secgw/sa.c
> +++ b/examples/ipsec-secgw/sa.c
> @@ -1115,7 +1115,7 @@ fill_ipsec_app_sa_prm(struct rte_ipsec_sa_prm *prm,
>
> prm->flags = app_prm->flags;
> prm->ipsec_xform.options.esn = app_prm->enable_esn;
> - prm->replay_win_sz = app_prm->window_size;
> + prm->ipsec_xform.replay_win_sz = app_prm->window_size;
> }
>
> static int
> diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile
> index 81fb99980..161ea9e3d 100644
> --- a/lib/librte_ipsec/Makefile
> +++ b/lib/librte_ipsec/Makefile
> @@ -14,7 +14,7 @@ LDLIBS += -lrte_cryptodev -lrte_security -lrte_hash
>
> EXPORT_MAP := rte_ipsec_version.map
>
> -LIBABIVER := 1
> +LIBABIVER := 2
>
> # all source are stored in SRCS-y
> SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) += esp_inb.c
> diff --git a/lib/librte_ipsec/meson.build b/lib/librte_ipsec/meson.build
> index 70358526b..e8604dadd 100644
> --- a/lib/librte_ipsec/meson.build
> +++ b/lib/librte_ipsec/meson.build
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2018 Intel Corporation
>
> +version = 2
> allow_experimental_apis = true
>
> sources = files('esp_inb.c', 'esp_outb.c', 'sa.c', 'ses.c', 'ipsec_sad.c')
> diff --git a/lib/librte_ipsec/rte_ipsec_sa.h b/lib/librte_ipsec/rte_ipsec_sa.h
> index 47ce169d2..1cfde5874 100644
> --- a/lib/librte_ipsec/rte_ipsec_sa.h
> +++ b/lib/librte_ipsec/rte_ipsec_sa.h
> @@ -47,12 +47,6 @@ struct rte_ipsec_sa_prm {
> uint8_t proto; /**< next header protocol */
> } trs; /**< transport mode related parameters */
> };
> -
> - /**
> - * window size to enable sequence replay attack handling.
> - * replay checking is disabled if the window size is 0.
> - */
> - uint32_t replay_win_sz;
> };
>
> /**
> diff --git a/lib/librte_ipsec/sa.c b/lib/librte_ipsec/sa.c
> index 23d394b46..6f1d92c3c 100644
> --- a/lib/librte_ipsec/sa.c
> +++ b/lib/librte_ipsec/sa.c
> @@ -439,7 +439,7 @@ rte_ipsec_sa_size(const struct rte_ipsec_sa_prm *prm)
> return rc;
>
> /* determine required size */
> - wsz = prm->replay_win_sz;
> + wsz = prm->ipsec_xform.replay_win_sz;
> return ipsec_sa_size(type, &wsz, &nb);
> }
>
> @@ -461,7 +461,7 @@ rte_ipsec_sa_init(struct rte_ipsec_sa *sa, const struct
> rte_ipsec_sa_prm *prm,
> return rc;
>
> /* determine required size */
> - wsz = prm->replay_win_sz;
> + wsz = prm->ipsec_xform.replay_win_sz;
> sz = ipsec_sa_size(type, &wsz, &nb);
> if (sz < 0)
> return sz;
> --
> 2.17.1
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v6 2/3] ipsec: remove redundant replay_win_sz
2019-11-06 6:54 5% ` [dpdk-dev] [PATCH v6 " Hemant Agrawal
@ 2019-11-06 6:54 4% ` Hemant Agrawal
2019-11-06 7:00 0% ` Akhil Goyal
2019-11-06 13:31 0% ` Ananyev, Konstantin
0 siblings, 2 replies; 200+ results
From: Hemant Agrawal @ 2019-11-06 6:54 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal
The rte_security lib has introduced replay_win_sz,
so it can be removed from the rte_ipsec lib.
The relaved tests,app are also update to reflect
the usages.
Note that esn and anti-replay fileds were earlier used
only for ipsec library, they were enabling the libipsec
by default. With this change esn and anti-replay setting
will not automatically enabled libipsec.
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
app/test/test_ipsec.c | 2 +-
doc/guides/rel_notes/release_19_11.rst | 7 +++++--
examples/ipsec-secgw/ipsec-secgw.c | 5 -----
examples/ipsec-secgw/ipsec.c | 4 ++++
examples/ipsec-secgw/sa.c | 2 +-
lib/librte_ipsec/Makefile | 2 +-
lib/librte_ipsec/meson.build | 1 +
lib/librte_ipsec/rte_ipsec_sa.h | 6 ------
lib/librte_ipsec/sa.c | 4 ++--
9 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
index 4007eff19..7dc83fee7 100644
--- a/app/test/test_ipsec.c
+++ b/app/test/test_ipsec.c
@@ -689,11 +689,11 @@ fill_ipsec_param(uint32_t replay_win_sz, uint64_t flags)
prm->userdata = 1;
prm->flags = flags;
- prm->replay_win_sz = replay_win_sz;
/* setup ipsec xform */
prm->ipsec_xform = ut_params->ipsec_xform;
prm->ipsec_xform.salt = (uint32_t)rte_rand();
+ prm->ipsec_xform.replay_win_sz = replay_win_sz;
/* setup tunnel related fields */
prm->tun.hdr_len = sizeof(ipv4_outer);
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index dcae08002..0504a3443 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -369,10 +369,13 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
-* security: A new field ''replay_win_sz'' has been added to the structure
+* security: The field ''replay_win_sz'' has been moved from ipsec library
+ based ''rte_ipsec_sa_prm'' structure to security library based structure
``rte_security_ipsec_xform``, which specify the Anti replay window size
to enable sequence replay attack handling.
+* ipsec: The field ''replay_win_sz'' has been removed from the structure
+ ''rte_ipsec_sa_prm'' as it has been added to the security library.
Shared Library Versions
-----------------------
@@ -415,7 +418,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_gso.so.1
librte_hash.so.2
librte_ip_frag.so.1
- librte_ipsec.so.1
+ + librte_ipsec.so.2
librte_jobstats.so.1
librte_kni.so.2
librte_kvargs.so.1
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index b12936470..3b5aaf683 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -1424,9 +1424,6 @@ print_app_sa_prm(const struct app_sa_prm *prm)
printf("librte_ipsec usage: %s\n",
(prm->enable == 0) ? "disabled" : "enabled");
- if (prm->enable == 0)
- return;
-
printf("replay window size: %u\n", prm->window_size);
printf("ESN: %s\n", (prm->enable_esn == 0) ? "disabled" : "enabled");
printf("SA flags: %#" PRIx64 "\n", prm->flags);
@@ -1495,11 +1492,9 @@ parse_args(int32_t argc, char **argv)
app_sa_prm.enable = 1;
break;
case 'w':
- app_sa_prm.enable = 1;
app_sa_prm.window_size = parse_decimal(optarg);
break;
case 'e':
- app_sa_prm.enable = 1;
app_sa_prm.enable_esn = 1;
break;
case 'a':
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index d7761e966..d4b57121a 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -49,6 +49,8 @@ set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
/* TODO support for Transport */
}
ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
+ ipsec->replay_win_sz = app_sa_prm.window_size;
+ ipsec->options.esn = app_sa_prm.enable_esn;
}
int
@@ -92,6 +94,7 @@ create_lookaside_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa,
.spi = sa->spi,
.salt = sa->salt,
.options = { 0 },
+ .replay_win_sz = 0,
.direction = sa->direction,
.proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
.mode = (IS_TUNNEL(sa->flags)) ?
@@ -151,6 +154,7 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
.spi = sa->spi,
.salt = sa->salt,
.options = { 0 },
+ .replay_win_sz = 0,
.direction = sa->direction,
.proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
.mode = (sa->flags == IP4_TUNNEL ||
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index a8dee342e..4605a3a6c 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -1115,7 +1115,7 @@ fill_ipsec_app_sa_prm(struct rte_ipsec_sa_prm *prm,
prm->flags = app_prm->flags;
prm->ipsec_xform.options.esn = app_prm->enable_esn;
- prm->replay_win_sz = app_prm->window_size;
+ prm->ipsec_xform.replay_win_sz = app_prm->window_size;
}
static int
diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile
index 81fb99980..161ea9e3d 100644
--- a/lib/librte_ipsec/Makefile
+++ b/lib/librte_ipsec/Makefile
@@ -14,7 +14,7 @@ LDLIBS += -lrte_cryptodev -lrte_security -lrte_hash
EXPORT_MAP := rte_ipsec_version.map
-LIBABIVER := 1
+LIBABIVER := 2
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) += esp_inb.c
diff --git a/lib/librte_ipsec/meson.build b/lib/librte_ipsec/meson.build
index 70358526b..e8604dadd 100644
--- a/lib/librte_ipsec/meson.build
+++ b/lib/librte_ipsec/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2018 Intel Corporation
+version = 2
allow_experimental_apis = true
sources = files('esp_inb.c', 'esp_outb.c', 'sa.c', 'ses.c', 'ipsec_sad.c')
diff --git a/lib/librte_ipsec/rte_ipsec_sa.h b/lib/librte_ipsec/rte_ipsec_sa.h
index 47ce169d2..1cfde5874 100644
--- a/lib/librte_ipsec/rte_ipsec_sa.h
+++ b/lib/librte_ipsec/rte_ipsec_sa.h
@@ -47,12 +47,6 @@ struct rte_ipsec_sa_prm {
uint8_t proto; /**< next header protocol */
} trs; /**< transport mode related parameters */
};
-
- /**
- * window size to enable sequence replay attack handling.
- * replay checking is disabled if the window size is 0.
- */
- uint32_t replay_win_sz;
};
/**
diff --git a/lib/librte_ipsec/sa.c b/lib/librte_ipsec/sa.c
index 23d394b46..6f1d92c3c 100644
--- a/lib/librte_ipsec/sa.c
+++ b/lib/librte_ipsec/sa.c
@@ -439,7 +439,7 @@ rte_ipsec_sa_size(const struct rte_ipsec_sa_prm *prm)
return rc;
/* determine required size */
- wsz = prm->replay_win_sz;
+ wsz = prm->ipsec_xform.replay_win_sz;
return ipsec_sa_size(type, &wsz, &nb);
}
@@ -461,7 +461,7 @@ rte_ipsec_sa_init(struct rte_ipsec_sa *sa, const struct rte_ipsec_sa_prm *prm,
return rc;
/* determine required size */
- wsz = prm->replay_win_sz;
+ wsz = prm->ipsec_xform.replay_win_sz;
sz = ipsec_sa_size(type, &wsz, &nb);
if (sz < 0)
return sz;
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v6 1/3] security: add anti replay window size
2019-10-31 13:15 5% ` [dpdk-dev] [PATCH v5 " Hemant Agrawal
2019-10-31 13:15 5% ` [dpdk-dev] [PATCH v5 2/3] ipsec: remove redundant replay_win_sz Hemant Agrawal
2019-11-01 6:16 0% ` [dpdk-dev] [EXT] [PATCH v5 1/3] security: add anti replay window size Anoob Joseph
@ 2019-11-06 6:54 5% ` Hemant Agrawal
2019-11-06 6:54 4% ` [dpdk-dev] [PATCH v6 2/3] ipsec: remove redundant replay_win_sz Hemant Agrawal
2 siblings, 1 reply; 200+ results
From: Hemant Agrawal @ 2019-11-06 6:54 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal
At present the ipsec xfrom is missing the important step
to configure the anti replay window size.
The newly added field will also help in to enable or disable
the anti replay checking, if available in offload by means
of non-zero or zero value.
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
---
doc/guides/rel_notes/release_19_11.rst | 6 +++++-
lib/librte_security/Makefile | 2 +-
lib/librte_security/meson.build | 2 +-
lib/librte_security/rte_security.h | 8 ++++++++
4 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index 2eec0a2c1..dcae08002 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -369,6 +369,10 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
+* security: A new field ''replay_win_sz'' has been added to the structure
+ ``rte_security_ipsec_xform``, which specify the Anti replay window size
+ to enable sequence replay attack handling.
+
Shared Library Versions
-----------------------
@@ -441,7 +445,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_reorder.so.1
librte_ring.so.2
+ librte_sched.so.4
- librte_security.so.2
+ + librte_security.so.3
librte_stack.so.1
librte_table.so.3
librte_timer.so.1
diff --git a/lib/librte_security/Makefile b/lib/librte_security/Makefile
index 6708effdb..6a268ee2a 100644
--- a/lib/librte_security/Makefile
+++ b/lib/librte_security/Makefile
@@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_security.a
# library version
-LIBABIVER := 2
+LIBABIVER := 3
# build flags
CFLAGS += -O3
diff --git a/lib/librte_security/meson.build b/lib/librte_security/meson.build
index a5130d2f6..6fed01273 100644
--- a/lib/librte_security/meson.build
+++ b/lib/librte_security/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017-2019 Intel Corporation
-version = 2
+version = 3
sources = files('rte_security.c')
headers = files('rte_security.h', 'rte_security_driver.h')
deps += ['mempool', 'cryptodev']
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index aaafdfcd7..216e5370f 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -212,6 +212,10 @@ struct rte_security_ipsec_xform {
/**< Tunnel parameters, NULL for transport mode */
uint64_t esn_soft_limit;
/**< ESN for which the overflow event need to be raised */
+ uint32_t replay_win_sz;
+ /**< Anti replay window size to enable sequence replay attack handling.
+ * replay checking is disabled if the window size is 0.
+ */
};
/**
@@ -563,6 +567,10 @@ struct rte_security_capability {
/**< IPsec SA direction */
struct rte_security_ipsec_sa_options options;
/**< IPsec SA supported options */
+ uint32_t replay_win_sz_max;
+ /**< IPsec Anti Replay Window Size. A '0' value
+ * indicates that Anti Replay Window is not supported.
+ */
} ipsec;
/**< IPsec capability */
struct {
--
2.17.1
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v5 2/3] ipsec: remove redundant replay_win_sz
2019-11-05 22:01 0% ` Akhil Goyal
@ 2019-11-06 5:16 0% ` Hemant Agrawal
0 siblings, 0 replies; 200+ results
From: Hemant Agrawal @ 2019-11-06 5:16 UTC (permalink / raw)
To: Akhil Goyal, dev; +Cc: konstantin.ananyev, anoobj
> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Wednesday, November 6, 2019 3:32 AM
> To: Hemant Agrawal <hemant.agrawal@nxp.com>; dev@dpdk.org
> Cc: konstantin.ananyev@intel.com; anoobj@marvell.com; Hemant Agrawal
> <hemant.agrawal@nxp.com>
> Subject: RE: [PATCH v5 2/3] ipsec: remove redundant replay_win_sz
> Importance: High
>
> Hi Hemant,
> >
> > The rte_security lib has introduced replay_win_sz, so it can be
> > removed from the rte_ipsec lib.
> >
> > Also, the relaved tests,app are also update to reflect the usages.
> >
> > Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > ---
> > app/test/test_ipsec.c | 2 +-
> > doc/guides/rel_notes/release_19_11.rst | 7 +++++--
> > examples/ipsec-secgw/ipsec.c | 1 +
> > examples/ipsec-secgw/sa.c | 2 +-
> > lib/librte_ipsec/Makefile | 2 +-
> > lib/librte_ipsec/meson.build | 1 +
> > lib/librte_ipsec/rte_ipsec_sa.h | 6 ------
> > lib/librte_ipsec/sa.c | 4 ++--
> > 8 files changed, 12 insertions(+), 13 deletions(-)
> >
> > diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c index
> > 4007eff19..7dc83fee7 100644
> > --- a/app/test/test_ipsec.c
> > +++ b/app/test/test_ipsec.c
> > @@ -689,11 +689,11 @@ fill_ipsec_param(uint32_t replay_win_sz,
> > uint64_t
> > flags)
> >
> > prm->userdata = 1;
> > prm->flags = flags;
> > - prm->replay_win_sz = replay_win_sz;
> >
> > /* setup ipsec xform */
> > prm->ipsec_xform = ut_params->ipsec_xform;
> > prm->ipsec_xform.salt = (uint32_t)rte_rand();
> > + prm->ipsec_xform.replay_win_sz = replay_win_sz;
> >
> > /* setup tunnel related fields */
> > prm->tun.hdr_len = sizeof(ipv4_outer); diff --git
> > a/doc/guides/rel_notes/release_19_11.rst
> > b/doc/guides/rel_notes/release_19_11.rst
> > index 0508ec545..ca414edb5 100644
> > --- a/doc/guides/rel_notes/release_19_11.rst
> > +++ b/doc/guides/rel_notes/release_19_11.rst
> > @@ -365,10 +365,13 @@ ABI Changes
> > align the Ethernet header on receive and all known encapsulations
> > preserve the alignment of the header.
> >
> > -* security: A new field ''replay_win_sz'' has been added to the
> > structure
> > +* security: The field ''replay_win_sz'' has been moved from ipsec
> > +library
> > + based ''rte_ipsec_sa_prm'' structure to security library based
> > +structure
> > ``rte_security_ipsec_xform``, which specify the Anti replay window size
> > to enable sequence replay attack handling.
> >
> > +* ipsec: The field ''replay_win_sz'' has been removed from the
> > +structure
> > + ''rte_ipsec_sa_prm'' as it has been added to the security library.
> >
> > Shared Library Versions
> > -----------------------
> > @@ -411,7 +414,7 @@ The libraries prepended with a plus sign were
> > incremented in this version.
> > librte_gso.so.1
> > librte_hash.so.2
> > librte_ip_frag.so.1
> > - librte_ipsec.so.1
> > + + librte_ipsec.so.2
> > librte_jobstats.so.1
> > librte_kni.so.2
> > librte_kvargs.so.1
> > diff --git a/examples/ipsec-secgw/ipsec.c
> > b/examples/ipsec-secgw/ipsec.c index 51fb22e8a..159e81f99 100644
> > --- a/examples/ipsec-secgw/ipsec.c
> > +++ b/examples/ipsec-secgw/ipsec.c
> > @@ -49,6 +49,7 @@ set_ipsec_conf(struct ipsec_sa *sa, struct
> > rte_security_ipsec_xform *ipsec)
> > /* TODO support for Transport */
> > }
> > ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
> > + ipsec->replay_win_sz = app_sa_prm.window_size;
>
> The value of window_size is coming from command line and while parsing it,
> lib mode Is getting enabled, which means people can use anti replay only
> when lib mode is enabled which is not correct.
> Also there should be a way to disable anti replay. So when it is not given as
> command line It should not be enabled and default value should be 0.
>
[Hemant] Ok. I will look into it.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions
2019-11-05 15:24 23% ` [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-11-05 17:37 5% ` Stephen Hemminger
@ 2019-11-06 0:11 11% ` Thomas Monjalon
2019-11-06 8:49 11% ` Ray Kinsella
2019-11-06 16:12 5% ` Mcnamara, John
2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-11-06 0:11 UTC (permalink / raw)
To: Ray Kinsella
Cc: dev, stephen, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
I'm sorry I still have some comments.
But on the positive side, you can see that I carefuly read this doc.
05/11/2019 16:24, Ray Kinsella:
> +#. Major ABI versions are declared every **year** and are then supported for one
> + year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
As discussed earlier, a major ABI version can be declared less often
than one year in the future.
An ABI is supported more than one year, because of the LTS branches.
That's why I propose to replace with this sentence:
"
Major ABI versions are declared regularly and are then supported for
at least one year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
"
> +#. The ABI version is managed at a project level in DPDK, with the ABI version
> + reflected in all library's soname.
Yes, even the experimental libraries should have the same version,
with the minor number incremented at each release.
(just a comment to change a policy at the end of this patch)
> + In 2019, the DPDK community stated its intention to move to ABI stable
> + releases, over a number of release cycles. This change begins with
> + maintaining ABI stability through one year of DPDK releases starting from
> + DPDK 19.11. This policy will be reviewed in 2020, with intention of
> + lengthening the stability period.
Great, the schedule is clear here.
> +A major ABI version is declared every year, aligned with that year's LTS
> +release, e.g. v19.11. This ABI version is then supported for one year by all
> +subsequent releases within that time period, until the next LTS release, e.g.
> +v20.11.
Let's reword like this:
"
A new major ABI version can be declared when a new LTS branch is started,
e.g. ABI 19 for DPDK 19.11.0.
This major ABI version is then supported until the next one,
e.g. ABI 20 for DPDK 20.11.0.
All ABI changes must be detailed in the release notes.
"
> +At the declaration of a major ABI version, major version numbers encoded in
> +libraries' sonames are bumped to indicate the new version, with the minor
> +version reset to ``0``. An example would be ``librte_eal.so.20.3`` would become
> +``librte_eal.so.21.0``.
>
> +Minor versions are incremented to indicate the release of a new ABI compatible
> +DPDK release, typically the DPDK quarterly releases. An example of this, might
> +be that ``librte_eal.so.20.1`` would indicate the first ABI compatible DPDK
> +release, following the declaration of the new major ABI version ``20``.
>
> +An ABI version is supported in all new releases until the next major ABI version
> +is declared.
This sentence is repetitive.
> When changing the major ABI version, the release notes will detail
> +all ABI changes.
I suggest to move and reword this sentence above (as in my above reword).
> + ABI breakages due to changes such as reorganizing public
> + structure fields for aesthetic or readability purposes should be avoided.
Why it should be avoided?
If the ABI is broken anyway, I don't see any reason to not break it more.
> +#. ABI breaking changes (including an alternative map file) can be included with
> + deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option, to provide
> + more details about oncoming changes. ``RTE_NEXT_ABI`` wrapper will be removed
> + at the declaration of the next major ABI version.
I missed that in discussions.
I thought we wanted to wait for the next major ABI.
If we allow NEXT_ABI ifdef, we will have 2 DPDK versions
(stable and next ABI) to test.
> +Libraries marked as ``experimental`` are entirely not considered part of an ABI
> +version, and may change without warning at any time. Experimental libraries
> +always have a major version of ``0`` to indicate they exist outside of
> +ABI Versioning, with the minor version incremented with each ABI change
> +to library.
It means not all libraries will have the same ABI version.
It is contrary of "ABI version is managed at a project level",
and I don't see a real benefit of a different version number.
Anyway, some experimental functions can live inside a library
with a stable ABI version number.
^ permalink raw reply [relevance 11%]
* Re: [dpdk-dev] [PATCH v5 2/3] ipsec: remove redundant replay_win_sz
2019-10-31 13:15 5% ` [dpdk-dev] [PATCH v5 2/3] ipsec: remove redundant replay_win_sz Hemant Agrawal
@ 2019-11-05 22:01 0% ` Akhil Goyal
2019-11-06 5:16 0% ` Hemant Agrawal
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2019-11-05 22:01 UTC (permalink / raw)
To: Hemant Agrawal, dev; +Cc: konstantin.ananyev, anoobj, Hemant Agrawal
Hi Hemant,
>
> The rte_security lib has introduced replay_win_sz,
> so it can be removed from the rte_ipsec lib.
>
> Also, the relaved tests,app are also update to reflect
> the usages.
>
> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> app/test/test_ipsec.c | 2 +-
> doc/guides/rel_notes/release_19_11.rst | 7 +++++--
> examples/ipsec-secgw/ipsec.c | 1 +
> examples/ipsec-secgw/sa.c | 2 +-
> lib/librte_ipsec/Makefile | 2 +-
> lib/librte_ipsec/meson.build | 1 +
> lib/librte_ipsec/rte_ipsec_sa.h | 6 ------
> lib/librte_ipsec/sa.c | 4 ++--
> 8 files changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
> index 4007eff19..7dc83fee7 100644
> --- a/app/test/test_ipsec.c
> +++ b/app/test/test_ipsec.c
> @@ -689,11 +689,11 @@ fill_ipsec_param(uint32_t replay_win_sz, uint64_t
> flags)
>
> prm->userdata = 1;
> prm->flags = flags;
> - prm->replay_win_sz = replay_win_sz;
>
> /* setup ipsec xform */
> prm->ipsec_xform = ut_params->ipsec_xform;
> prm->ipsec_xform.salt = (uint32_t)rte_rand();
> + prm->ipsec_xform.replay_win_sz = replay_win_sz;
>
> /* setup tunnel related fields */
> prm->tun.hdr_len = sizeof(ipv4_outer);
> diff --git a/doc/guides/rel_notes/release_19_11.rst
> b/doc/guides/rel_notes/release_19_11.rst
> index 0508ec545..ca414edb5 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -365,10 +365,13 @@ ABI Changes
> align the Ethernet header on receive and all known encapsulations
> preserve the alignment of the header.
>
> -* security: A new field ''replay_win_sz'' has been added to the structure
> +* security: The field ''replay_win_sz'' has been moved from ipsec library
> + based ''rte_ipsec_sa_prm'' structure to security library based structure
> ``rte_security_ipsec_xform``, which specify the Anti replay window size
> to enable sequence replay attack handling.
>
> +* ipsec: The field ''replay_win_sz'' has been removed from the structure
> + ''rte_ipsec_sa_prm'' as it has been added to the security library.
>
> Shared Library Versions
> -----------------------
> @@ -411,7 +414,7 @@ The libraries prepended with a plus sign were
> incremented in this version.
> librte_gso.so.1
> librte_hash.so.2
> librte_ip_frag.so.1
> - librte_ipsec.so.1
> + + librte_ipsec.so.2
> librte_jobstats.so.1
> librte_kni.so.2
> librte_kvargs.so.1
> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> index 51fb22e8a..159e81f99 100644
> --- a/examples/ipsec-secgw/ipsec.c
> +++ b/examples/ipsec-secgw/ipsec.c
> @@ -49,6 +49,7 @@ set_ipsec_conf(struct ipsec_sa *sa, struct
> rte_security_ipsec_xform *ipsec)
> /* TODO support for Transport */
> }
> ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
> + ipsec->replay_win_sz = app_sa_prm.window_size;
The value of window_size is coming from command line and while parsing it, lib mode
Is getting enabled, which means people can use anti replay only when lib mode is enabled
which is not correct.
Also there should be a way to disable anti replay. So when it is not given as command line
It should not be enabled and default value should be 0.
> }
>
> int
> diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
> index 14ee94731..3d687c459 100644
> --- a/examples/ipsec-secgw/sa.c
> +++ b/examples/ipsec-secgw/sa.c
> @@ -1055,7 +1055,7 @@ fill_ipsec_app_sa_prm(struct rte_ipsec_sa_prm *prm,
>
> prm->flags = app_prm->flags;
> prm->ipsec_xform.options.esn = app_prm->enable_esn;
> - prm->replay_win_sz = app_prm->window_size;
> + prm->ipsec_xform.replay_win_sz = app_prm->window_size;
> }
>
> static int
> diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile
> index 81fb99980..161ea9e3d 100644
> --- a/lib/librte_ipsec/Makefile
> +++ b/lib/librte_ipsec/Makefile
> @@ -14,7 +14,7 @@ LDLIBS += -lrte_cryptodev -lrte_security -lrte_hash
>
> EXPORT_MAP := rte_ipsec_version.map
>
> -LIBABIVER := 1
> +LIBABIVER := 2
>
> # all source are stored in SRCS-y
> SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) += esp_inb.c
> diff --git a/lib/librte_ipsec/meson.build b/lib/librte_ipsec/meson.build
> index 70358526b..e8604dadd 100644
> --- a/lib/librte_ipsec/meson.build
> +++ b/lib/librte_ipsec/meson.build
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2018 Intel Corporation
>
> +version = 2
> allow_experimental_apis = true
>
> sources = files('esp_inb.c', 'esp_outb.c', 'sa.c', 'ses.c', 'ipsec_sad.c')
> diff --git a/lib/librte_ipsec/rte_ipsec_sa.h b/lib/librte_ipsec/rte_ipsec_sa.h
> index 47ce169d2..1cfde5874 100644
> --- a/lib/librte_ipsec/rte_ipsec_sa.h
> +++ b/lib/librte_ipsec/rte_ipsec_sa.h
> @@ -47,12 +47,6 @@ struct rte_ipsec_sa_prm {
> uint8_t proto; /**< next header protocol */
> } trs; /**< transport mode related parameters */
> };
> -
> - /**
> - * window size to enable sequence replay attack handling.
> - * replay checking is disabled if the window size is 0.
> - */
> - uint32_t replay_win_sz;
> };
>
> /**
> diff --git a/lib/librte_ipsec/sa.c b/lib/librte_ipsec/sa.c
> index 23d394b46..6f1d92c3c 100644
> --- a/lib/librte_ipsec/sa.c
> +++ b/lib/librte_ipsec/sa.c
> @@ -439,7 +439,7 @@ rte_ipsec_sa_size(const struct rte_ipsec_sa_prm *prm)
> return rc;
>
> /* determine required size */
> - wsz = prm->replay_win_sz;
> + wsz = prm->ipsec_xform.replay_win_sz;
> return ipsec_sa_size(type, &wsz, &nb);
> }
>
> @@ -461,7 +461,7 @@ rte_ipsec_sa_init(struct rte_ipsec_sa *sa, const struct
> rte_ipsec_sa_prm *prm,
> return rc;
>
> /* determine required size */
> - wsz = prm->replay_win_sz;
> + wsz = prm->ipsec_xform.replay_win_sz;
> sz = ipsec_sa_size(type, &wsz, &nb);
> if (sz < 0)
> return sz;
> --
> 2.17.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 3/4] doc: updates to versioning guide for abi versions
2019-11-05 15:24 35% ` [dpdk-dev] [PATCH v8 3/4] doc: updates to versioning guide for " Ray Kinsella
@ 2019-11-05 17:37 4% ` Stephen Hemminger
2019-11-06 16:13 4% ` Mcnamara, John
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-11-05 17:37 UTC (permalink / raw)
To: Ray Kinsella
Cc: dev, thomas, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
On Tue, 5 Nov 2019 15:24:17 +0000
Ray Kinsella <mdr@ashroe.eu> wrote:
> Updates to the ABI versioning guide, to account for the changes to the DPDK
> ABI/API policy. Fixes for references to abi versioning and policy guides.
>
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
> ---
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions
2019-11-05 15:24 23% ` [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
@ 2019-11-05 17:37 5% ` Stephen Hemminger
2019-11-06 0:11 11% ` Thomas Monjalon
2019-11-06 16:12 5% ` Mcnamara, John
2 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-11-05 17:37 UTC (permalink / raw)
To: Ray Kinsella
Cc: dev, thomas, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
On Tue, 5 Nov 2019 15:24:16 +0000
Ray Kinsella <mdr@ashroe.eu> wrote:
> This policy change introduces major ABI versions, these are
> declared every year, typically aligned with the LTS release
> and are supported by subsequent releases in the following year.
> This change is intended to improve ABI stabilty for those projects
> consuming DPDK.
>
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v8 1/4] doc: separate versioning.rst into version and policy
2019-11-05 15:24 18% ` [dpdk-dev] [PATCH v8 1/4] doc: separate versioning.rst into version and policy Ray Kinsella
@ 2019-11-05 17:37 0% ` Stephen Hemminger
2019-11-06 16:11 0% ` Mcnamara, John
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-11-05 17:37 UTC (permalink / raw)
To: Ray Kinsella
Cc: dev, thomas, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
On Tue, 5 Nov 2019 15:24:15 +0000
Ray Kinsella <mdr@ashroe.eu> wrote:
> Separate versioning.rst into abi versioning and abi policy guidance, in
> preparation for adding more detail to the abi policy.
>
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
> ---
> doc/guides/contributing/abi_policy.rst | 167 ++++++++
> doc/guides/contributing/abi_versioning.rst | 427 +++++++++++++++++++++
> doc/guides/contributing/index.rst | 3 +-
> doc/guides/contributing/patches.rst | 2 +-
> doc/guides/contributing/versioning.rst | 591 -----------------------------
> doc/guides/rel_notes/deprecation.rst | 2 +-
> 6 files changed, 598 insertions(+), 594 deletions(-)
> create mode 100644 doc/guides/contributing/abi_policy.rst
> create mode 100644 doc/guides/contributing/abi_versioning.rst
> delete mode 100644 doc/guides/contributing/versioning.rst
>
Acked-by: Stephen Hemminger <stephen@networkplumber.og>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps
2019-11-05 15:15 2% [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps Anatoly Burakov
@ 2019-11-05 17:15 0% ` Burakov, Anatoly
2019-11-06 13:58 3% ` David Marchand
2019-11-06 21:53 0% ` David Marchand
` (2 subsequent siblings)
3 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-11-05 17:15 UTC (permalink / raw)
To: dev
Cc: Bruce Richardson, rajesh.ravi, ajit.khaparde,
jonathan.richardson, scott.branden, vikram.prakash,
srinath.mannam, david.marchand, thomas
On 05-Nov-19 3:15 PM, Anatoly Burakov wrote:
> Currently, externally created heaps are supposed to be automatically
> mapped for VFIO DMA by EAL, however they only do so if, at the time of
> heap creation, VFIO is initialized and has at least one device
> available. If no devices are available at the time of heap creation (or
> if devices were available, but were since hot-unplugged, thus dropping
> all VFIO container mappings), then VFIO mapping code would have skipped
> over externally allocated heaps.
>
> The fix is two-fold. First, we allow externally allocated memory
> segments to be marked as "heap" segments. This allows us to distinguish
> between external memory segments that were created via heap API, from
> those that were created via rte_extmem_register() API.
>
> Then, we fix the VFIO code to only skip non-heap external segments.
> Also, since external heaps are not guaranteed to have valid IOVA
> addresses, we will skip those which have invalid IOVA addresses as well.
>
> Fixes: 0f526d674f8e ("malloc: separate creating memseg list and malloc heap")
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
>
> Notes:
> This cannot be backported to older releases as it breaks the
> API and ABI. A separate fix is in the works for stable.
>
Alternative, non-breaking implementation available (which will be slower
due to O(N) memseg list heaps lookups):
http://patches.dpdk.org/patch/62486/
I'm fine with either option being merged.
The more perfect solution would've been to rename "msl->external" into
"msl->flags" and have various flags for memseg lists, but it's too late
to break the API now.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
2019-11-05 15:12 0% ` Ferruh Yigit
@ 2019-11-05 15:54 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-11-05 15:54 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Slava Ovsiienko, Damjan Marion (damarion),
Liu, Yu Y, Wang, Haiyue, Thomas Monjalon, dev, arybchenko,
jerinjacobk, Ye, Xiaolong, Ray Kinsella, Sun, Chenmin
On Tue, 5 Nov 2019 15:12:07 +0000
Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> On 11/3/2019 7:50 AM, Slava Ovsiienko wrote:
> >
> >
> >> -----Original Message-----
> >> From: Damjan Marion (damarion) <damarion@cisco.com>
> >> Sent: Saturday, November 2, 2019 21:21
> >> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> >> Cc: Liu, Yu Y <yu.y.liu@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> >> Thomas Monjalon <thomas@monjalon.net>; dev@dpdk.org;
> >> arybchenko@solarflare.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> >> jerinjacobk@gmail.com; Ye, Xiaolong <xiaolong.ye@intel.com>; Ray Kinsella
> >> <ray.kinsella@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>
> >> Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
> >> information
> >>
> >>
> >>
> >>> On 2 Nov 2019, at 09:38, Slava Ovsiienko <viacheslavo@mellanox.com>
> >> wrote:
> >>>
> >>> Hi
> >>>> -----Original Message-----
> >>>> From: Liu, Yu Y <yu.y.liu@intel.com>
> >>>> Sent: Saturday, November 2, 2019 8:56
> >>>> To: Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
> >>>> <thomas@monjalon.net>
> >>>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> >>>> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> >>>> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> >>>> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> >>>> <viacheslavo@mellanox.com>; Damjan Marion (damarion)
> >>>> <damarion@cisco.com>; Liu, Yu Y <yu.y.liu@intel.com>
> >>>> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> >>>> mode information
> >>>>
> >>>> Add Damjan from FD.io for awareness...
> >>>>
> >>>> Hi Thomas,
> >>>>
> >>>> Long time no see. Sorry I use outlook which is not friendly to
> >>>> community email.
> >>>>
> >>>>> Anyway I will propose to replace this API in the next release.
> >>>> Will your plan be affected by API/ABI stable plan?
> >>>> BTW, if you propose new change in next release, it will make DPDK
> >>>> consumer(FD.io) to change again.
> >>>> So even if it is not affected to the API/ABI stable plan, do we still
> >>>> have time to get a solution for everyone in DPDK 19.11 with your
> >>>> contribution/acceleration?
> >>>>
> >>>>> I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> >>>> Please be rest assured it is not the case.
> >>>> This request is just from one FD.io project internal bug " tx/rx
> >>>> burst function is shown as nil" reported by Chenmin.
> >>>
> >>> Why just the presenting string with function name (possible with suffix) is
> >> not enough?
> >>> I would like to see this API (strings approach) in mlx5 either,
> >>> dropping the entire feature does not look nice, as for me.
> >>>
> >>> We could consider some requirements for the name suffices to
> >>> distinguish whether function uses vector instructions and which ones if any.
> >>>
> >>>> My understanding is DPDK behavior was taken as bug for someone in
> >>>> FD.io project and potentially will mislead other DPDK consumer.
> >>>
> >>> Why does FD.io code want to know which vector extension is used by burst
> >> routines?
> >>> Is it going to share/preserve some resources (registers, etc.)? Is it robust ?
> >>> Burst routines might not know whether vector extensions is used (they
> >>> might call libraries, even rte_memcpy() can use vectors in implicit fashion).
> >>
> >> This is jut debug CLI print, it was added by me as a result of frustration of
> >> dealing constantly with operational issues where people are reporting lower
> >> performance caused by DPDK deciding for variety of reasons to switch from
> >> vector PMD to scalar one.
> >
> > And it seems there is no need for flags, as for me.
> > I think the simple string would be quite enough to identify the datapath routine.
> > Also, we have exact the same issue with mlx5 PMD, so the API (in simple
> > string version) is desirable (+1 from me).
> >
>
> Hi Thomas, Slava,
>
> It has been discussed in the previous mail thread [1], there was no objection to
> it and Haiyue seems send the version based on it.
>
>
> For me having the flag still makes sense, because:
> 1) It helps standardizing the provided string.
> 2) Helps to the application to consume the provided data via API (not text)
>
> The idea was PMD sets the flag for the know standard features, provides the text
> for the non standard part.
> The APIs converts the flag to the string and append to text so it will be
> complete for the app if just wants to log it. Flags still has the standard part
> for the application what to use it.
> Initially standard part was just vectorization but it can be extended by time as
> more common data path used by PMDs. Text part is always free text.
>
>
> After above said, I think the API has been already discussed more than enough,
> and Haiyue already sent an all string version, OK to go with it.
>
> [1]
> http://inbox.dpdk.org/dev/a6893929-f981-4701-7cce-52b5e8ec934e@intel.com/
The string gives more flexibility there is no reason that driver should not
be free to offer any number of algorithms. Likewise, the application should
not care which algorithm is used. The return value must be for information
use only.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions
2019-11-05 15:24 10% [dpdk-dev] [PATCH v8 0/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-11-05 15:24 18% ` [dpdk-dev] [PATCH v8 1/4] doc: separate versioning.rst into version and policy Ray Kinsella
@ 2019-11-05 15:24 23% ` Ray Kinsella
2019-11-05 17:37 5% ` Stephen Hemminger
` (2 more replies)
2019-11-05 15:24 35% ` [dpdk-dev] [PATCH v8 3/4] doc: updates to versioning guide for " Ray Kinsella
2019-11-05 15:24 13% ` [dpdk-dev] [PATCH v8 4/4] doc: add maintainer for abi policy Ray Kinsella
3 siblings, 3 replies; 200+ results
From: Ray Kinsella @ 2019-11-05 15:24 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, john.mcnamara, marko.kovacevic, hemant.agrawal,
ktraynor, aconole
This policy change introduces major ABI versions, these are
declared every year, typically aligned with the LTS release
and are supported by subsequent releases in the following year.
This change is intended to improve ABI stabilty for those projects
consuming DPDK.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
---
doc/guides/contributing/abi_policy.rst | 319 ++++--
.../contributing/img/abi_stability_policy.svg | 1059 ++++++++++++++++++++
doc/guides/contributing/img/what_is_an_abi.svg | 382 +++++++
doc/guides/contributing/stable.rst | 12 +-
4 files changed, 1681 insertions(+), 91 deletions(-)
create mode 100644 doc/guides/contributing/img/abi_stability_policy.svg
create mode 100644 doc/guides/contributing/img/what_is_an_abi.svg
diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst
index d4f4e9f..f8e11d3 100644
--- a/doc/guides/contributing/abi_policy.rst
+++ b/doc/guides/contributing/abi_policy.rst
@@ -1,31 +1,44 @@
.. SPDX-License-Identifier: BSD-3-Clause
- Copyright 2018 The DPDK contributors
+ Copyright 2019 The DPDK contributors
-DPDK ABI/API policy
-===================
+ABI Policy
+==========
Description
-----------
-This document details some methods for handling ABI management in the DPDK.
+This document details the management policy that ensures the long-term stability
+of the DPDK ABI and API.
General Guidelines
------------------
-#. Whenever possible, ABI should be preserved
-#. ABI/API may be changed with a deprecation process
-#. The modification of symbols can generally be managed with versioning
-#. Libraries or APIs marked in ``experimental`` state may change without constraint
-#. New APIs will be marked as ``experimental`` for at least one release to allow
- any issues found by users of the new API to be fixed quickly
-#. The addition of symbols is generally not problematic
-#. The removal of symbols generally is an ABI break and requires bumping of the
- LIBABIVER macro
-#. Updates to the minimum hardware requirements, which drop support for hardware which
- was previously supported, should be treated as an ABI change.
-
-What is an ABI
-~~~~~~~~~~~~~~
+#. Major ABI versions are declared every **year** and are then supported for one
+ year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
+#. The ABI version is managed at a project level in DPDK, with the ABI version
+ reflected in all library's soname.
+#. The ABI should be preserved and not changed lightly. ABI changes must follow
+ the outlined :ref:`deprecation process <abi_changes>`.
+#. The addition of symbols is generally not problematic. The modification of
+ symbols is managed with ABI Versioning.
+#. The removal of symbols is considered an :ref:`ABI breakage <abi_breakages>`,
+ once approved these will form part of the next ABI version.
+#. Libraries or APIs marked as :ref:`Experimental <experimental_apis>` are not
+ considered part of an ABI version and may change without constraint.
+#. Updates to the :ref:`minimum hardware requirements <hw_rqmts>`, which drop
+ support for hardware which was previously supported, should be treated as an
+ ABI change.
+
+.. note::
+
+ In 2019, the DPDK community stated its intention to move to ABI stable
+ releases, over a number of release cycles. This change begins with
+ maintaining ABI stability through one year of DPDK releases starting from
+ DPDK 19.11. This policy will be reviewed in 2020, with intention of
+ lengthening the stability period.
+
+What is an ABI?
+~~~~~~~~~~~~~~~
An ABI (Application Binary Interface) is the set of runtime interfaces exposed
by a library. It is similar to an API (Application Programming Interface) but
@@ -37,30 +50,80 @@ Therefore, in the case of dynamic linking, it is critical that an ABI is
preserved, or (when modified), done in such a way that the application is unable
to behave improperly or in an unexpected fashion.
+.. _figure_what_is_an_abi:
+
+.. figure:: img/what_is_an_abi.*
+
+ Illustration of DPDK API and ABI.
-ABI/API Deprecation
--------------------
+
+What is an ABI version?
+~~~~~~~~~~~~~~~~~~~~~~~
+
+An ABI version is an instance of a library's ABI at a specific release. Certain
+releases are considered to be milestone releases, the yearly LTS release for
+example. The ABI of a milestone release may be designated as a 'major ABI
+version', where this ABI version is then supported for some number of subsequent
+releases and is annotated in the library's soname.
+
+ABI version support in subsequent releases facilitates application upgrades, by
+enabling applications built against the milestone release to upgrade to
+subsequent releases of a library without a rebuild.
+
+More details on major ABI version can be found in the ABI Versioning guide.
The DPDK ABI policy
-~~~~~~~~~~~~~~~~~~~
+-------------------
+
+A major ABI version is declared every year, aligned with that year's LTS
+release, e.g. v19.11. This ABI version is then supported for one year by all
+subsequent releases within that time period, until the next LTS release, e.g.
+v20.11.
-ABI versions are set at the time of major release labeling, and the ABI may
-change multiple times, without warning, between the last release label and the
-HEAD label of the git tree.
+At the declaration of a major ABI version, major version numbers encoded in
+libraries' sonames are bumped to indicate the new version, with the minor
+version reset to ``0``. An example would be ``librte_eal.so.20.3`` would become
+``librte_eal.so.21.0``.
-ABI versions, once released, are available until such time as their
-deprecation has been noted in the Release Notes for at least one major release
-cycle. For example consider the case where the ABI for DPDK 2.0 has been
-shipped and then a decision is made to modify it during the development of
-DPDK 2.1. The decision will be recorded in the Release Notes for the DPDK 2.1
-release and the modification will be made available in the DPDK 2.2 release.
+The ABI may then change multiple times, without warning, between the last major
+ABI version increment and the HEAD label of the git tree, with the condition
+that ABI compatibility with the major ABI version is preserved and therefore
+sonames do not change.
-ABI versions may be deprecated in whole or in part as needed by a given
-update.
+Minor versions are incremented to indicate the release of a new ABI compatible
+DPDK release, typically the DPDK quarterly releases. An example of this, might
+be that ``librte_eal.so.20.1`` would indicate the first ABI compatible DPDK
+release, following the declaration of the new major ABI version ``20``.
-Some ABI changes may be too significant to reasonably maintain multiple
-versions. In those cases ABI's may be updated without backward compatibility
-being provided. The requirements for doing so are:
+An ABI version is supported in all new releases until the next major ABI version
+is declared. When changing the major ABI version, the release notes will detail
+all ABI changes.
+
+.. _figure_abi_stability_policy:
+
+.. figure:: img/abi_stability_policy.*
+
+ Mapping of new ABI versions and ABI version compatibility to DPDK releases.
+
+.. _abi_changes:
+
+ABI Changes
+~~~~~~~~~~~
+
+The ABI may still change after the declaration of a major ABI version, that is
+new APIs may be still added or existing APIs may be modified.
+
+.. Warning::
+
+ Note that, this policy details the method by which the ABI may be changed,
+ with due regard to preserving compatibility and observing deprecation
+ notices. This process however should not be undertaken lightly, as a general
+ rule ABI stability is extremely important for downstream consumers of DPDK.
+ The ABI should only be changed for significant reasons, such as performance
+ enhancements. ABI breakages due to changes such as reorganizing public
+ structure fields for aesthetic or readability purposes should be avoided.
+
+The requirements for changing the ABI are:
#. At least 3 acknowledgments of the need to do so must be made on the
dpdk.org mailing list.
@@ -69,34 +132,119 @@ being provided. The requirements for doing so are:
no maintainer is available for the component, the tree/sub-tree maintainer
for that component must acknowledge the ABI change instead.
+ - The acknowledgment of three members of the technical board, as delegates
+ of the `technical board <https://core.dpdk.org/techboard/>`_ acknowledging
+ the need for the ABI change, is also mandatory.
+
- It is also recommended that acknowledgments from different "areas of
interest" be sought for each deprecation, for example: from NIC vendors,
CPU vendors, end-users, etc.
-#. The changes (including an alternative map file) can be included with
- deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option,
- to provide more details about oncoming changes.
- ``RTE_NEXT_ABI`` wrapper will be removed when it become the default ABI.
- More preferred way to provide this information is sending the feature
- as a separate patch and reference it in deprecation notice.
+#. Backward compatibility with the major ABI version must be maintained through
+ ABI Versioning, with :ref:`forward-only <forward-only>` compatibility
+ offered for any ABI changes that are indicated to be part of the next ABI
+ version.
-#. A full deprecation cycle, as explained above, must be made to offer
- downstream consumers sufficient warning of the change.
+ - In situations where backward compatibility is not possible, read the
+ section on :ref:`abi_breakages`.
-Note that the above process for ABI deprecation should not be undertaken
-lightly. ABI stability is extremely important for downstream consumers of the
-DPDK, especially when distributed in shared object form. Every effort should
-be made to preserve the ABI whenever possible. The ABI should only be changed
-for significant reasons, such as performance enhancements. ABI breakage due to
-changes such as reorganizing public structure fields for aesthetic or
-readability purposes should be avoided.
+ - No backward or forward compatibility is offered for API changes marked as
+ ``experimental``, as described in the section on :ref:`Experimental APIs
+ and Libraries <experimental_apis>`.
-.. note::
+#. If a newly proposed API functionally replaces an existing one, when the new
+ API becomes non-experimental, then the old one is marked with
+ ``__rte_deprecated``.
+
+ - The depreciated API should follow the notification process to be removed,
+ see :ref:`deprecation_notices`.
+
+ - At the declaration of the next major ABI version, those ABI changes then
+ become a formal part of the new ABI and the requirement to preserve ABI
+ compatibility with the last major ABI version is then dropped.
+
+ - The responsibility for removing redundant ABI compatibility code rests
+ with the original contributor of the ABI changes, failing that, then with
+ the contributor's company and then finally with the maintainer.
+
+.. _forward-only:
+
+.. Note::
+
+ Note that forward-only compatibility is offered for those changes made
+ between major ABI versions. As a library's soname can only describe
+ compatibility with the last major ABI version, until the next major ABI
+ version is declared, these changes therefore cannot be resolved as a runtime
+ dependency through the soname. Therefore any application wishing to make use
+ of these ABI changes can only ensure that its runtime dependencies are met
+ through Operating System package versioning.
+
+.. _hw_rqmts:
+
+.. Note::
Updates to the minimum hardware requirements, which drop support for hardware
which was previously supported, should be treated as an ABI change, and
- follow the relevant deprecation policy procedures as above: 3 acks and
- announcement at least one release in advance.
+ follow the relevant deprecation policy procedures as above: 3 acks, technical
+ board approval and announcement at least one release in advance.
+
+.. _abi_breakages:
+
+ABI Breakages
+~~~~~~~~~~~~~
+
+For those ABI changes that are too significant to reasonably maintain multiple
+symbol versions, there is an amended process. In these cases, ABIs may be
+updated without the requirement of backward compatibility being provided. These
+changes must follow the same process :ref:`described above <abi_changes>` as non-breaking
+changes, however with the following additional requirements:
+
+#. ABI breaking changes (including an alternative map file) can be included with
+ deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option, to provide
+ more details about oncoming changes. ``RTE_NEXT_ABI`` wrapper will be removed
+ at the declaration of the next major ABI version.
+
+#. Once approved, and after the deprecation notice has been observed these
+ changes will form part of the next declared major ABI version.
+
+Examples of ABI Changes
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The following are examples of allowable ABI changes occurring between
+declarations of major ABI versions.
+
+* DPDK 19.11 release, defines the function ``rte_foo()``, and ``rte_foo()``
+ as part of the major ABI version ``20``.
+
+* DPDK 20.02 release defines a new function ``rte_foo(uint8_t bar)``, and
+ this is not a problem as long as the symbol ``rte_foo@DPDK20`` is
+ preserved through ABI Versioning.
+
+ - The new function may be marked with the ``__rte_experimental`` tag for a
+ number of releases, as described in the section :ref:`experimental_apis`.
+
+ - Once ``rte_foo(uint8_t bar)`` becomes non-experimental ``rte_foo()`` is then
+ declared as ``__rte_depreciated``, with an associated deprecation notice
+ provided.
+
+* DPDK 19.11 is not re-released to include ``rte_foo(uint8_t bar)``, the new
+ version of ``rte_foo`` only exists from DPDK 20.02 onwards as described in the
+ :ref:`note on forward-only compatibility<forward-only>`.
+
+* DPDK 20.02 release defines the experimental function ``__rte_experimental
+ rte_baz()``. This function may or may not exist in the DPDK 20.05 release.
+
+* An application ``dPacket`` wishes to use ``rte_foo(uint8_t bar)``, before the
+ declaration of the DPDK ``21`` major API version. The application can only
+ ensure its runtime dependencies are met by specifying ``DPDK (>= 20.2)`` as
+ an explicit package dependency, as the soname only may only indicate the
+ supported major ABI version.
+
+* At the release of DPDK 20.11, the function ``rte_foo(uint8_t bar)`` becomes
+ formally part of then new major ABI version DPDK 21.0 and ``rte_foo()`` may be
+ removed.
+
+.. _deprecation_notices:
Examples of Deprecation Notices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -104,46 +252,42 @@ Examples of Deprecation Notices
The following are some examples of ABI deprecation notices which would be
added to the Release Notes:
-* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
- to be replaced with the inline function ``rte_foo()``.
+* The Macro ``#RTE_FOO`` is deprecated and will be removed with ABI version
+ 21, to be replaced with the inline function ``rte_foo()``.
* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
- in version 2.0. Backwards compatibility will be maintained for this function
- until the release of version 2.1
+ in version 20.2. Backwards compatibility will be maintained for this function
+ until the release of the new DPDK major ABI version 21, in DPDK version
+ 20.11.
-* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
+* The members of ``struct rte_foo`` have been reorganized in DPDK 20.02 for
performance reasons. Existing binary applications will have backwards
- compatibility in release 2.0, while newly built binaries will need to
- reference the new structure variant ``struct rte_foo2``. Compatibility will
- be removed in release 2.2, and all applications will require updating and
+ compatibility in release 20.02, while newly built binaries will need to
+ reference the new structure variant ``struct rte_foo2``. Compatibility will be
+ removed in release 20.11, and all applications will require updating and
rebuilding to the new structure at that time, which will be renamed to the
original ``struct rte_foo``.
* Significant ABI changes are planned for the ``librte_dostuff`` library. The
- upcoming release 2.0 will not contain these changes, but release 2.1 will,
+ upcoming release 20.02 will not contain these changes, but release 20.11 will,
and no backwards compatibility is planned due to the extensive nature of
- these changes. Binaries using this library built prior to version 2.1 will
+ these changes. Binaries using this library built prior to ABI version 21 will
require updating and recompilation.
-New API replacing previous one
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If a new API proposed functionally replaces an existing one, when the new API
-becomes non-experimental then the old one is marked with ``__rte_deprecated``.
-Deprecated APIs are removed completely just after the next LTS.
+.. _experimental_apis:
-Reminder that old API should follow deprecation process to be removed.
+Experimental
+------------
+APIs
+~~~~
-Experimental APIs
------------------
-
-APIs marked as ``experimental`` are not considered part of the ABI and may
-change without warning at any time. Since changes to APIs are most likely
-immediately after their introduction, as users begin to take advantage of
-those new APIs and start finding issues with them, new DPDK APIs will be
-automatically marked as ``experimental`` to allow for a period of stabilization
-before they become part of a tracked ABI.
+APIs marked as ``experimental`` are not considered part of an ABI version and
+may change without warning at any time. Since changes to APIs are most likely
+immediately after their introduction, as users begin to take advantage of those
+new APIs and start finding issues with them, new DPDK APIs will be automatically
+marked as ``experimental`` to allow for a period of stabilization before they
+become part of a tracked ABI version.
Note that marking an API as experimental is a multi step process.
To mark an API as experimental, the symbols which are desired to be exported
@@ -161,7 +305,16 @@ In addition to tagging the code with ``__rte_experimental``,
the doxygen markup must also contain the EXPERIMENTAL string,
and the MAINTAINERS file should note the EXPERIMENTAL libraries.
-For removing the experimental tag associated with an API, deprecation notice
-is not required. Though, an API should remain in experimental state for at least
-one release. Thereafter, normal process of posting patch for review to mailing
-list can be followed.
+For removing the experimental tag associated with an API, deprecation notice is
+not required. Though, an API should remain in experimental state for at least
+one release. Thereafter, the normal process of posting patch for review to
+mailing list can be followed.
+
+Libraries
+~~~~~~~~~
+
+Libraries marked as ``experimental`` are entirely not considered part of an ABI
+version, and may change without warning at any time. Experimental libraries
+always have a major version of ``0`` to indicate they exist outside of
+ABI Versioning, with the minor version incremented with each ABI change
+to library.
diff --git a/doc/guides/contributing/img/abi_stability_policy.svg b/doc/guides/contributing/img/abi_stability_policy.svg
new file mode 100644
index 0000000..4fd4007
--- /dev/null
+++ b/doc/guides/contributing/img/abi_stability_policy.svg
@@ -0,0 +1,1059 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1237.4869"
+ height="481.37463"
+ version="1.1"
+ viewBox="0 0 1237.4869 481.37463"
+ xml:space="preserve"
+ id="svg7800"
+ sodipodi:docname="abi_stability_policy.svg"
+ inkscape:version="0.92.2 (5c3e80d, 2017-08-06)"><metadata
+ id="metadata7804"><rdf:RDF><cc:Work
+ rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" /></cc:Work></rdf:RDF></metadata><sodipodi:namedview
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1"
+ objecttolerance="10"
+ gridtolerance="10"
+ guidetolerance="10"
+ inkscape:pageopacity="0"
+ inkscape:pageshadow="2"
+ inkscape:window-width="1920"
+ inkscape:window-height="1017"
+ id="namedview7802"
+ showgrid="false"
+ inkscape:zoom="0.8875"
+ inkscape:cx="840.50495"
+ inkscape:cy="179.36692"
+ inkscape:window-x="-8"
+ inkscape:window-y="-8"
+ inkscape:window-maximized="1"
+ inkscape:current-layer="svg7800" /><defs
+ id="defs7394"><clipPath
+ id="clipPath3975"><path
+ d="M 0,1.2207e-4 H 960 V 540.00012 H 0 Z"
+ id="path7226"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4003"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7229"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4025"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7232"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4037"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7235"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4049"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7238"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4061"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7241"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4073"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7244"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4085"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7247"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4097"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7250"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4109"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7253"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4121"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7256"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4133"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7259"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4145"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7262"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4157"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7265"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4169"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7268"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4181"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7271"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4193"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7274"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4205"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7277"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4217"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7280"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4229"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7283"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4241"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7286"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4253"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7289"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4265"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7292"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4277"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7295"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4289"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7298"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4301"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7301"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4313"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7304"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4327"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7307"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4339"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7310"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4351"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7313"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4363"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7316"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4375"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7319"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4389"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7322"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4403"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7325"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4417"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7328"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4429"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7331"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4441"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7334"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4453"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7337"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4477"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7340"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4489"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7343"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4501"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7346"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4513"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7349"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4525"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7352"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4537"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7355"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4549"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7358"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4561"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7361"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4573"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7364"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4589"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7367"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4601"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7370"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4615"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7373"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4629"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7376"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4641"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7379"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4653"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7382"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4673"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7385"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4685"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7388"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath4699"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path7391"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath></defs><g
+ id="g7406"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><path
+ style="fill:#44546a"
+ inkscape:connector-curvature="0"
+ id="path7400"
+ d="m 161.83,180.57 773.79,4.78 c 0.82,0.01 1.49,0.68 1.49,1.51 -0.01,0.83 -0.68,1.5 -1.51,1.49 l -773.79,-4.78 c -0.83,-0.01 -1.5,-0.68 -1.49,-1.51 0.01,-0.83 0.68,-1.5 1.51,-1.49 z m 772.3,1.77 8.97,4.56 -9.03,4.44 z" /><path
+ style="fill:#00b050;fill-rule:evenodd"
+ inkscape:connector-curvature="0"
+ id="path7402"
+ d="m 173.28,182.22 c 0,4.67 3.36,8.46 7.5,8.46 4.14,0 7.5,-3.79 7.5,-8.46 0,-4.67 -3.36,-8.46 -7.5,-8.46 -4.14,0 -7.5,3.79 -7.5,8.46 z" /><path
+ style="fill:#00b050;fill-rule:evenodd"
+ inkscape:connector-curvature="0"
+ id="path7404"
+ d="m 612.24,183.78 c 0,4.67 3.36,8.46 7.5,8.46 4.14,0 7.5,-3.79 7.5,-8.46 0,-4.67 -3.36,-8.46 -7.5,-8.46 -4.14,0 -7.5,3.79 -7.5,8.46 z" /></g><g
+ style="fill:#ff0000;fill-rule:evenodd"
+ id="g7420"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><path
+ inkscape:connector-curvature="0"
+ id="path7408"
+ d="m 228.12,182.22 c 0,4.67 3.36,8.46 7.5,8.46 4.14,0 7.5,-3.79 7.5,-8.46 0,-4.67 -3.36,-8.46 -7.5,-8.46 -4.14,0 -7.5,3.79 -7.5,8.46 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7410"
+ d="m 282.96,182.22 c 0,4.67 3.36,8.46 7.5,8.46 4.14,0 7.5,-3.79 7.5,-8.46 0,-4.67 -3.36,-8.46 -7.5,-8.46 -4.14,0 -7.5,3.79 -7.5,8.46 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7412"
+ d="m 337.8,182.22 c 0,4.67 3.38,8.46 7.56,8.46 4.18,0 7.56,-3.79 7.56,-8.46 0,-4.67 -3.38,-8.46 -7.56,-8.46 -4.18,0 -7.56,3.79 -7.56,8.46 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7414"
+ d="m 447.6,182.22 c 0,4.67 3.36,8.46 7.5,8.46 4.14,0 7.5,-3.79 7.5,-8.46 0,-4.67 -3.36,-8.46 -7.5,-8.46 -4.14,0 -7.5,3.79 -7.5,8.46 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7416"
+ d="m 502.44,182.34 c 0,4.67 3.38,8.46 7.56,8.46 4.18,0 7.56,-3.79 7.56,-8.46 0,-4.67 -3.38,-8.46 -7.56,-8.46 -4.18,0 -7.56,3.79 -7.56,8.46 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7418"
+ d="m 557.28,182.34 c 0,4.67 3.38,8.46 7.56,8.46 4.18,0 7.56,-3.79 7.56,-8.46 0,-4.67 -3.38,-8.46 -7.56,-8.46 -4.18,0 -7.56,3.79 -7.56,8.46 z" /></g><g
+ id="g7426"
+ clip-path="url(#clipPath4003)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7424"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,152.98,149.45)"><tspan
+ id="tspan7422"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 24.10668 31.22496">v19.11</tspan></text>
+</g><path
+ style="fill:#00b050;fill-rule:evenodd;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7428"
+ d="m 499.42541,379.9105 c 0,-6.22651 4.47989,-11.27972 9.99975,-11.27972 5.51986,0 9.99975,5.05321 9.99975,11.27972 0,6.22651 -4.47989,11.27972 -9.99975,11.27972 -5.51986,0 -9.99975,-5.05321 -9.99975,-11.27972 z" /><path
+ style="fill:#00b050;fill-rule:evenodd;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7430"
+ d="m 1084.6908,373.67065 c 0,-6.22651 4.4799,-11.27971 9.9997,-11.27971 5.5199,0 9.9998,5.0532 9.9998,11.27971 0,6.22652 -4.4799,11.27972 -9.9998,11.27972 -5.5198,0 -9.9997,-5.0532 -9.9997,-11.27972 z" /><g
+ style="fill:#ff0000;fill-rule:evenodd"
+ id="g7438"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><path
+ inkscape:connector-curvature="0"
+ id="path7432"
+ d="m 667.08,185.4 c 0,4.64 3.36,8.4 7.5,8.4 4.14,0 7.5,-3.76 7.5,-8.4 0,-4.64 -3.36,-8.4 -7.5,-8.4 -4.14,0 -7.5,3.76 -7.5,8.4 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7434"
+ d="m 721.92,185.58 c 0,4.67 3.38,8.46 7.56,8.46 4.18,0 7.56,-3.79 7.56,-8.46 0,-4.67 -3.38,-8.46 -7.56,-8.46 -4.18,0 -7.56,3.79 -7.56,8.46 z" /><path
+ inkscape:connector-curvature="0"
+ id="path7436"
+ d="m 776.76,185.58 c 0,4.67 3.38,8.46 7.56,8.46 4.18,0 7.56,-3.79 7.56,-8.46 0,-4.67 -3.38,-8.46 -7.56,-8.46 -4.18,0 -7.56,3.79 -7.56,8.46 z" /></g><g
+ id="g7444"
+ clip-path="url(#clipPath4025)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7442"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,210.14,150.1)"><tspan
+ id="tspan7440"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 24.10668 31.22496">v20.02</tspan></text>
+</g><g
+ id="g7450"
+ clip-path="url(#clipPath4037)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7448"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,265.01,150.1)"><tspan
+ id="tspan7446"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 24.10668 31.22496">v20.05</tspan></text>
+</g><g
+ id="g7456"
+ clip-path="url(#clipPath4049)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7454"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,319.9,150.77)"><tspan
+ id="tspan7452"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 24.10668 31.22496">v20.08</tspan></text>
+</g><g
+ id="g7462"
+ clip-path="url(#clipPath4061)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7460"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,375,150.94)"><tspan
+ id="tspan7458"
+ y="0"
+ x="0 7.9180322 14.992224 22.066416 25.652737 32.726929">V20.11</tspan></text>
+</g><g
+ id="g7468"
+ clip-path="url(#clipPath4073)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7466"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,429.17,150.94)"><tspan
+ id="tspan7464"
+ y="0"
+ x="0 6.3569279 13.445184 20.519377 24.105696 31.179888">v21.02</tspan></text>
+</g><g
+ id="g7474"
+ clip-path="url(#clipPath4085)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7472"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,483,150.55)"><tspan
+ id="tspan7470"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 24.10668 31.22496">v21.05</tspan></text>
+</g><g
+ id="g7480"
+ clip-path="url(#clipPath4097)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7478"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,537.38,150.82)"><tspan
+ id="tspan7476"
+ y="0"
+ x="0 6.3569279 13.445184 20.519377 24.105696 31.179888">v21.08</tspan></text>
+</g><g
+ id="g7486"
+ clip-path="url(#clipPath4109)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7484"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,592.27,150.82)"><tspan
+ id="tspan7482"
+ y="0"
+ x="0 6.3569279 13.445184 20.519377 24.105696 31.179888">v21.11</tspan></text>
+</g><g
+ id="g7492"
+ clip-path="url(#clipPath4121)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7490"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,647.14,151.46)"><tspan
+ id="tspan7488"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 24.10668 31.22496">v22.02</tspan></text>
+</g><g
+ id="g7498"
+ clip-path="url(#clipPath4133)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7496"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,702.24,151.63)"><tspan
+ id="tspan7494"
+ y="0"
+ x="0 7.96068 14.99472 22.113001 25.651079 32.76936">V22.05</tspan></text>
+</g><g
+ id="g7504"
+ clip-path="url(#clipPath4145)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7502"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,756.43,151.63)"><tspan
+ id="tspan7500"
+ y="0"
+ x="0 7.96068 14.99472 22.113001 25.651079 32.76936">V22.08</tspan></text>
+</g><g
+ id="g7510"
+ clip-path="url(#clipPath4157)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7508"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,811.99,151.63)"><tspan
+ id="tspan7506"
+ y="0"
+ x="0 7.96068 14.99472 22.113001 25.651079 32.76936">V22.11</tspan></text>
+</g><g
+ id="g7516"
+ clip-path="url(#clipPath4169)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7514"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,105.82,214.18)"><tspan
+ id="tspan7512"
+ y="0"
+ x="0 6.3460798 13.46436">v20</tspan></text>
+</g><g
+ id="g7522"
+ clip-path="url(#clipPath4181)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7520"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,105.5,247.68)"><tspan
+ id="tspan7518"
+ y="0"
+ x="0 6.3569279 13.445184">v21</tspan></text>
+</g><g
+ id="g7528"
+ clip-path="url(#clipPath4193)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7526"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,228.79,214.51)"><tspan
+ id="tspan7524"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7534"
+ clip-path="url(#clipPath4205)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7532"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,283.8,214.51)"><tspan
+ id="tspan7530"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7540"
+ clip-path="url(#clipPath4217)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7538"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,337.68,214.51)"><tspan
+ id="tspan7536"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7546"
+ clip-path="url(#clipPath4229)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7544"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,611.66,285.79)"><tspan
+ id="tspan7542"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7552"
+ clip-path="url(#clipPath4241)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7550"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,666.65,285.79)"><tspan
+ id="tspan7548"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7558"
+ clip-path="url(#clipPath4253)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7556"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,719.4,285.79)"><tspan
+ id="tspan7554"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7564"
+ clip-path="url(#clipPath4265)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7562"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,775.56,285.79)"><tspan
+ id="tspan7560"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7570"
+ clip-path="url(#clipPath4277)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7568"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,398.54,249.22)"><tspan
+ id="tspan7566"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7576"
+ clip-path="url(#clipPath4289)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7574"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,453.53,249.22)"><tspan
+ id="tspan7572"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7582"
+ clip-path="url(#clipPath4301)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7580"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,507.43,249.22)"><tspan
+ id="tspan7578"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7588"
+ clip-path="url(#clipPath4313)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7586"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,561.05,249.22)"><tspan
+ id="tspan7584"
+ y="0"
+ x="0">√</tspan></text>
+</g><path
+ style="fill:#44546a;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7590"
+ d="m 217.67245,474.73479 v -25.14603 c 0,-1.10664 -0.89331,-1.99995 -1.99995,-1.99995 -1.10664,0 -1.99995,0.89331 -1.99995,1.99995 v 25.14603 c 0,1.09331 0.89331,1.99995 1.99995,1.99995 1.10664,0 1.99995,-0.90664 1.99995,-1.99995 z m 3.9999,-23.14608 -5.99985,-11.9997 -5.99985,11.9997 z" /><g
+ id="g7596"
+ clip-path="url(#clipPath4327)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7594"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,170.83,214.51)"><tspan
+ id="tspan7592"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7602"
+ clip-path="url(#clipPath4339)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-weight:bold;font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7600"
+ font-weight="bold"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,23.4,272.33)"><tspan
+ id="tspan7598"
+ y="0"
+ x="0 8.5227842 16.412687 20.167776">ABI </tspan></text>
+</g><g
+ id="g7608"
+ clip-path="url(#clipPath4351)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-weight:bold;font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7606"
+ font-weight="bold"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,46.68,272.33)"><tspan
+ id="tspan7604"
+ y="0"
+ x="0 7.566432 14.640624 19.563025 25.174561 28.662432 36.228863">Version</tspan></text>
+</g><g
+ id="g7614"
+ clip-path="url(#clipPath4363)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-weight:bold;font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7612"
+ font-weight="bold"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,17.64,255.5)"><tspan
+ id="tspan7610"
+ y="0"
+ x="0 7.4271598 14.98068 26.395201 33.934681 40.80024 45.700199 49.154041 56.7216 60.175442 63.671398 67.125237 72.053284">Compatibility</tspan></text>
+</g><g
+ id="g7620"
+ clip-path="url(#clipPath4375)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7618"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,191.28,116.86)"><tspan
+ id="tspan7616"
+ y="0"
+ x="0 6.3460798 13.46436">v20</tspan></text>
+</g><path
+ style="fill:#44546a;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7622"
+ d="m 511.7451,474.89479 v -25.14604 c 0,-1.10664 -0.89331,-1.99995 -1.99995,-1.99995 -1.10664,0 -1.99995,0.89331 -1.99995,1.99995 v 25.14604 c 0,1.09331 0.89331,1.99995 1.99995,1.99995 1.10664,0 1.99995,-0.90664 1.99995,-1.99995 z m 3.9999,-23.14609 -5.99985,-11.9997 -5.99985,11.9997 z" /><g
+ id="g7628"
+ clip-path="url(#clipPath4389)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7626"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,407.06,115.63)"><tspan
+ id="tspan7624"
+ y="0"
+ x="0 6.3460798 13.46436">v21</tspan></text>
+</g><path
+ style="fill:#44546a;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7630"
+ d="m 804.53778,476.01476 v -25.14604 c 0,-1.10664 -0.89331,-1.99995 -1.99995,-1.99995 -1.10664,0 -1.99995,0.89331 -1.99995,1.99995 v 25.14604 c 0,1.09331 0.89331,1.99995 1.99995,1.99995 1.10664,0 1.99995,-0.90664 1.99995,-1.99995 z m 3.9999,-23.14609 -5.99985,-11.9997 -5.99985,11.9997 z" /><g
+ id="g7636"
+ clip-path="url(#clipPath4403)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7634"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,626.66,114.74)"><tspan
+ id="tspan7632"
+ y="0"
+ x="0 6.3460798 13.46436">v22</tspan></text>
+</g><path
+ style="fill:#44546a;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7638"
+ d="m 1098.2904,479.37468 v -25.14604 c 0,-1.10664 -0.8933,-1.99995 -1.9999,-1.99995 -1.1067,0 -2,0.89331 -2,1.99995 v 25.14604 c 0,1.0933 0.8933,1.99995 2,1.99995 1.1066,0 1.9999,-0.90665 1.9999,-1.99995 z m 3.9999,-23.14609 -5.9998,-11.9997 -5.9999,11.9997 z" /><g
+ id="g7644"
+ clip-path="url(#clipPath4417)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7642"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,846.96,112.22)"><tspan
+ id="tspan7640"
+ y="0"
+ x="0 6.3569279 13.445184">v23</tspan></text>
+</g><g
+ id="g7650"
+ clip-path="url(#clipPath4429)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7648"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,832.87,318.46)"><tspan
+ id="tspan7646"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7656"
+ clip-path="url(#clipPath4441)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7654"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,105.5,285.67)"><tspan
+ id="tspan7652"
+ y="0"
+ x="0 6.3460798 13.46436">v22</tspan></text>
+</g><g
+ id="g7662"
+ clip-path="url(#clipPath4453)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7660"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,104.93,319.87)"><tspan
+ id="tspan7658"
+ y="0"
+ x="0 6.3460798 13.46436">v23</tspan></text>
+</g><path
+ style="fill:none;stroke:#5b9bd5;stroke-width:0.63998401;stroke-miterlimit:10;stroke-dasharray:2.559936, 1.919952"
+ inkscape:connector-curvature="0"
+ id="path7664"
+ stroke-miterlimit="10"
+ d="m 1104.7569,213.75465 -934.60326,0.39999" /><path
+ style="fill:none;stroke:#5b9bd5;stroke-width:0.63998401;stroke-miterlimit:10;stroke-dasharray:2.559936, 1.919952"
+ inkscape:connector-curvature="0"
+ id="path7666"
+ stroke-miterlimit="10"
+ d="M 1105.3969,255.35361 170.79362,255.7536" /><path
+ style="fill:none;stroke:#5b9bd5;stroke-width:0.63998401;stroke-miterlimit:10;stroke-dasharray:2.559936, 1.919952"
+ inkscape:connector-curvature="0"
+ id="path7668"
+ stroke-miterlimit="10"
+ d="M 1105.3969,299.35251 170.79362,299.7525" /><g
+ id="g7674"
+ clip-path="url(#clipPath4477)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#8497b0"
+ id="text7672"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,283.8,251.38)"><tspan
+ id="tspan7670"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7680"
+ clip-path="url(#clipPath4489)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#8497b0"
+ id="text7678"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,339.5,251.95)"><tspan
+ id="tspan7676"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7686"
+ clip-path="url(#clipPath4501)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#d0cece"
+ id="text7684"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,229.8,250.63)"><tspan
+ id="tspan7682"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7692"
+ clip-path="url(#clipPath4513)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#d0cece"
+ id="text7690"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,453.53,286.63)"><tspan
+ id="tspan7688"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7698"
+ clip-path="url(#clipPath4525)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#8497b0"
+ id="text7696"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,507.43,286.63)"><tspan
+ id="tspan7694"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7704"
+ clip-path="url(#clipPath4537)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#8497b0"
+ id="text7702"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,561.05,286.63)"><tspan
+ id="tspan7700"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7710"
+ clip-path="url(#clipPath4549)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#d0cece"
+ id="text7708"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,667.39,318.89)"><tspan
+ id="tspan7706"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7716"
+ clip-path="url(#clipPath4561)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#8497b0"
+ id="text7714"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,720.14,318.89)"><tspan
+ id="tspan7712"
+ y="0"
+ x="0">√</tspan></text>
+</g><g
+ id="g7722"
+ clip-path="url(#clipPath4573)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#8497b0"
+ id="text7720"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,776.3,318.89)"><tspan
+ id="tspan7718"
+ y="0"
+ x="0">√</tspan></text>
+</g><path
+ style="fill:#7030a0;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7724"
+ d="m 211.36594,305.0057 2.18661,-227.154316 c 0.0133,-1.0933 -0.87997,-1.99995 -1.98661,-2.01328 -1.09331,-0.0133 -1.99995,0.87998 -2.01329,1.98662 l -2.18661,227.140986 c -0.0133,1.10663 0.87998,2.01328 1.98662,2.02661 1.10664,0.0133 1.99995,-0.87998 2.01328,-1.98662 z m -7.97313,-2.07994 5.87985,12.06636 6.11985,-11.94637 z" /><path
+ style="fill:#7030a0;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7726"
+ d="M 289.03067,238.94069 V 107.43731 c 0,-1.10664 -0.89331,-1.99995 -1.99995,-1.99995 -1.10664,0 -1.99995,0.89331 -1.99995,1.99995 v 131.50338 c 0,1.09331 0.89331,1.99995 1.99995,1.99995 1.10664,0 1.99995,-0.90664 1.99995,-1.99995 z m -7.9998,-1.99995 5.99985,11.9997 5.99985,-11.9997 z" /><g
+ id="g7732"
+ clip-path="url(#clipPath4589)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7730"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,164.59,422.74)"><tspan
+ id="tspan7728"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 23.75568 31.88484 39.578758 43.06068 46.065239 49.294441 54.784081 57.957119 65.271957 72.263878 78.118561 81.347763 88.072922 92.762283 99.754204 107.04096 110.38248 117.10764 120.33684 123.56604 130.17888 137.50777 144.49968 151.78644 155.12796 165.16656 168.43788 173.14128 180.44208 183.67128 190.01736 197.13564 204.19775 207.77795 214.89624 221.94432 225.17352 229.9752 236.70036">v20 ABI is declared aligned with v19.11 LTS</tspan></text>
+</g><g
+ id="g7738"
+ clip-path="url(#clipPath4601)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.06400013px;font-family:Calibri;fill:#000000"
+ id="text7736"
+ font-size="14.064px"
+ transform="matrix(1,0,0,-1,222.12,398.3)"><tspan
+ id="tspan7734"
+ y="0"
+ x="0 6.3569279 13.445184 20.519377 23.740032 29.014032 35.385025 46.537777 53.851055 61.262783 64.497505 70.038719 73.034355 79.771011 84.440254 91.401939 94.622589 101.35925 108.65846 115.97174 122.93343 130.2467 133.59393 140.3306 147.62981 154.94308 158.16374 164.52068 171.60893 178.68312 181.90378 187.17778 193.54877 204.70152 212.0148 219.42653 222.66125 228.20247 231.32468 238.06133 242.73058 249.69226 252.81447 263.98129 271.39301 278.77661 282.01132 286.30084 289.53555 296.53943 303.82458 307.34061 310.51904 316.0462 323.3595 330.67276 337.98605 345.39777 350.30612 355.01755 358.13977 362.21832 369.63004 374.53839 377.5762 383.93314 391.02139 398.09558 401.2178 409.36084 417.03979 420.51361 423.6358 429.40204 436.81378 444.04266 448.75412 451.98883 459.28806 466.60132 473.56302 479.06204">v21 symbols are added and v20 symbols are modified, support for v20 ABI continues.</tspan></text>
+</g><path
+ style="fill:#7030a0;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7740"
+ d="m 510.78512,258.56686 -0.31999,-126.17017 c 0,-1.09331 0.89331,-1.99995 1.99995,-1.99995 1.09331,0 1.99995,0.89331 1.99995,1.99995 l 0.31999,126.15684 c 0,1.10664 -0.89331,2.01328 -1.99995,2.01328 -1.0933,0 -1.99995,-0.89331 -1.99995,-1.99995 z m 7.9998,-2.01328 -5.97318,12.01303 -6.02652,-11.98636 z" /><g
+ id="g7746"
+ clip-path="url(#clipPath4615)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7744"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,388.51,373.39)"><tspan
+ id="tspan7742"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 23.75568 31.88484 39.578758 43.06068 46.065239 49.294441 54.784081 57.957119 65.271957 72.263878 78.118561 81.347763 88.072922 92.762283 99.754204 107.04096 110.38248 117.10764 120.33684 123.56604 130.17888 137.50777 144.49968 151.78644 155.12796 165.16656 168.43788 173.14128 180.44208 183.67128 190.01736 197.13564 204.19775 207.77795 214.89624 221.94432 225.17352 229.9752 236.70036 243.14471 246.65472 249.78564 254.46095 261.45288 272.58661 279.31177 282.54095 289.86984 293.09903 300.47003 307.02673 310.36823 316.71432 323.83261 330.89471 334.12393 339.40295 345.76309 356.92487 364.23972 371.63879 374.91013 380.39975 383.4324 390.15756 394.83289 401.8248 404.99783 409.71527 416.70721 427.84091 435.23999 441.51587 448.50781 455.79456">v21 ABI is declared aligned with v20.11 LTS, remaining v20 symbols are removed.</tspan></text>
+</g><path
+ style="fill:none;stroke:#7030a0;stroke-width:2.07994795;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path7748"
+ stroke-miterlimit="10"
+ d="M 278.23094,342.95142 H 449.58665 V 261.03347 H 278.23094 Z" /><g
+ id="g7754"
+ clip-path="url(#clipPath4629)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-weight:bold;font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7752"
+ font-weight="bold"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,23.616,114.74)"><tspan
+ id="tspan7750"
+ y="0"
+ x="0 8.5082397 16.4268 20.17548 23.26428 30.817801 37.879921 42.821999 48.423962 51.93396 59.48748 67.026962">ABI Versions</tspan></text>
+</g><g
+ id="g7760"
+ clip-path="url(#clipPath4641)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-weight:bold;font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7758"
+ font-weight="bold"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,20.064,150.17)"><tspan
+ id="tspan7756"
+ y="0"
+ x="0 8.8451996 16.31448 25.159679 32.839561 36.0126 43.67844 50.740559 54.222481 61.284599 68.248444 73.850403 80.954643">DPDK Releases</tspan></text>
+</g><g
+ id="g7766"
+ clip-path="url(#clipPath4653)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7764"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,444,346.1)"><tspan
+ id="tspan7762"
+ y="0"
+ x="0 6.3460798 13.46436 20.52648 23.75568 29.034719 35.39484 46.556641 53.871479 61.270561 64.541878 70.031517 73.064163 79.789322 84.464638 91.456558 94.629601 101.35476 108.72576 116.02656 123.01848 130.30524 133.64676 140.37192 147.68677 155.0016 158.2308 164.57687 171.69516 178.75728 181.98648 187.26552 193.62564 204.78745 212.10228 219.50136 222.77267 228.26231 231.43536 238.16052 242.80775 249.79968 252.88847 264.05029 271.44937 278.82037 282.04956 286.33176 289.60309 296.595 303.88177 307.39175 310.56479 316.1106 323.42545 330.74026 338.05511 345.45419 350.39627 355.09967 358.20251 362.28815 369.68723 374.62933 377.63388 383.97995 391.09824 398.16037 401.27725 409.4064 417.10031 420.58224 423.69913 429.45551 436.85461 444.09924 448.80264 452.03183 459.33264 466.64749 473.6394 479.12903 488.81665 492.43896">v22 symbols are added and v21 symbols are modified, support for v21 ABI continues…..</tspan></text>
+</g><path
+ style="fill:#7030a0;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7768"
+ d="m 583.39664,198.26171 -0.13333,-30.49257 c 0,-1.10664 0.89331,-2.01329 1.98662,-2.01329 1.10664,0 2.01328,0.89331 2.01328,1.98662 l 0.13333,30.49257 c 0,1.10664 -0.89331,2.01328 -1.99995,2.01328 -1.0933,0 -1.99995,-0.89331 -1.99995,-1.98661 z m 7.98647,-2.03995 -5.94652,12.02636 -6.05318,-11.97303 z" /><path
+ style="fill:none;stroke:#7030a0;stroke-width:2.07994795;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path7770"
+ stroke-miterlimit="10"
+ d="M 571.18361,299.43251 H 742.37933 V 212.87467 H 571.18361 Z" /><path
+ style="fill:#00b050;fill-rule:evenodd;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7772"
+ d="m 933.01457,30.959224 c 0,-6.22651 4.50655,-11.27972 10.07975,-11.27972 5.57319,0 10.07974,5.05321 10.07974,11.27972 0,6.22651 -4.50655,11.27972 -10.07974,11.27972 -5.5732,0 -10.07975,-5.05321 -10.07975,-11.27972 z" /><path
+ style="fill:#ff0000;fill-rule:evenodd;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7774"
+ d="m 1081.3309,29.759254 c 0,-6.18651 4.4798,-11.19972 9.9997,-11.19972 5.5199,0 9.9998,5.01321 9.9998,11.19972 0,6.18651 -4.4799,11.19972 -9.9998,11.19972 -5.5199,0 -9.9997,-5.01321 -9.9997,-11.19972 z" /><g
+ id="g7780"
+ clip-path="url(#clipPath4673)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7778"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,744.89,439.54)"><tspan
+ id="tspan7776"
+ y="0"
+ x="0 4.8016801 11.52684 17.971201 21.144239 28.5714 35.56332 38.792519 45.728279 52.453442 57.943081">LTS Release</tspan></text>
+</g><g
+ id="g7786"
+ clip-path="url(#clipPath4685)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7784"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,856.06,439.75)"><tspan
+ id="tspan7782"
+ y="0"
+ x="0 12.0042 15.2334 22.562281 29.961361 34.903439 38.020321 45.461521 52.453442 55.68264 62.618401 69.343559 74.833199">Minor Release</tspan></text>
+</g><path
+ style="fill:#44546a;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path7788"
+ d="m 779.25841,46.265514 v -25.14604 c 0,-1.10664 -0.89331,-1.99995 -1.99995,-1.99995 -1.10664,0 -1.99995,0.89331 -1.99995,1.99995 v 25.14604 c 0,1.0933 0.89331,1.99995 1.99995,1.99995 1.10664,0 1.99995,-0.90665 1.99995,-1.99995 z m 3.9999,-23.14609 -5.99985,-11.9997 -5.99985,11.9997 z" /><g
+ id="g7794"
+ clip-path="url(#clipPath4699)"
+ transform="matrix(1.3333,0,0,-1.3333,-24.241503,623.02442)"><text
+ style="font-size:14.03999996px;font-family:Calibri;fill:#000000"
+ id="text7792"
+ font-size="14.04px"
+ transform="matrix(1,0,0,-1,622.34,439.54)"><tspan
+ id="tspan7790"
+ y="0"
+ x="0 8.1291599 15.82308 19.305 22.309561 29.512079 36.504002 41.151241 46.640881 49.870079 57.339359">ABI Version</tspan></text>
+</g><path
+ style="fill:none;stroke:#002060;stroke-width:1.27996802;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path7796"
+ stroke-miterlimit="10"
+ d="M 763.41881,62.078444 H 1236.847 V 0.63998401 H 763.41881 Z" /></svg>
\ No newline at end of file
diff --git a/doc/guides/contributing/img/what_is_an_abi.svg b/doc/guides/contributing/img/what_is_an_abi.svg
new file mode 100644
index 0000000..fd3d993
--- /dev/null
+++ b/doc/guides/contributing/img/what_is_an_abi.svg
@@ -0,0 +1,382 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="970.69568"
+ height="522.22693"
+ version="1.1"
+ viewBox="0 0 970.69568 522.22693"
+ xml:space="preserve"
+ id="svg8399"
+ sodipodi:docname="what_is_an_abi.svg"
+ inkscape:version="0.92.2 (5c3e80d, 2017-08-06)"><metadata
+ id="metadata8403"><rdf:RDF><cc:Work
+ rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" /></cc:Work></rdf:RDF></metadata><sodipodi:namedview
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1"
+ objecttolerance="10"
+ gridtolerance="10"
+ guidetolerance="10"
+ inkscape:pageopacity="0"
+ inkscape:pageshadow="2"
+ inkscape:window-width="1920"
+ inkscape:window-height="1017"
+ id="namedview8401"
+ showgrid="false"
+ inkscape:zoom="0.62755727"
+ inkscape:cx="820.83951"
+ inkscape:cy="-47.473217"
+ inkscape:window-x="-8"
+ inkscape:window-y="-8"
+ inkscape:window-maximized="1"
+ inkscape:current-layer="svg8399" /><defs
+ id="defs8269"><clipPath
+ id="clipPath26"><path
+ d="M 0,1.2207e-4 H 960 V 540.00012 H 0 Z"
+ id="path8206"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><radialGradient
+ id="radialGradient40"
+ cx="0"
+ cy="0"
+ r="1"
+ gradientTransform="matrix(386.44367,-1.3123672e-5,-1.3123672e-5,-386.44367,470.30824,246.15384)"
+ gradientUnits="userSpaceOnUse"><stop
+ stop-color="#f9d8e2"
+ offset="0"
+ id="stop8209" /><stop
+ stop-color="#fff"
+ offset=".74"
+ id="stop8211" /><stop
+ stop-color="#fff"
+ offset=".83"
+ id="stop8213" /><stop
+ stop-color="#fff"
+ offset="1"
+ id="stop8215" /></radialGradient><clipPath
+ id="clipPath56"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8218"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath68"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8221"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath82"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8224"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath96"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8227"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath108"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8230"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath120"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8233"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath132"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8236"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath144"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8239"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath156"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8242"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath168"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8245"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath180"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8248"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath192"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8251"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath204"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8254"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath216"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8257"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath228"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8260"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath240"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8263"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath><clipPath
+ id="clipPath260"><path
+ d="M 1.4305e-5,0 H 960.00001 V 540 H 1.4305e-5 Z"
+ id="path8266"
+ inkscape:connector-curvature="0"
+ style="clip-rule:evenodd" /></clipPath></defs><path
+ inkscape:connector-curvature="0"
+ style="fill:url(#radialGradient40);fill-rule:evenodd;stroke-width:1.33329999"
+ id="path8275"
+ d="m 116.15709,143.06309 c 0,-28.46596 23.07942,-51.545378 51.54538,-51.545378 h 605.21154 c 28.46595,0 51.54537,23.079418 51.54537,51.545378 V 349.2446 c 0,28.46595 -23.07942,51.54538 -51.54537,51.54538 H 167.70247 c -28.46595,0 -51.54538,-23.07943 -51.54538,-51.54538 z" /><path
+ style="fill:#00b050;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path8277"
+ d="m 478.70803,73.758152 0.58665,373.057338 c 0,1.67996 -1.35997,3.03993 -3.03992,3.03993 -1.67996,0.0133 -3.03993,-1.34663 -3.03993,-3.02659 L 472.62818,73.758152 c 0,-1.67995 1.35997,-3.03992 3.03992,-3.03992 1.67996,0 3.03993,1.35997 3.03993,3.03992 z m 6.65317,370.004088 -9.09311,18.25287 -9.14644,-18.22621 z" /><path
+ style="fill:none;stroke:#7030a0;stroke-width:6.07984781;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path8279"
+ stroke-miterlimit="10"
+ d="m 3.0399239,186.92866 c 0,-36.70575 29.7459201,-66.45167 66.4516701,-66.45167 H 778.00721 c 36.70575,0 66.45167,29.74592 66.45167,66.45167 v 265.80669 c 0,36.70574 -29.74592,66.45167 -66.45167,66.45167 H 69.491594 c -36.70575,0 -66.4516701,-29.74593 -66.4516701,-66.45167 z" /><path
+ style="fill:none;stroke:#3b3059;stroke-width:6.07984781;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path8281"
+ stroke-miterlimit="10"
+ d="m 101.27746,71.464882 c 0,-37.78572 30.63924,-68.4249581 68.42496,-68.4249581 h 729.52846 c 37.7857,0 68.4249,30.6392381 68.4249,68.4249581 V 345.1647 c 0,37.78572 -30.6392,68.42496 -68.4249,68.42496 H 169.70242 c -37.78572,0 -68.42496,-30.63924 -68.42496,-68.42496 z" /><g
+ id="g8287"
+ clip-path="url(#clipPath56)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:32.06399918px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8285"
+ font-size="32.064px"
+ transform="matrix(1,0,0,-1,409.78,93.312)"><tspan
+ id="tspan8283"
+ y="0"
+ x="0 23.855616 42.837505 66.693123">DPDK</tspan></text>
+</g><g
+ id="g8293"
+ clip-path="url(#clipPath68)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:32.06399918px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8291"
+ font-size="32.064px"
+ transform="matrix(1,0,0,-1,358.03,435.43)"><tspan
+ id="tspan8289"
+ y="0"
+ x="0 23.72736 45.595009 67.462654 73.875458 80.160004 100.90541 122.80512 133.54655 139.95937 160.96127">Application</tspan></text>
+</g><path
+ style="fill:#f9d8e2;fill-opacity:0.70196001;fill-rule:evenodd;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path8295"
+ d="M 424.30939,345.59136 H 531.18672 V 277.91305 H 424.30939 Z" /><g
+ id="g8301"
+ clip-path="url(#clipPath82)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:32.04000092px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8299"
+ font-size="32.04px"
+ transform="matrix(1,0,0,-1,432.96,231.41)"><tspan
+ id="tspan8297"
+ y="0"
+ x="0 23.7096 42.67728">API</tspan></text>
+</g><path
+ style="fill:#f9d8e2;fill-opacity:0.70196001;fill-rule:evenodd;stroke-width:1.33329999"
+ inkscape:connector-curvature="0"
+ id="path8303"
+ d="m 422.38944,213.91465 h 107.19732 v -67.8383 H 422.38944 Z" /><g
+ id="g8309"
+ clip-path="url(#clipPath96)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:32.04000092px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8307"
+ font-size="32.04px"
+ transform="matrix(1,0,0,-1,431.54,330.29)"><tspan
+ id="tspan8305"
+ y="0"
+ x="0 23.7096 42.100559">ABI</tspan></text>
+</g><g
+ id="g8315"
+ clip-path="url(#clipPath108)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8313"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,221.78,293.23)"><tspan
+ id="tspan8311"
+ y="0"
+ x="0 9.4483204 14.25228 24.706079 35.447159 40.203239 51.10392 66.106323 81.076797 84.332642 94.068237">Programming</tspan></text>
+</g><g
+ id="g8321"
+ clip-path="url(#clipPath120)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.98400021px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8319"
+ font-size="15.984px"
+ transform="matrix(1,0,0,-1,221.78,274.03)"><tspan
+ id="tspan8317"
+ y="0"
+ x="0 7.320672 18.237743 27.987984 38.633327 48.351601 59.268673 69.945984">Language</tspan></text>
+</g><g
+ id="g8327"
+ clip-path="url(#clipPath132)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8325"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,221.78,254.81)"><tspan
+ id="tspan8323"
+ y="0"
+ x="0 7.6767602 17.38044 27.116039 37.442162 42.708961 45.93288 56.386681 66.122276">Functions</tspan></text>
+</g><g
+ id="g8333"
+ clip-path="url(#clipPath144)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8331"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,221.78,235.61)"><tspan
+ id="tspan8329"
+ y="0"
+ x="0 11.87424 22.77492 28.073641 38.974319 44.273041 52.891441 63.776161 74.150162">Datatypes</tspan></text>
+</g><g
+ id="g8339"
+ clip-path="url(#clipPath156)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8337"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,221.78,216.41)"><tspan
+ id="tspan8335"
+ y="0"
+ x="0 9.6877203 20.06172 25.312559 35.016239 39.820202 49.555801 54.216122 60.823559 69.441963 80.326683 90.700684">Return Types</tspan></text>
+</g><g
+ id="g8345"
+ clip-path="url(#clipPath168)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8343"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,221.78,197.21)"><tspan
+ id="tspan8341"
+ y="0"
+ x="0 12.97548 23.429279 33.164879 39.357361 44.640121 55.540798 65.276398 70.559158">Constants</tspan></text>
+</g><g
+ id="g8351"
+ clip-path="url(#clipPath180)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8349"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,221.78,178.01)"><tspan
+ id="tspan8347"
+ y="0"
+ x="0">…</tspan></text>
+</g><g
+ id="g8357"
+ clip-path="url(#clipPath192)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8355"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,546.38,354.12)"><tspan
+ id="tspan8353"
+ y="0"
+ x="0 3.8304 13.566 19.75848 25.07316 29.877119 39.580799 49.906921 55.189678 58.413601 68.867401 78.602997 83.2314 89.423882 99.797882">Instruction set</tspan></text>
+</g><g
+ id="g8363"
+ clip-path="url(#clipPath204)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.98400021px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8361"
+ font-size="15.984px"
+ transform="matrix(1,0,0,-1,546.38,332.88)"><tspan
+ id="tspan8359"
+ y="0"
+ x="0 8.5674238 16.239744 26.517456 36.859104 46.577377 51.836113 62.753185 73.654274 77.026894 87.352562 91.892014 103.99191 108.33955 115.66022 118.85703 128.60727 136.63123 147.02083">Executable & Linker</tspan></text>
+</g><g
+ id="g8369"
+ clip-path="url(#clipPath216)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8367"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,546.38,313.66)"><tspan
+ id="tspan8365"
+ y="0"
+ x="0 7.6767602 18.13056 22.934521 37.904999 48.805679">Format</tspan></text>
+</g><g
+ id="g8375"
+ clip-path="url(#clipPath228)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8373"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,546.38,292.42)"><tspan
+ id="tspan8371"
+ y="0"
+ x="0 12.97548 23.87616 27.22776 30.579359 33.80328 43.538879 54.200161 58.39764 71.373123 81.82692 91.562523 100.6278 110.95392 120.68952 125.95632 129.18024 139.63403 149.36964 155.56212">Calling Conventions.</tspan></text>
+</g><g
+ id="g8381"
+ clip-path="url(#clipPath240)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8379"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,546.38,271.3)"><tspan
+ id="tspan8377"
+ y="0"
+ x="0">…</tspan></text>
+</g><path
+ style="fill:none;stroke:#ffffff;stroke-width:6.07984781;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:18.239544, 24.319392"
+ inkscape:connector-curvature="0"
+ id="path8383"
+ stroke-miterlimit="10"
+ d="M 122.71693,120.47699 H 782.84709" /><path
+ style="fill:none;stroke:#ffffff;stroke-width:6.07984781;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:18.239544, 24.319392"
+ inkscape:connector-curvature="0"
+ id="path8385"
+ stroke-miterlimit="10"
+ d="M 177.27556,413.58966 H 837.40573" /><g
+ id="g8391"
+ clip-path="url(#clipPath260)"
+ transform="matrix(1.3333,0,0,-1.3333,-143.35642,633.10417)"><text
+ style="font-style:italic;font-size:15.96000004px;font-family:'Century Gothic';fill:#3b3059"
+ id="text8389"
+ font-style="italic"
+ font-size="15.96px"
+ transform="matrix(1,0,0,-1,483.19,405.82)"><tspan
+ id="tspan8387"
+ y="0"
+ x="0 5.0114398 14.71512 24.45072 34.77684 40.299 43.522919 53.976719 63.712318 68.13324 78.459358 89.360039 92.583961 95.807877">function calls</tspan></text>
+</g><path
+ style="fill:none;stroke:#3b3059;stroke-width:0.95997602;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path8393"
+ stroke-miterlimit="10"
+ d="m 574.38564,303.03242 c -11.93304,0 -21.59946,-1.61329 -21.59946,-3.59991 V 164.62255 c 0,-1.98662 -9.66643,-3.59991 -21.59946,-3.59991 11.93303,0 21.59946,-1.61329 21.59946,-3.59991 v -18.30621 c 0,-1.98662 9.66642,-3.59991 21.59946,-3.59991" /><path
+ style="fill:none;stroke:#3b3059;stroke-width:0.95997602;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10"
+ inkscape:connector-curvature="0"
+ id="path8395"
+ stroke-miterlimit="10"
+ d="m 372.63068,389.43026 c 13.293,0 24.0794,-1.79995 24.0794,-4.01323 v -91.53105 c 0,-2.21327 10.78639,-4.01323 24.0794,-4.01323 -13.29301,0 -24.0794,-1.79995 -24.0794,-4.01323 v -65.3717 c 0,-2.21328 -10.7864,-4.01323 -24.0794,-4.01323" /></svg>
\ No newline at end of file
diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing/stable.rst
index 6a5eee9..4d38bb8 100644
--- a/doc/guides/contributing/stable.rst
+++ b/doc/guides/contributing/stable.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: BSD-3-Clause
Copyright 2018 The DPDK contributors
-.. stable_lts_releases:
+.. _stable_lts_releases:
DPDK Stable Releases and Long Term Support
==========================================
@@ -53,6 +53,9 @@ year's November (X.11) release will be maintained as an LTS for 2 years.
After the X.11 release, an LTS branch will be created for it at
http://git.dpdk.org/dpdk-stable where bugfixes will be backported to.
+A LTS release may align with the declaration of a new major ABI version,
+please read the :doc:`abi_policy` for more information.
+
It is anticipated that there will be at least 4 releases per year of the LTS
or approximately 1 every 3 months. However, the cadence can be shorter or
longer depending on the number and criticality of the backported
@@ -119,10 +122,3 @@ A Stable Release will be released by:
list.
Stable releases are available on the `dpdk.org download page <http://core.dpdk.org/download/>`_.
-
-
-ABI
----
-
-The Stable Release should not be seen as a way of breaking or circumventing
-the DPDK ABI policy.
--
2.7.4
^ permalink raw reply [relevance 23%]
* [dpdk-dev] [PATCH v8 4/4] doc: add maintainer for abi policy
2019-11-05 15:24 10% [dpdk-dev] [PATCH v8 0/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
` (2 preceding siblings ...)
2019-11-05 15:24 35% ` [dpdk-dev] [PATCH v8 3/4] doc: updates to versioning guide for " Ray Kinsella
@ 2019-11-05 15:24 13% ` Ray Kinsella
2019-11-06 16:13 4% ` Mcnamara, John
3 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-11-05 15:24 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, john.mcnamara, marko.kovacevic, hemant.agrawal,
ktraynor, aconole
Add an entry to the maintainer file for the abi policy.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
---
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 717c318..d5bb806 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -84,6 +84,10 @@ M: Marko Kovacevic <marko.kovacevic@intel.com>
F: README
F: doc/
+ABI Policy
+M: Ray Kinsella <mdr@ashroe.eu>
+F: doc/guides/contributing/abi_*.rst
+
Developers and Maintainers Tools
M: Thomas Monjalon <thomas@monjalon.net>
F: MAINTAINERS
--
2.7.4
^ permalink raw reply [relevance 13%]
* [dpdk-dev] [PATCH v8 3/4] doc: updates to versioning guide for abi versions
2019-11-05 15:24 10% [dpdk-dev] [PATCH v8 0/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-11-05 15:24 18% ` [dpdk-dev] [PATCH v8 1/4] doc: separate versioning.rst into version and policy Ray Kinsella
2019-11-05 15:24 23% ` [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
@ 2019-11-05 15:24 35% ` Ray Kinsella
2019-11-05 17:37 4% ` Stephen Hemminger
2019-11-06 16:13 4% ` Mcnamara, John
2019-11-05 15:24 13% ` [dpdk-dev] [PATCH v8 4/4] doc: add maintainer for abi policy Ray Kinsella
3 siblings, 2 replies; 200+ results
From: Ray Kinsella @ 2019-11-05 15:24 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, john.mcnamara, marko.kovacevic, hemant.agrawal,
ktraynor, aconole
Updates to the ABI versioning guide, to account for the changes to the DPDK
ABI/API policy. Fixes for references to abi versioning and policy guides.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
---
doc/guides/contributing/abi_policy.rst | 15 +-
doc/guides/contributing/abi_versioning.rst | 250 +++++++++++++++++++----------
doc/guides/contributing/patches.rst | 6 +-
doc/guides/rel_notes/deprecation.rst | 6 +-
4 files changed, 183 insertions(+), 94 deletions(-)
diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst
index f8e11d3..4677f84 100644
--- a/doc/guides/contributing/abi_policy.rst
+++ b/doc/guides/contributing/abi_policy.rst
@@ -16,11 +16,11 @@ General Guidelines
#. Major ABI versions are declared every **year** and are then supported for one
year, typically aligned with the :ref:`LTS release <stable_lts_releases>`.
#. The ABI version is managed at a project level in DPDK, with the ABI version
- reflected in all library's soname.
+ reflected in all :ref:`library's soname <what_is_soname>`.
#. The ABI should be preserved and not changed lightly. ABI changes must follow
the outlined :ref:`deprecation process <abi_changes>`.
#. The addition of symbols is generally not problematic. The modification of
- symbols is managed with ABI Versioning.
+ symbols is managed with :ref:`ABI Versioning <abi_versioning>`.
#. The removal of symbols is considered an :ref:`ABI breakage <abi_breakages>`,
once approved these will form part of the next ABI version.
#. Libraries or APIs marked as :ref:`Experimental <experimental_apis>` are not
@@ -64,13 +64,14 @@ An ABI version is an instance of a library's ABI at a specific release. Certain
releases are considered to be milestone releases, the yearly LTS release for
example. The ABI of a milestone release may be designated as a 'major ABI
version', where this ABI version is then supported for some number of subsequent
-releases and is annotated in the library's soname.
+releases and is annotated in the library's :ref:`soname<what_is_soname>`.
ABI version support in subsequent releases facilitates application upgrades, by
enabling applications built against the milestone release to upgrade to
subsequent releases of a library without a rebuild.
-More details on major ABI version can be found in the ABI Versioning guide.
+More details on major ABI version can be found in the :ref:`ABI versioning
+<major_abi_versions>` guide.
The DPDK ABI policy
-------------------
@@ -141,7 +142,7 @@ The requirements for changing the ABI are:
CPU vendors, end-users, etc.
#. Backward compatibility with the major ABI version must be maintained through
- ABI Versioning, with :ref:`forward-only <forward-only>` compatibility
+ :ref:`abi_versioning`, with :ref:`forward-only <forward-only>` compatibility
offered for any ABI changes that are indicated to be part of the next ABI
version.
@@ -218,7 +219,7 @@ declarations of major ABI versions.
* DPDK 20.02 release defines a new function ``rte_foo(uint8_t bar)``, and
this is not a problem as long as the symbol ``rte_foo@DPDK20`` is
- preserved through ABI Versioning.
+ preserved through :ref:`abi_versioning`.
- The new function may be marked with the ``__rte_experimental`` tag for a
number of releases, as described in the section :ref:`experimental_apis`.
@@ -316,5 +317,5 @@ Libraries
Libraries marked as ``experimental`` are entirely not considered part of an ABI
version, and may change without warning at any time. Experimental libraries
always have a major version of ``0`` to indicate they exist outside of
-ABI Versioning, with the minor version incremented with each ABI change
+:ref:`abi_versioning` , with the minor version incremented with each ABI change
to library.
diff --git a/doc/guides/contributing/abi_versioning.rst b/doc/guides/contributing/abi_versioning.rst
index 1c5612c..a3d5479 100644
--- a/doc/guides/contributing/abi_versioning.rst
+++ b/doc/guides/contributing/abi_versioning.rst
@@ -1,44 +1,134 @@
.. SPDX-License-Identifier: BSD-3-Clause
Copyright 2018 The DPDK contributors
-.. library_versioning:
+.. _abi_versioning:
-Library versioning
+ABI Versioning
+==============
+
+This document details the mechanics of ABI version management in DPDK.
+
+.. _what_is_soname:
+
+What is a library's soname?
+---------------------------
+
+System libraries usually adopt the familiar major and minor version naming
+convention, where major versions (e.g. ``librte_eal 20.x, 21.x``) are presumed
+to be ABI incompatible with each other and minor versions (e.g. ``librte_eal
+20.1, 20.2``) are presumed to be ABI compatible. A library's `soname
+<https://en.wikipedia.org/wiki/Soname>`_. is typically used to provide backward
+compatibility information about a given library, describing the lowest common
+denominator ABI supported by the library. The soname or logical name for the
+library, is typically comprised of the library's name and major version e.g.
+``librte_eal.so.20``.
+
+During an application's build process, a library's soname is noted as a runtime
+dependency of the application. This information is then used by the `dynamic
+linker <https://en.wikipedia.org/wiki/Dynamic_linker>`_ when resolving the
+applications dependencies at runtime, to load a library supporting the correct
+ABI version. The library loaded at runtime therefore, may be a minor revision
+supporting the same major ABI version (e.g. ``librte_eal.20.2``), as the library
+used to link the application (e.g ``librte_eal.20.0``).
+
+.. _major_abi_versions:
+
+Major ABI versions
------------------
-Downstreams might want to provide different DPDK releases at the same time to
-support multiple consumers of DPDK linked against older and newer sonames.
+An ABI version change to a given library, especially in core libraries such as
+``librte_mbuf``, may cause an implicit ripple effect on the ABI of it's
+consuming libraries, causing ABI breakages. There may however be no explicit
+reason to bump a dependent library's ABI version, as there may have been no
+obvious change to the dependent library's API, even though the library's ABI
+compatibility will have been broken.
+
+This interdependence of DPDK libraries, means that ABI versioning of libraries
+is more manageable at a project level, with all project libraries sharing a
+**single ABI version**. In addition, the need to maintain a stable ABI for some
+number of releases as described in the section :doc:`abi_policy`, means
+that ABI version increments need to carefully planned and managed at a project
+level.
+
+Major ABI versions are therefore declared typically aligned with an LTS release
+and is then supported some number of subsequent releases, shared across all
+libraries. This means that a single project level ABI version, reflected in all
+individual library's soname, library filenames and associated version maps
+persists over multiple releases.
+
+.. code-block:: none
+
+ $ head ./lib/librte_acl/rte_acl_version.map
+ DPDK_20 {
+ global:
+ ...
-Also due to the interdependencies that DPDK libraries can have applications
-might end up with an executable space in which multiple versions of a library
-are mapped by ld.so.
+ $ head ./lib/librte_eal/rte_eal_version.map
+ DPDK_20 {
+ global:
+ ...
-Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
-depending on LibA.
+When an ABI change is made between major ABI versions to a given library, a new
+section is added to that library's version map describing the impending new ABI
+version, as described in the section :ref:`example_abi_macro_usage`. The
+library's soname and filename however do not change, e.g. ``libacl.so.20``, as
+ABI compatibility with the last major ABI version continues to be preserved for
+that library.
-.. note::
+.. code-block:: none
- Application
- \-> LibA.old
- \-> LibB.new -> LibA.new
+ $ head ./lib/librte_acl/rte_acl_version.map
+ DPDK_20 {
+ global:
+ ...
-That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
-If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
-library - versions defined in the libraries ``LIBABIVER``.
-An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
-``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
+ DPDK_21 {
+ global:
+
+ } DPDK_20;
+ ...
+ $ head ./lib/librte_eal/rte_eal_version.map
+ DPDK_20 {
+ global:
+ ...
+
+However when a new ABI version is declared, for example DPDK ``21``, old
+depreciated functions may be safely removed at this point and the entire old
+major ABI version removed, see the section :ref:`deprecating_entire_abi` on
+how this may be done.
+
+.. code-block:: none
+
+ $ head ./lib/librte_acl/rte_acl_version.map
+ DPDK_21 {
+ global:
+ ...
+
+ $ head ./lib/librte_eal/rte_eal_version.map
+ DPDK_21 {
+ global:
+ ...
+
+At the same time, the major ABI version is changed atomically across all
+libraries by incrementing the major version in individual library's soname, e.g.
+``libacl.so.21``. This is done by bumping the LIBABIVER number in the libraries
+Makefile to indicate to dynamic linking applications that this is a later, and
+possibly incompatible library version:
+
+.. code-block:: c
+
+ -LIBABIVER := 20
+ +LIBABIVER := 21
-ABI versioning
---------------
Versioning Macros
-~~~~~~~~~~~~~~~~~
+-----------------
When a symbol is exported from a library to provide an API, it also provides a
calling convention (ABI) that is embodied in its name, return type and
arguments. Occasionally that function may need to change to accommodate new
-functionality or behavior. When that occurs, it is desirable to allow for
+functionality or behavior. When that occurs, it is may be required to allow for
backward compatibility for a time with older binaries that are dynamically
linked to the DPDK.
@@ -61,8 +151,10 @@ The macros exported are:
fully qualified function ``p``, so that if a symbol becomes versioned, it
can still be mapped back to the public symbol name.
+.. _example_abi_macro_usage:
+
Examples of ABI Macro use
-^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~
Updating a public API
_____________________
@@ -106,16 +198,16 @@ maintain previous ABI versions that are accessible only to previously compiled
binaries
The addition of a parameter to the function is ABI breaking as the function is
-public, and existing application may use it in its current form. However, the
+public, and existing application may use it in its current form. However, the
compatibility macros in DPDK allow a developer to use symbol versioning so that
multiple functions can be mapped to the same public symbol based on when an
-application was linked to it. To see how this is done, we start with the
-requisite libraries version map file. Initially the version map file for the
-acl library looks like this
+application was linked to it. To see how this is done, we start with the
+requisite libraries version map file. Initially the version map file for the acl
+library looks like this
.. code-block:: none
- DPDK_2.0 {
+ DPDK_20 {
global:
rte_acl_add_rules;
@@ -141,7 +233,7 @@ This file needs to be modified as follows
.. code-block:: none
- DPDK_2.0 {
+ DPDK_20 {
global:
rte_acl_add_rules;
@@ -163,16 +255,16 @@ This file needs to be modified as follows
local: *;
};
- DPDK_2.1 {
+ DPDK_21 {
global:
rte_acl_create;
- } DPDK_2.0;
+ } DPDK_20;
The addition of the new block tells the linker that a new version node is
-available (DPDK_2.1), which contains the symbol rte_acl_create, and inherits the
-symbols from the DPDK_2.0 node. This list is directly translated into a list of
-exported symbols when DPDK is compiled as a shared library
+available (DPDK_21), which contains the symbol rte_acl_create, and inherits
+the symbols from the DPDK_20 node. This list is directly translated into a
+list of exported symbols when DPDK is compiled as a shared library
Next, we need to specify in the code which function map to the rte_acl_create
symbol at which versions. First, at the site of the initial symbol definition,
@@ -191,22 +283,22 @@ with the public symbol name
Note that the base name of the symbol was kept intact, as this is conducive to
the macros used for versioning symbols. That is our next step, mapping this new
-symbol name to the initial symbol name at version node 2.0. Immediately after
+symbol name to the initial symbol name at version node 20. Immediately after
the function, we add this line of code
.. code-block:: c
- VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
+ VERSION_SYMBOL(rte_acl_create, _v20, 20);
-Remembering to also add the rte_function_versioning.h header to the requisite c file where
-these changes are being made. The above macro instructs the linker to create a
-new symbol ``rte_acl_create@DPDK_2.0``, which matches the symbol created in older
-builds, but now points to the above newly named function. We have now mapped
-the original rte_acl_create symbol to the original function (but with a new
-name)
+Remembering to also add the rte_function_versioning.h header to the requisite c
+file where these changes are being made. The above macro instructs the linker to
+create a new symbol ``rte_acl_create@DPDK_20``, which matches the symbol created
+in older builds, but now points to the above newly named function. We have now
+mapped the original rte_acl_create symbol to the original function (but with a
+new name).
-Next, we need to create the 2.1 version of the symbol. We create a new function
-name, with a different suffix, and implement it appropriately
+Next, we need to create the 21 version of the symbol. We create a new function
+name, with a different suffix, and implement it appropriately
.. code-block:: c
@@ -220,12 +312,12 @@ name, with a different suffix, and implement it appropriately
return ctx;
}
-This code serves as our new API call. Its the same as our old call, but adds
-the new parameter in place. Next we need to map this function to the symbol
-``rte_acl_create@DPDK_2.1``. To do this, we modify the public prototype of the call
-in the header file, adding the macro there to inform all including applications,
-that on re-link, the default rte_acl_create symbol should point to this
-function. Note that we could do this by simply naming the function above
+This code serves as our new API call. Its the same as our old call, but adds the
+new parameter in place. Next we need to map this function to the symbol
+``rte_acl_create@DPDK_21``. To do this, we modify the public prototype of the
+call in the header file, adding the macro there to inform all including
+applications, that on re-link, the default rte_acl_create symbol should point to
+this function. Note that we could do this by simply naming the function above
rte_acl_create, and the linker would chose the most recent version tag to apply
in the version script, but we can also do this in the header file
@@ -233,11 +325,11 @@ in the version script, but we can also do this in the header file
struct rte_acl_ctx *
-rte_acl_create(const struct rte_acl_param *param);
- +rte_acl_create(const struct rte_acl_param *param, int debug);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+ +rte_acl_create_v21(const struct rte_acl_param *param, int debug);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
The BIND_DEFAULT_SYMBOL macro explicitly tells applications that include this
-header, to link to the rte_acl_create_v21 function and apply the DPDK_2.1
+header, to link to the rte_acl_create_v21 function and apply the DPDK_21
version node to it. This method is more explicit and flexible than just
re-implementing the exact symbol name, and allows for other features (such as
linking to the old symbol version by default, when the new ABI is to be opt-in
@@ -257,6 +349,7 @@ assumption is that the most recent version of the symbol is the one you want to
map. So, back in the C file where, immediately after ``rte_acl_create_v21`` is
defined, we add this
+
.. code-block:: c
struct rte_acl_ctx *
@@ -270,21 +363,22 @@ That tells the compiler that, when building a static library, any calls to the
symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
That's it, on the next shared library rebuild, there will be two versions of
-rte_acl_create, an old DPDK_2.0 version, used by previously built applications,
-and a new DPDK_2.1 version, used by future built applications.
+rte_acl_create, an old DPDK_20 version, used by previously built applications,
+and a new DPDK_21 version, used by future built applications.
Deprecating part of a public API
________________________________
-Lets assume that you've done the above update, and after a few releases have
-passed you decide you would like to retire the old version of the function.
-After having gone through the ABI deprecation announcement process, removal is
-easy. Start by removing the symbol from the requisite version map file:
+Lets assume that you've done the above update, and in preparation for the next
+major ABI version you decide you would like to retire the old version of the
+function. After having gone through the ABI deprecation announcement process,
+removal is easy. Start by removing the symbol from the requisite version map
+file:
.. code-block:: none
- DPDK_2.0 {
+ DPDK_20 {
global:
rte_acl_add_rules;
@@ -306,48 +400,42 @@ easy. Start by removing the symbol from the requisite version map file:
local: *;
};
- DPDK_2.1 {
+ DPDK_21 {
global:
rte_acl_create;
- } DPDK_2.0;
+ } DPDK_20;
Next remove the corresponding versioned export.
.. code-block:: c
- -VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
+ -VERSION_SYMBOL(rte_acl_create, _v20, 20);
Note that the internal function definition could also be removed, but its used
-in our example by the newer version _v21, so we leave it in place. This is a
-coding style choice.
-
-Lastly, we need to bump the LIBABIVER number for this library in the Makefile to
-indicate to applications doing dynamic linking that this is a later, and
-possibly incompatible library version:
-
-.. code-block:: c
+in our example by the newer version v21, so we leave it in place and declare it
+as static. This is a coding style choice.
- -LIBABIVER := 1
- +LIBABIVER := 2
+.. _deprecating_entire_abi:
Deprecating an entire ABI version
_________________________________
-While removing a symbol from and ABI may be useful, it is often more practical
-to remove an entire version node at once. If a version node completely
-specifies an API, then removing part of it, typically makes it incomplete. In
-those cases it is better to remove the entire node
+While removing a symbol from an ABI may be useful, it is more practical to
+remove an entire version node at once, as is typically done at the declaration
+of a major ABI version. If a version node completely specifies an API, then
+removing part of it, typically makes it incomplete. In those cases it is better
+to remove the entire node.
To do this, start by modifying the version map file, such that all symbols from
-the node to be removed are merged into the next node in the map
+the node to be removed are merged into the next node in the map.
In the case of our map above, it would transform to look as follows
.. code-block:: none
- DPDK_2.1 {
+ DPDK_21 {
global:
rte_acl_add_rules;
@@ -375,8 +463,8 @@ symbols.
.. code-block:: c
- -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 2.0);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+ -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 20);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
Lastly, any VERSION_SYMBOL macros that point to the old version node should be
removed, taking care to keep, where need old code in place to support newer
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index c9ec529..2140303 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -156,9 +156,9 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* For other PMDs and more info, refer to the ``MAINTAINERS`` file.
-* New external functions should be added to the local ``version.map`` file.
- See the :doc:`Guidelines for ABI policy and versioning </contributing/abi_versioning>`.
- New external functions should also be added in alphabetical order.
+* New external functions should be added to the local ``version.map`` file. See
+ the :doc:`ABI policy <abi_policy>` and :ref:`ABI versioning <abi_versioning>`
+ guides. New external functions should also be added in alphabetical order.
* Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``.
See the :ref:`Release Notes section of the Documentation Guidelines <doc_guidelines>` for details.
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index cf37d80..d454915 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -4,9 +4,9 @@
ABI and API Deprecation
=======================
-See the :doc:`guidelines document for details of the ABI policy </contributing/abi_versioning>`.
-API and ABI deprecation notices are to be posted here.
-
+See the guidelines document for details of the :doc:`ABI policy
+<../contributing/abi_policy>`. API and ABI deprecation notices are to be posted
+here.
Deprecation Notices
-------------------
--
2.7.4
^ permalink raw reply [relevance 35%]
* [dpdk-dev] [PATCH v8 1/4] doc: separate versioning.rst into version and policy
2019-11-05 15:24 10% [dpdk-dev] [PATCH v8 0/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
@ 2019-11-05 15:24 18% ` Ray Kinsella
2019-11-05 17:37 0% ` Stephen Hemminger
2019-11-06 16:11 0% ` Mcnamara, John
2019-11-05 15:24 23% ` [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
` (2 subsequent siblings)
3 siblings, 2 replies; 200+ results
From: Ray Kinsella @ 2019-11-05 15:24 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, john.mcnamara, marko.kovacevic, hemant.agrawal,
ktraynor, aconole
Separate versioning.rst into abi versioning and abi policy guidance, in
preparation for adding more detail to the abi policy.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
---
doc/guides/contributing/abi_policy.rst | 167 ++++++++
doc/guides/contributing/abi_versioning.rst | 427 +++++++++++++++++++++
doc/guides/contributing/index.rst | 3 +-
doc/guides/contributing/patches.rst | 2 +-
doc/guides/contributing/versioning.rst | 591 -----------------------------
doc/guides/rel_notes/deprecation.rst | 2 +-
6 files changed, 598 insertions(+), 594 deletions(-)
create mode 100644 doc/guides/contributing/abi_policy.rst
create mode 100644 doc/guides/contributing/abi_versioning.rst
delete mode 100644 doc/guides/contributing/versioning.rst
diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst
new file mode 100644
index 0000000..d4f4e9f
--- /dev/null
+++ b/doc/guides/contributing/abi_policy.rst
@@ -0,0 +1,167 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2018 The DPDK contributors
+
+DPDK ABI/API policy
+===================
+
+Description
+-----------
+
+This document details some methods for handling ABI management in the DPDK.
+
+General Guidelines
+------------------
+
+#. Whenever possible, ABI should be preserved
+#. ABI/API may be changed with a deprecation process
+#. The modification of symbols can generally be managed with versioning
+#. Libraries or APIs marked in ``experimental`` state may change without constraint
+#. New APIs will be marked as ``experimental`` for at least one release to allow
+ any issues found by users of the new API to be fixed quickly
+#. The addition of symbols is generally not problematic
+#. The removal of symbols generally is an ABI break and requires bumping of the
+ LIBABIVER macro
+#. Updates to the minimum hardware requirements, which drop support for hardware which
+ was previously supported, should be treated as an ABI change.
+
+What is an ABI
+~~~~~~~~~~~~~~
+
+An ABI (Application Binary Interface) is the set of runtime interfaces exposed
+by a library. It is similar to an API (Application Programming Interface) but
+is the result of compilation. It is also effectively cloned when applications
+link to dynamic libraries. That is to say when an application is compiled to
+link against dynamic libraries, it is assumed that the ABI remains constant
+between the time the application is compiled/linked, and the time that it runs.
+Therefore, in the case of dynamic linking, it is critical that an ABI is
+preserved, or (when modified), done in such a way that the application is unable
+to behave improperly or in an unexpected fashion.
+
+
+ABI/API Deprecation
+-------------------
+
+The DPDK ABI policy
+~~~~~~~~~~~~~~~~~~~
+
+ABI versions are set at the time of major release labeling, and the ABI may
+change multiple times, without warning, between the last release label and the
+HEAD label of the git tree.
+
+ABI versions, once released, are available until such time as their
+deprecation has been noted in the Release Notes for at least one major release
+cycle. For example consider the case where the ABI for DPDK 2.0 has been
+shipped and then a decision is made to modify it during the development of
+DPDK 2.1. The decision will be recorded in the Release Notes for the DPDK 2.1
+release and the modification will be made available in the DPDK 2.2 release.
+
+ABI versions may be deprecated in whole or in part as needed by a given
+update.
+
+Some ABI changes may be too significant to reasonably maintain multiple
+versions. In those cases ABI's may be updated without backward compatibility
+being provided. The requirements for doing so are:
+
+#. At least 3 acknowledgments of the need to do so must be made on the
+ dpdk.org mailing list.
+
+ - The acknowledgment of the maintainer of the component is mandatory, or if
+ no maintainer is available for the component, the tree/sub-tree maintainer
+ for that component must acknowledge the ABI change instead.
+
+ - It is also recommended that acknowledgments from different "areas of
+ interest" be sought for each deprecation, for example: from NIC vendors,
+ CPU vendors, end-users, etc.
+
+#. The changes (including an alternative map file) can be included with
+ deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option,
+ to provide more details about oncoming changes.
+ ``RTE_NEXT_ABI`` wrapper will be removed when it become the default ABI.
+ More preferred way to provide this information is sending the feature
+ as a separate patch and reference it in deprecation notice.
+
+#. A full deprecation cycle, as explained above, must be made to offer
+ downstream consumers sufficient warning of the change.
+
+Note that the above process for ABI deprecation should not be undertaken
+lightly. ABI stability is extremely important for downstream consumers of the
+DPDK, especially when distributed in shared object form. Every effort should
+be made to preserve the ABI whenever possible. The ABI should only be changed
+for significant reasons, such as performance enhancements. ABI breakage due to
+changes such as reorganizing public structure fields for aesthetic or
+readability purposes should be avoided.
+
+.. note::
+
+ Updates to the minimum hardware requirements, which drop support for hardware
+ which was previously supported, should be treated as an ABI change, and
+ follow the relevant deprecation policy procedures as above: 3 acks and
+ announcement at least one release in advance.
+
+Examples of Deprecation Notices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following are some examples of ABI deprecation notices which would be
+added to the Release Notes:
+
+* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
+ to be replaced with the inline function ``rte_foo()``.
+
+* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
+ in version 2.0. Backwards compatibility will be maintained for this function
+ until the release of version 2.1
+
+* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
+ performance reasons. Existing binary applications will have backwards
+ compatibility in release 2.0, while newly built binaries will need to
+ reference the new structure variant ``struct rte_foo2``. Compatibility will
+ be removed in release 2.2, and all applications will require updating and
+ rebuilding to the new structure at that time, which will be renamed to the
+ original ``struct rte_foo``.
+
+* Significant ABI changes are planned for the ``librte_dostuff`` library. The
+ upcoming release 2.0 will not contain these changes, but release 2.1 will,
+ and no backwards compatibility is planned due to the extensive nature of
+ these changes. Binaries using this library built prior to version 2.1 will
+ require updating and recompilation.
+
+New API replacing previous one
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If a new API proposed functionally replaces an existing one, when the new API
+becomes non-experimental then the old one is marked with ``__rte_deprecated``.
+Deprecated APIs are removed completely just after the next LTS.
+
+Reminder that old API should follow deprecation process to be removed.
+
+
+Experimental APIs
+-----------------
+
+APIs marked as ``experimental`` are not considered part of the ABI and may
+change without warning at any time. Since changes to APIs are most likely
+immediately after their introduction, as users begin to take advantage of
+those new APIs and start finding issues with them, new DPDK APIs will be
+automatically marked as ``experimental`` to allow for a period of stabilization
+before they become part of a tracked ABI.
+
+Note that marking an API as experimental is a multi step process.
+To mark an API as experimental, the symbols which are desired to be exported
+must be placed in an EXPERIMENTAL version block in the corresponding libraries'
+version map script.
+Secondly, the corresponding prototypes of those exported functions (in the
+development header files), must be marked with the ``__rte_experimental`` tag
+(see ``rte_compat.h``).
+The DPDK build makefiles perform a check to ensure that the map file and the
+C code reflect the same list of symbols.
+This check can be circumvented by defining ``ALLOW_EXPERIMENTAL_API``
+during compilation in the corresponding library Makefile.
+
+In addition to tagging the code with ``__rte_experimental``,
+the doxygen markup must also contain the EXPERIMENTAL string,
+and the MAINTAINERS file should note the EXPERIMENTAL libraries.
+
+For removing the experimental tag associated with an API, deprecation notice
+is not required. Though, an API should remain in experimental state for at least
+one release. Thereafter, normal process of posting patch for review to mailing
+list can be followed.
diff --git a/doc/guides/contributing/abi_versioning.rst b/doc/guides/contributing/abi_versioning.rst
new file mode 100644
index 0000000..1c5612c
--- /dev/null
+++ b/doc/guides/contributing/abi_versioning.rst
@@ -0,0 +1,427 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2018 The DPDK contributors
+
+.. library_versioning:
+
+Library versioning
+------------------
+
+Downstreams might want to provide different DPDK releases at the same time to
+support multiple consumers of DPDK linked against older and newer sonames.
+
+Also due to the interdependencies that DPDK libraries can have applications
+might end up with an executable space in which multiple versions of a library
+are mapped by ld.so.
+
+Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
+depending on LibA.
+
+.. note::
+
+ Application
+ \-> LibA.old
+ \-> LibB.new -> LibA.new
+
+That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
+If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
+library - versions defined in the libraries ``LIBABIVER``.
+An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
+``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
+
+
+ABI versioning
+--------------
+
+Versioning Macros
+~~~~~~~~~~~~~~~~~
+
+When a symbol is exported from a library to provide an API, it also provides a
+calling convention (ABI) that is embodied in its name, return type and
+arguments. Occasionally that function may need to change to accommodate new
+functionality or behavior. When that occurs, it is desirable to allow for
+backward compatibility for a time with older binaries that are dynamically
+linked to the DPDK.
+
+To support backward compatibility the ``rte_function_versioning.h``
+header file provides macros to use when updating exported functions. These
+macros are used in conjunction with the ``rte_<library>_version.map`` file for
+a given library to allow multiple versions of a symbol to exist in a shared
+library so that older binaries need not be immediately recompiled.
+
+The macros exported are:
+
+* ``VERSION_SYMBOL(b, e, n)``: Creates a symbol version table entry binding
+ versioned symbol ``b@DPDK_n`` to the internal function ``b_e``.
+
+* ``BIND_DEFAULT_SYMBOL(b, e, n)``: Creates a symbol version entry instructing
+ the linker to bind references to symbol ``b`` to the internal symbol
+ ``b_e``.
+
+* ``MAP_STATIC_SYMBOL(f, p)``: Declare the prototype ``f``, and map it to the
+ fully qualified function ``p``, so that if a symbol becomes versioned, it
+ can still be mapped back to the public symbol name.
+
+Examples of ABI Macro use
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Updating a public API
+_____________________
+
+Assume we have a function as follows
+
+.. code-block:: c
+
+ /*
+ * Create an acl context object for apps to
+ * manipulate
+ */
+ struct rte_acl_ctx *
+ rte_acl_create(const struct rte_acl_param *param)
+ {
+ ...
+ }
+
+
+Assume that struct rte_acl_ctx is a private structure, and that a developer
+wishes to enhance the acl api so that a debugging flag can be enabled on a
+per-context basis. This requires an addition to the structure (which, being
+private, is safe), but it also requires modifying the code as follows
+
+.. code-block:: c
+
+ /*
+ * Create an acl context object for apps to
+ * manipulate
+ */
+ struct rte_acl_ctx *
+ rte_acl_create(const struct rte_acl_param *param, int debug)
+ {
+ ...
+ }
+
+
+Note also that, being a public function, the header file prototype must also be
+changed, as must all the call sites, to reflect the new ABI footprint. We will
+maintain previous ABI versions that are accessible only to previously compiled
+binaries
+
+The addition of a parameter to the function is ABI breaking as the function is
+public, and existing application may use it in its current form. However, the
+compatibility macros in DPDK allow a developer to use symbol versioning so that
+multiple functions can be mapped to the same public symbol based on when an
+application was linked to it. To see how this is done, we start with the
+requisite libraries version map file. Initially the version map file for the
+acl library looks like this
+
+.. code-block:: none
+
+ DPDK_2.0 {
+ global:
+
+ rte_acl_add_rules;
+ rte_acl_build;
+ rte_acl_classify;
+ rte_acl_classify_alg;
+ rte_acl_classify_scalar;
+ rte_acl_create;
+ rte_acl_dump;
+ rte_acl_find_existing;
+ rte_acl_free;
+ rte_acl_ipv4vlan_add_rules;
+ rte_acl_ipv4vlan_build;
+ rte_acl_list_dump;
+ rte_acl_reset;
+ rte_acl_reset_rules;
+ rte_acl_set_ctx_classify;
+
+ local: *;
+ };
+
+This file needs to be modified as follows
+
+.. code-block:: none
+
+ DPDK_2.0 {
+ global:
+
+ rte_acl_add_rules;
+ rte_acl_build;
+ rte_acl_classify;
+ rte_acl_classify_alg;
+ rte_acl_classify_scalar;
+ rte_acl_create;
+ rte_acl_dump;
+ rte_acl_find_existing;
+ rte_acl_free;
+ rte_acl_ipv4vlan_add_rules;
+ rte_acl_ipv4vlan_build;
+ rte_acl_list_dump;
+ rte_acl_reset;
+ rte_acl_reset_rules;
+ rte_acl_set_ctx_classify;
+
+ local: *;
+ };
+
+ DPDK_2.1 {
+ global:
+ rte_acl_create;
+
+ } DPDK_2.0;
+
+The addition of the new block tells the linker that a new version node is
+available (DPDK_2.1), which contains the symbol rte_acl_create, and inherits the
+symbols from the DPDK_2.0 node. This list is directly translated into a list of
+exported symbols when DPDK is compiled as a shared library
+
+Next, we need to specify in the code which function map to the rte_acl_create
+symbol at which versions. First, at the site of the initial symbol definition,
+we need to update the function so that it is uniquely named, and not in conflict
+with the public symbol name
+
+.. code-block:: c
+
+ struct rte_acl_ctx *
+ -rte_acl_create(const struct rte_acl_param *param)
+ +rte_acl_create_v20(const struct rte_acl_param *param)
+ {
+ size_t sz;
+ struct rte_acl_ctx *ctx;
+ ...
+
+Note that the base name of the symbol was kept intact, as this is conducive to
+the macros used for versioning symbols. That is our next step, mapping this new
+symbol name to the initial symbol name at version node 2.0. Immediately after
+the function, we add this line of code
+
+.. code-block:: c
+
+ VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
+
+Remembering to also add the rte_function_versioning.h header to the requisite c file where
+these changes are being made. The above macro instructs the linker to create a
+new symbol ``rte_acl_create@DPDK_2.0``, which matches the symbol created in older
+builds, but now points to the above newly named function. We have now mapped
+the original rte_acl_create symbol to the original function (but with a new
+name)
+
+Next, we need to create the 2.1 version of the symbol. We create a new function
+name, with a different suffix, and implement it appropriately
+
+.. code-block:: c
+
+ struct rte_acl_ctx *
+ rte_acl_create_v21(const struct rte_acl_param *param, int debug);
+ {
+ struct rte_acl_ctx *ctx = rte_acl_create_v20(param);
+
+ ctx->debug = debug;
+
+ return ctx;
+ }
+
+This code serves as our new API call. Its the same as our old call, but adds
+the new parameter in place. Next we need to map this function to the symbol
+``rte_acl_create@DPDK_2.1``. To do this, we modify the public prototype of the call
+in the header file, adding the macro there to inform all including applications,
+that on re-link, the default rte_acl_create symbol should point to this
+function. Note that we could do this by simply naming the function above
+rte_acl_create, and the linker would chose the most recent version tag to apply
+in the version script, but we can also do this in the header file
+
+.. code-block:: c
+
+ struct rte_acl_ctx *
+ -rte_acl_create(const struct rte_acl_param *param);
+ +rte_acl_create(const struct rte_acl_param *param, int debug);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+
+The BIND_DEFAULT_SYMBOL macro explicitly tells applications that include this
+header, to link to the rte_acl_create_v21 function and apply the DPDK_2.1
+version node to it. This method is more explicit and flexible than just
+re-implementing the exact symbol name, and allows for other features (such as
+linking to the old symbol version by default, when the new ABI is to be opt-in
+for a period.
+
+One last thing we need to do. Note that we've taken what was a public symbol,
+and duplicated it into two uniquely and differently named symbols. We've then
+mapped each of those back to the public symbol ``rte_acl_create`` with different
+version tags. This only applies to dynamic linking, as static linking has no
+notion of versioning. That leaves this code in a position of no longer having a
+symbol simply named ``rte_acl_create`` and a static build will fail on that
+missing symbol.
+
+To correct this, we can simply map a function of our choosing back to the public
+symbol in the static build with the ``MAP_STATIC_SYMBOL`` macro. Generally the
+assumption is that the most recent version of the symbol is the one you want to
+map. So, back in the C file where, immediately after ``rte_acl_create_v21`` is
+defined, we add this
+
+.. code-block:: c
+
+ struct rte_acl_ctx *
+ rte_acl_create_v21(const struct rte_acl_param *param, int debug)
+ {
+ ...
+ }
+ MAP_STATIC_SYMBOL(struct rte_acl_ctx *rte_acl_create(const struct rte_acl_param *param, int debug), rte_acl_create_v21);
+
+That tells the compiler that, when building a static library, any calls to the
+symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
+
+That's it, on the next shared library rebuild, there will be two versions of
+rte_acl_create, an old DPDK_2.0 version, used by previously built applications,
+and a new DPDK_2.1 version, used by future built applications.
+
+
+Deprecating part of a public API
+________________________________
+
+Lets assume that you've done the above update, and after a few releases have
+passed you decide you would like to retire the old version of the function.
+After having gone through the ABI deprecation announcement process, removal is
+easy. Start by removing the symbol from the requisite version map file:
+
+.. code-block:: none
+
+ DPDK_2.0 {
+ global:
+
+ rte_acl_add_rules;
+ rte_acl_build;
+ rte_acl_classify;
+ rte_acl_classify_alg;
+ rte_acl_classify_scalar;
+ rte_acl_dump;
+ - rte_acl_create
+ rte_acl_find_existing;
+ rte_acl_free;
+ rte_acl_ipv4vlan_add_rules;
+ rte_acl_ipv4vlan_build;
+ rte_acl_list_dump;
+ rte_acl_reset;
+ rte_acl_reset_rules;
+ rte_acl_set_ctx_classify;
+
+ local: *;
+ };
+
+ DPDK_2.1 {
+ global:
+ rte_acl_create;
+ } DPDK_2.0;
+
+
+Next remove the corresponding versioned export.
+
+.. code-block:: c
+
+ -VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
+
+
+Note that the internal function definition could also be removed, but its used
+in our example by the newer version _v21, so we leave it in place. This is a
+coding style choice.
+
+Lastly, we need to bump the LIBABIVER number for this library in the Makefile to
+indicate to applications doing dynamic linking that this is a later, and
+possibly incompatible library version:
+
+.. code-block:: c
+
+ -LIBABIVER := 1
+ +LIBABIVER := 2
+
+Deprecating an entire ABI version
+_________________________________
+
+While removing a symbol from and ABI may be useful, it is often more practical
+to remove an entire version node at once. If a version node completely
+specifies an API, then removing part of it, typically makes it incomplete. In
+those cases it is better to remove the entire node
+
+To do this, start by modifying the version map file, such that all symbols from
+the node to be removed are merged into the next node in the map
+
+In the case of our map above, it would transform to look as follows
+
+.. code-block:: none
+
+ DPDK_2.1 {
+ global:
+
+ rte_acl_add_rules;
+ rte_acl_build;
+ rte_acl_classify;
+ rte_acl_classify_alg;
+ rte_acl_classify_scalar;
+ rte_acl_dump;
+ rte_acl_create
+ rte_acl_find_existing;
+ rte_acl_free;
+ rte_acl_ipv4vlan_add_rules;
+ rte_acl_ipv4vlan_build;
+ rte_acl_list_dump;
+ rte_acl_reset;
+ rte_acl_reset_rules;
+ rte_acl_set_ctx_classify;
+
+ local: *;
+ };
+
+Then any uses of BIND_DEFAULT_SYMBOL that pointed to the old node should be
+updated to point to the new version node in any header files for all affected
+symbols.
+
+.. code-block:: c
+
+ -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 2.0);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+
+Lastly, any VERSION_SYMBOL macros that point to the old version node should be
+removed, taking care to keep, where need old code in place to support newer
+versions of the symbol.
+
+
+Running the ABI Validator
+-------------------------
+
+The ``devtools`` directory in the DPDK source tree contains a utility program,
+``validate-abi.sh``, for validating the DPDK ABI based on the Linux `ABI
+Compliance Checker
+<http://ispras.linuxbase.org/index.php/ABI_compliance_checker>`_.
+
+This has a dependency on the ``abi-compliance-checker`` and ``and abi-dumper``
+utilities which can be installed via a package manager. For example::
+
+ sudo yum install abi-compliance-checker
+ sudo yum install abi-dumper
+
+The syntax of the ``validate-abi.sh`` utility is::
+
+ ./devtools/validate-abi.sh <REV1> <REV2>
+
+Where ``REV1`` and ``REV2`` are valid gitrevisions(7)
+https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
+on the local repo.
+
+For example::
+
+ # Check between the previous and latest commit:
+ ./devtools/validate-abi.sh HEAD~1 HEAD
+
+ # Check on a specific compilation target:
+ ./devtools/validate-abi.sh -t x86_64-native-linux-gcc HEAD~1 HEAD
+
+ # Check between two tags:
+ ./devtools/validate-abi.sh v2.0.0 v2.1.0
+
+ # Check between git master and local topic-branch "vhost-hacking":
+ ./devtools/validate-abi.sh master vhost-hacking
+
+After the validation script completes (it can take a while since it need to
+compile both tags) it will create compatibility reports in the
+``./abi-check/compat_report`` directory. Listed incompatibilities can be found
+as follows::
+
+ grep -lr Incompatible abi-check/compat_reports/
diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
index e2608d3..2fefd91 100644
--- a/doc/guides/contributing/index.rst
+++ b/doc/guides/contributing/index.rst
@@ -10,7 +10,8 @@ Contributor's Guidelines
coding_style
design
- versioning
+ abi_policy
+ abi_versioning
documentation
patches
vulnerability
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 9e1013b..c9ec529 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -157,7 +157,7 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* For other PMDs and more info, refer to the ``MAINTAINERS`` file.
* New external functions should be added to the local ``version.map`` file.
- See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
+ See the :doc:`Guidelines for ABI policy and versioning </contributing/abi_versioning>`.
New external functions should also be added in alphabetical order.
* Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``.
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
deleted file mode 100644
index 64984c5..0000000
--- a/doc/guides/contributing/versioning.rst
+++ /dev/null
@@ -1,591 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
- Copyright 2018 The DPDK contributors
-
-DPDK ABI/API policy
-===================
-
-Description
------------
-
-This document details some methods for handling ABI management in the DPDK.
-
-General Guidelines
-------------------
-
-#. Whenever possible, ABI should be preserved
-#. ABI/API may be changed with a deprecation process
-#. The modification of symbols can generally be managed with versioning
-#. Libraries or APIs marked in ``experimental`` state may change without constraint
-#. New APIs will be marked as ``experimental`` for at least one release to allow
- any issues found by users of the new API to be fixed quickly
-#. The addition of symbols is generally not problematic
-#. The removal of symbols generally is an ABI break and requires bumping of the
- LIBABIVER macro
-#. Updates to the minimum hardware requirements, which drop support for hardware which
- was previously supported, should be treated as an ABI change.
-
-What is an ABI
-~~~~~~~~~~~~~~
-
-An ABI (Application Binary Interface) is the set of runtime interfaces exposed
-by a library. It is similar to an API (Application Programming Interface) but
-is the result of compilation. It is also effectively cloned when applications
-link to dynamic libraries. That is to say when an application is compiled to
-link against dynamic libraries, it is assumed that the ABI remains constant
-between the time the application is compiled/linked, and the time that it runs.
-Therefore, in the case of dynamic linking, it is critical that an ABI is
-preserved, or (when modified), done in such a way that the application is unable
-to behave improperly or in an unexpected fashion.
-
-
-ABI/API Deprecation
--------------------
-
-The DPDK ABI policy
-~~~~~~~~~~~~~~~~~~~
-
-ABI versions are set at the time of major release labeling, and the ABI may
-change multiple times, without warning, between the last release label and the
-HEAD label of the git tree.
-
-ABI versions, once released, are available until such time as their
-deprecation has been noted in the Release Notes for at least one major release
-cycle. For example consider the case where the ABI for DPDK 2.0 has been
-shipped and then a decision is made to modify it during the development of
-DPDK 2.1. The decision will be recorded in the Release Notes for the DPDK 2.1
-release and the modification will be made available in the DPDK 2.2 release.
-
-ABI versions may be deprecated in whole or in part as needed by a given
-update.
-
-Some ABI changes may be too significant to reasonably maintain multiple
-versions. In those cases ABI's may be updated without backward compatibility
-being provided. The requirements for doing so are:
-
-#. At least 3 acknowledgments of the need to do so must be made on the
- dpdk.org mailing list.
-
- - The acknowledgment of the maintainer of the component is mandatory, or if
- no maintainer is available for the component, the tree/sub-tree maintainer
- for that component must acknowledge the ABI change instead.
-
- - It is also recommended that acknowledgments from different "areas of
- interest" be sought for each deprecation, for example: from NIC vendors,
- CPU vendors, end-users, etc.
-
-#. The changes (including an alternative map file) can be included with
- deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option,
- to provide more details about oncoming changes.
- ``RTE_NEXT_ABI`` wrapper will be removed when it become the default ABI.
- More preferred way to provide this information is sending the feature
- as a separate patch and reference it in deprecation notice.
-
-#. A full deprecation cycle, as explained above, must be made to offer
- downstream consumers sufficient warning of the change.
-
-Note that the above process for ABI deprecation should not be undertaken
-lightly. ABI stability is extremely important for downstream consumers of the
-DPDK, especially when distributed in shared object form. Every effort should
-be made to preserve the ABI whenever possible. The ABI should only be changed
-for significant reasons, such as performance enhancements. ABI breakage due to
-changes such as reorganizing public structure fields for aesthetic or
-readability purposes should be avoided.
-
-.. note::
-
- Updates to the minimum hardware requirements, which drop support for hardware
- which was previously supported, should be treated as an ABI change, and
- follow the relevant deprecation policy procedures as above: 3 acks and
- announcement at least one release in advance.
-
-Examples of Deprecation Notices
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The following are some examples of ABI deprecation notices which would be
-added to the Release Notes:
-
-* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
- to be replaced with the inline function ``rte_foo()``.
-
-* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
- in version 2.0. Backwards compatibility will be maintained for this function
- until the release of version 2.1
-
-* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
- performance reasons. Existing binary applications will have backwards
- compatibility in release 2.0, while newly built binaries will need to
- reference the new structure variant ``struct rte_foo2``. Compatibility will
- be removed in release 2.2, and all applications will require updating and
- rebuilding to the new structure at that time, which will be renamed to the
- original ``struct rte_foo``.
-
-* Significant ABI changes are planned for the ``librte_dostuff`` library. The
- upcoming release 2.0 will not contain these changes, but release 2.1 will,
- and no backwards compatibility is planned due to the extensive nature of
- these changes. Binaries using this library built prior to version 2.1 will
- require updating and recompilation.
-
-New API replacing previous one
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If a new API proposed functionally replaces an existing one, when the new API
-becomes non-experimental then the old one is marked with ``__rte_deprecated``.
-Deprecated APIs are removed completely just after the next LTS.
-
-Reminder that old API should follow deprecation process to be removed.
-
-
-Experimental APIs
------------------
-
-APIs marked as ``experimental`` are not considered part of the ABI and may
-change without warning at any time. Since changes to APIs are most likely
-immediately after their introduction, as users begin to take advantage of
-those new APIs and start finding issues with them, new DPDK APIs will be
-automatically marked as ``experimental`` to allow for a period of stabilization
-before they become part of a tracked ABI.
-
-Note that marking an API as experimental is a multi step process.
-To mark an API as experimental, the symbols which are desired to be exported
-must be placed in an EXPERIMENTAL version block in the corresponding libraries'
-version map script.
-Secondly, the corresponding prototypes of those exported functions (in the
-development header files), must be marked with the ``__rte_experimental`` tag
-(see ``rte_compat.h``).
-The DPDK build makefiles perform a check to ensure that the map file and the
-C code reflect the same list of symbols.
-This check can be circumvented by defining ``ALLOW_EXPERIMENTAL_API``
-during compilation in the corresponding library Makefile.
-
-In addition to tagging the code with ``__rte_experimental``,
-the doxygen markup must also contain the EXPERIMENTAL string,
-and the MAINTAINERS file should note the EXPERIMENTAL libraries.
-
-For removing the experimental tag associated with an API, deprecation notice
-is not required. Though, an API should remain in experimental state for at least
-one release. Thereafter, normal process of posting patch for review to mailing
-list can be followed.
-
-
-Library versioning
-------------------
-
-Downstreams might want to provide different DPDK releases at the same time to
-support multiple consumers of DPDK linked against older and newer sonames.
-
-Also due to the interdependencies that DPDK libraries can have applications
-might end up with an executable space in which multiple versions of a library
-are mapped by ld.so.
-
-Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
-depending on LibA.
-
-.. note::
-
- Application
- \-> LibA.old
- \-> LibB.new -> LibA.new
-
-That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
-If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
-library - versions defined in the libraries ``LIBABIVER``.
-An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
-``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
-
-
-ABI versioning
---------------
-
-Versioning Macros
-~~~~~~~~~~~~~~~~~
-
-When a symbol is exported from a library to provide an API, it also provides a
-calling convention (ABI) that is embodied in its name, return type and
-arguments. Occasionally that function may need to change to accommodate new
-functionality or behavior. When that occurs, it is desirable to allow for
-backward compatibility for a time with older binaries that are dynamically
-linked to the DPDK.
-
-To support backward compatibility the ``rte_function_versioning.h``
-header file provides macros to use when updating exported functions. These
-macros are used in conjunction with the ``rte_<library>_version.map`` file for
-a given library to allow multiple versions of a symbol to exist in a shared
-library so that older binaries need not be immediately recompiled.
-
-The macros exported are:
-
-* ``VERSION_SYMBOL(b, e, n)``: Creates a symbol version table entry binding
- versioned symbol ``b@DPDK_n`` to the internal function ``b_e``.
-
-* ``BIND_DEFAULT_SYMBOL(b, e, n)``: Creates a symbol version entry instructing
- the linker to bind references to symbol ``b`` to the internal symbol
- ``b_e``.
-
-* ``MAP_STATIC_SYMBOL(f, p)``: Declare the prototype ``f``, and map it to the
- fully qualified function ``p``, so that if a symbol becomes versioned, it
- can still be mapped back to the public symbol name.
-
-Examples of ABI Macro use
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Updating a public API
-_____________________
-
-Assume we have a function as follows
-
-.. code-block:: c
-
- /*
- * Create an acl context object for apps to
- * manipulate
- */
- struct rte_acl_ctx *
- rte_acl_create(const struct rte_acl_param *param)
- {
- ...
- }
-
-
-Assume that struct rte_acl_ctx is a private structure, and that a developer
-wishes to enhance the acl api so that a debugging flag can be enabled on a
-per-context basis. This requires an addition to the structure (which, being
-private, is safe), but it also requires modifying the code as follows
-
-.. code-block:: c
-
- /*
- * Create an acl context object for apps to
- * manipulate
- */
- struct rte_acl_ctx *
- rte_acl_create(const struct rte_acl_param *param, int debug)
- {
- ...
- }
-
-
-Note also that, being a public function, the header file prototype must also be
-changed, as must all the call sites, to reflect the new ABI footprint. We will
-maintain previous ABI versions that are accessible only to previously compiled
-binaries
-
-The addition of a parameter to the function is ABI breaking as the function is
-public, and existing application may use it in its current form. However, the
-compatibility macros in DPDK allow a developer to use symbol versioning so that
-multiple functions can be mapped to the same public symbol based on when an
-application was linked to it. To see how this is done, we start with the
-requisite libraries version map file. Initially the version map file for the
-acl library looks like this
-
-.. code-block:: none
-
- DPDK_2.0 {
- global:
-
- rte_acl_add_rules;
- rte_acl_build;
- rte_acl_classify;
- rte_acl_classify_alg;
- rte_acl_classify_scalar;
- rte_acl_create;
- rte_acl_dump;
- rte_acl_find_existing;
- rte_acl_free;
- rte_acl_ipv4vlan_add_rules;
- rte_acl_ipv4vlan_build;
- rte_acl_list_dump;
- rte_acl_reset;
- rte_acl_reset_rules;
- rte_acl_set_ctx_classify;
-
- local: *;
- };
-
-This file needs to be modified as follows
-
-.. code-block:: none
-
- DPDK_2.0 {
- global:
-
- rte_acl_add_rules;
- rte_acl_build;
- rte_acl_classify;
- rte_acl_classify_alg;
- rte_acl_classify_scalar;
- rte_acl_create;
- rte_acl_dump;
- rte_acl_find_existing;
- rte_acl_free;
- rte_acl_ipv4vlan_add_rules;
- rte_acl_ipv4vlan_build;
- rte_acl_list_dump;
- rte_acl_reset;
- rte_acl_reset_rules;
- rte_acl_set_ctx_classify;
-
- local: *;
- };
-
- DPDK_2.1 {
- global:
- rte_acl_create;
-
- } DPDK_2.0;
-
-The addition of the new block tells the linker that a new version node is
-available (DPDK_2.1), which contains the symbol rte_acl_create, and inherits the
-symbols from the DPDK_2.0 node. This list is directly translated into a list of
-exported symbols when DPDK is compiled as a shared library
-
-Next, we need to specify in the code which function map to the rte_acl_create
-symbol at which versions. First, at the site of the initial symbol definition,
-we need to update the function so that it is uniquely named, and not in conflict
-with the public symbol name
-
-.. code-block:: c
-
- struct rte_acl_ctx *
- -rte_acl_create(const struct rte_acl_param *param)
- +rte_acl_create_v20(const struct rte_acl_param *param)
- {
- size_t sz;
- struct rte_acl_ctx *ctx;
- ...
-
-Note that the base name of the symbol was kept intact, as this is conducive to
-the macros used for versioning symbols. That is our next step, mapping this new
-symbol name to the initial symbol name at version node 2.0. Immediately after
-the function, we add this line of code
-
-.. code-block:: c
-
- VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
-
-Remembering to also add the rte_function_versioning.h header to the requisite c file where
-these changes are being made. The above macro instructs the linker to create a
-new symbol ``rte_acl_create@DPDK_2.0``, which matches the symbol created in older
-builds, but now points to the above newly named function. We have now mapped
-the original rte_acl_create symbol to the original function (but with a new
-name)
-
-Next, we need to create the 2.1 version of the symbol. We create a new function
-name, with a different suffix, and implement it appropriately
-
-.. code-block:: c
-
- struct rte_acl_ctx *
- rte_acl_create_v21(const struct rte_acl_param *param, int debug);
- {
- struct rte_acl_ctx *ctx = rte_acl_create_v20(param);
-
- ctx->debug = debug;
-
- return ctx;
- }
-
-This code serves as our new API call. Its the same as our old call, but adds
-the new parameter in place. Next we need to map this function to the symbol
-``rte_acl_create@DPDK_2.1``. To do this, we modify the public prototype of the call
-in the header file, adding the macro there to inform all including applications,
-that on re-link, the default rte_acl_create symbol should point to this
-function. Note that we could do this by simply naming the function above
-rte_acl_create, and the linker would chose the most recent version tag to apply
-in the version script, but we can also do this in the header file
-
-.. code-block:: c
-
- struct rte_acl_ctx *
- -rte_acl_create(const struct rte_acl_param *param);
- +rte_acl_create(const struct rte_acl_param *param, int debug);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
-
-The BIND_DEFAULT_SYMBOL macro explicitly tells applications that include this
-header, to link to the rte_acl_create_v21 function and apply the DPDK_2.1
-version node to it. This method is more explicit and flexible than just
-re-implementing the exact symbol name, and allows for other features (such as
-linking to the old symbol version by default, when the new ABI is to be opt-in
-for a period.
-
-One last thing we need to do. Note that we've taken what was a public symbol,
-and duplicated it into two uniquely and differently named symbols. We've then
-mapped each of those back to the public symbol ``rte_acl_create`` with different
-version tags. This only applies to dynamic linking, as static linking has no
-notion of versioning. That leaves this code in a position of no longer having a
-symbol simply named ``rte_acl_create`` and a static build will fail on that
-missing symbol.
-
-To correct this, we can simply map a function of our choosing back to the public
-symbol in the static build with the ``MAP_STATIC_SYMBOL`` macro. Generally the
-assumption is that the most recent version of the symbol is the one you want to
-map. So, back in the C file where, immediately after ``rte_acl_create_v21`` is
-defined, we add this
-
-.. code-block:: c
-
- struct rte_acl_ctx *
- rte_acl_create_v21(const struct rte_acl_param *param, int debug)
- {
- ...
- }
- MAP_STATIC_SYMBOL(struct rte_acl_ctx *rte_acl_create(const struct rte_acl_param *param, int debug), rte_acl_create_v21);
-
-That tells the compiler that, when building a static library, any calls to the
-symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
-
-That's it, on the next shared library rebuild, there will be two versions of
-rte_acl_create, an old DPDK_2.0 version, used by previously built applications,
-and a new DPDK_2.1 version, used by future built applications.
-
-
-Deprecating part of a public API
-________________________________
-
-Lets assume that you've done the above update, and after a few releases have
-passed you decide you would like to retire the old version of the function.
-After having gone through the ABI deprecation announcement process, removal is
-easy. Start by removing the symbol from the requisite version map file:
-
-.. code-block:: none
-
- DPDK_2.0 {
- global:
-
- rte_acl_add_rules;
- rte_acl_build;
- rte_acl_classify;
- rte_acl_classify_alg;
- rte_acl_classify_scalar;
- rte_acl_dump;
- - rte_acl_create
- rte_acl_find_existing;
- rte_acl_free;
- rte_acl_ipv4vlan_add_rules;
- rte_acl_ipv4vlan_build;
- rte_acl_list_dump;
- rte_acl_reset;
- rte_acl_reset_rules;
- rte_acl_set_ctx_classify;
-
- local: *;
- };
-
- DPDK_2.1 {
- global:
- rte_acl_create;
- } DPDK_2.0;
-
-
-Next remove the corresponding versioned export.
-
-.. code-block:: c
-
- -VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
-
-
-Note that the internal function definition could also be removed, but its used
-in our example by the newer version _v21, so we leave it in place. This is a
-coding style choice.
-
-Lastly, we need to bump the LIBABIVER number for this library in the Makefile to
-indicate to applications doing dynamic linking that this is a later, and
-possibly incompatible library version:
-
-.. code-block:: c
-
- -LIBABIVER := 1
- +LIBABIVER := 2
-
-Deprecating an entire ABI version
-_________________________________
-
-While removing a symbol from and ABI may be useful, it is often more practical
-to remove an entire version node at once. If a version node completely
-specifies an API, then removing part of it, typically makes it incomplete. In
-those cases it is better to remove the entire node
-
-To do this, start by modifying the version map file, such that all symbols from
-the node to be removed are merged into the next node in the map
-
-In the case of our map above, it would transform to look as follows
-
-.. code-block:: none
-
- DPDK_2.1 {
- global:
-
- rte_acl_add_rules;
- rte_acl_build;
- rte_acl_classify;
- rte_acl_classify_alg;
- rte_acl_classify_scalar;
- rte_acl_dump;
- rte_acl_create
- rte_acl_find_existing;
- rte_acl_free;
- rte_acl_ipv4vlan_add_rules;
- rte_acl_ipv4vlan_build;
- rte_acl_list_dump;
- rte_acl_reset;
- rte_acl_reset_rules;
- rte_acl_set_ctx_classify;
-
- local: *;
- };
-
-Then any uses of BIND_DEFAULT_SYMBOL that pointed to the old node should be
-updated to point to the new version node in any header files for all affected
-symbols.
-
-.. code-block:: c
-
- -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 2.0);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
-
-Lastly, any VERSION_SYMBOL macros that point to the old version node should be
-removed, taking care to keep, where need old code in place to support newer
-versions of the symbol.
-
-
-Running the ABI Validator
--------------------------
-
-The ``devtools`` directory in the DPDK source tree contains a utility program,
-``validate-abi.sh``, for validating the DPDK ABI based on the Linux `ABI
-Compliance Checker
-<http://ispras.linuxbase.org/index.php/ABI_compliance_checker>`_.
-
-This has a dependency on the ``abi-compliance-checker`` and ``and abi-dumper``
-utilities which can be installed via a package manager. For example::
-
- sudo yum install abi-compliance-checker
- sudo yum install abi-dumper
-
-The syntax of the ``validate-abi.sh`` utility is::
-
- ./devtools/validate-abi.sh <REV1> <REV2>
-
-Where ``REV1`` and ``REV2`` are valid gitrevisions(7)
-https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
-on the local repo.
-
-For example::
-
- # Check between the previous and latest commit:
- ./devtools/validate-abi.sh HEAD~1 HEAD
-
- # Check on a specific compilation target:
- ./devtools/validate-abi.sh -t x86_64-native-linux-gcc HEAD~1 HEAD
-
- # Check between two tags:
- ./devtools/validate-abi.sh v2.0.0 v2.1.0
-
- # Check between git master and local topic-branch "vhost-hacking":
- ./devtools/validate-abi.sh master vhost-hacking
-
-After the validation script completes (it can take a while since it need to
-compile both tags) it will create compatibility reports in the
-``./abi-check/compat_report`` directory. Listed incompatibilities can be found
-as follows::
-
- grep -lr Incompatible abi-check/compat_reports/
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 4249aab..cf37d80 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -4,7 +4,7 @@
ABI and API Deprecation
=======================
-See the :doc:`guidelines document for details of the ABI policy </contributing/versioning>`.
+See the :doc:`guidelines document for details of the ABI policy </contributing/abi_versioning>`.
API and ABI deprecation notices are to be posted here.
--
2.7.4
^ permalink raw reply [relevance 18%]
* [dpdk-dev] [PATCH v8 0/4] doc: changes to abi policy introducing major abi versions
@ 2019-11-05 15:24 10% Ray Kinsella
2019-11-05 15:24 18% ` [dpdk-dev] [PATCH v8 1/4] doc: separate versioning.rst into version and policy Ray Kinsella
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: Ray Kinsella @ 2019-11-05 15:24 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, john.mcnamara, marko.kovacevic, hemant.agrawal,
ktraynor, aconole
TL;DR abbreviation:
A major ABI version that all DPDK releases during an agreed period support. ABI
versioning is managed at a project-level, in place of library-level management.
ABI changes to add new features are permitted, as long as ABI compatibility with
the major ABI version is maintained.
Detail:
This patch introduces major ABI versions, released aligned with the LTS release
and maintained for one year through subsequent releases. The intention is that
the one year abi support period, will then be reviewed after the initial year
with the intention of lengthening the period for the next ABI version.
ABI changes that preserve ABI compatibility with the major ABI version are
permitted in subsequent releases. ABI changes, follow similar approval rules as
before with the additional gate of now requiring technical board approval. The
merging and release of ABI breaking changes would now be pushed to the
declaration of the next major ABI version.
This change encourages developers to maintain ABI compatibility with the major
ABI version, by promoting a permissive culture around those changes that
preserve ABI compatibility. This approach begins to align DPDK with those
projects that declare major ABI versions (e.g. version 2.x, 3.x) and support
those versions for some period, typically two years or more.
To provide an example of how this might work in practice:
* DPDK v20 is declared as the supported ABI version for one year, aligned with
the DPDK v19.11 (LTS) release. All library sonames are updated to reflect the
new ABI version, e.g. librte_eal.so.20, librte_acl.so.20...
* DPDK v20.02 .. v20.08 releases are ABI compatible with the DPDK v20 ABI. ABI
changes are permitted from DPDK v20.02 onwards, with the condition that ABI
compatibility with DPDK v20 is preserved.
* DPDK v21 is declared as the new supported ABI version for two years, aligned
with the DPDK v20.11 (LTS) release. The DPDK v20 ABI is now depreciated,
library sonames are updated to v21 and ABI compatibility breaking changes may
be introduced.
v8
* Fixed intermediate build warnings, figure annotations and typo's.
(as suggested by John McNamara).
v7
* PNGs are now SVG. Some additional clarifications. Fixed typos and grammatical
errors. (as suggested by Thomas Monjalon and David Marchand)
v6
* Added figure to abi_policy.rst, comparing and contrasting the DPDK abi and
api. (as suggested by Aaron Conole)
v5
* Added figure to abi_policy.rst, mapping abi versions and abi compatibility to
DPDK releases. (as suggested by Neil Horman)
v4
* Removed changes to stable.rst, fixed typos and clarified the ABI policy
"warning".
v3
* Added myself as the maintainer of the ABI policy.
* Updated the policy and versioning guides to use the year of the LTS+1 (e.g.
v20), as the abi major version number.
v2
* Restructured the patch into 3 patches:
1. Splits the original versioning document into an ABI policy document
and ABI versioning document.
2. Add changes to the policy document introducing major ABI versions.
3. Fixes up the versioning document in light of major ABI versioning.
* Reduces the initial ABI stability from two years to one year, with a review
after the first year.
* Adds detail around ABI version handling for experimental libraries.
* Adds detail around chain of responsility for removing deprecated symbols.
Ray Kinsella (4):
doc: separate versioning.rst into version and policy
doc: changes to abi policy introducing major abi versions
doc: updates to versioning guide for abi versions
doc: add maintainer for abi policy
MAINTAINERS | 4 +
doc/guides/contributing/abi_policy.rst | 321 ++++++
doc/guides/contributing/abi_versioning.rst | 515 ++++++++++
.../contributing/img/abi_stability_policy.svg | 1059 ++++++++++++++++++++
doc/guides/contributing/img/what_is_an_abi.svg | 382 +++++++
doc/guides/contributing/index.rst | 3 +-
doc/guides/contributing/patches.rst | 6 +-
doc/guides/contributing/stable.rst | 12 +-
doc/guides/contributing/versioning.rst | 591 -----------
doc/guides/rel_notes/deprecation.rst | 6 +-
10 files changed, 2293 insertions(+), 606 deletions(-)
create mode 100644 doc/guides/contributing/abi_policy.rst
create mode 100644 doc/guides/contributing/abi_versioning.rst
create mode 100644 doc/guides/contributing/img/abi_stability_policy.svg
create mode 100644 doc/guides/contributing/img/what_is_an_abi.svg
delete mode 100644 doc/guides/contributing/versioning.rst
--
2.7.4
^ permalink raw reply [relevance 10%]
* [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps
@ 2019-11-05 15:15 2% Anatoly Burakov
2019-11-05 17:15 0% ` Burakov, Anatoly
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: Anatoly Burakov @ 2019-11-05 15:15 UTC (permalink / raw)
To: dev
Cc: Bruce Richardson, rajesh.ravi, ajit.khaparde,
jonathan.richardson, scott.branden, vikram.prakash,
srinath.mannam, david.marchand, thomas
Currently, externally created heaps are supposed to be automatically
mapped for VFIO DMA by EAL, however they only do so if, at the time of
heap creation, VFIO is initialized and has at least one device
available. If no devices are available at the time of heap creation (or
if devices were available, but were since hot-unplugged, thus dropping
all VFIO container mappings), then VFIO mapping code would have skipped
over externally allocated heaps.
The fix is two-fold. First, we allow externally allocated memory
segments to be marked as "heap" segments. This allows us to distinguish
between external memory segments that were created via heap API, from
those that were created via rte_extmem_register() API.
Then, we fix the VFIO code to only skip non-heap external segments.
Also, since external heaps are not guaranteed to have valid IOVA
addresses, we will skip those which have invalid IOVA addresses as well.
Fixes: 0f526d674f8e ("malloc: separate creating memseg list and malloc heap")
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
Notes:
This cannot be backported to older releases as it breaks the
API and ABI. A separate fix is in the works for stable.
lib/librte_eal/common/include/rte_memory.h | 1 +
lib/librte_eal/common/rte_malloc.c | 1 +
lib/librte_eal/freebsd/eal/eal_memory.c | 1 +
lib/librte_eal/linux/eal/eal_memory.c | 3 ++
lib/librte_eal/linux/eal/eal_vfio.c | 46 +++++++++++++++++++---
5 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_memory.h b/lib/librte_eal/common/include/rte_memory.h
index 38e00e382c..bf81a2faa8 100644
--- a/lib/librte_eal/common/include/rte_memory.h
+++ b/lib/librte_eal/common/include/rte_memory.h
@@ -81,6 +81,7 @@ struct rte_memseg_list {
volatile uint32_t version; /**< version number for multiprocess sync. */
size_t len; /**< Length of memory area covered by this memseg list. */
unsigned int external; /**< 1 if this list points to external memory */
+ unsigned int heap; /**< 1 if this list points to a heap */
struct rte_fbarray memseg_arr;
};
diff --git a/lib/librte_eal/common/rte_malloc.c b/lib/librte_eal/common/rte_malloc.c
index 044d3a9078..413e4aa004 100644
--- a/lib/librte_eal/common/rte_malloc.c
+++ b/lib/librte_eal/common/rte_malloc.c
@@ -396,6 +396,7 @@ rte_malloc_heap_memory_add(const char *heap_name, void *va_addr, size_t len,
rte_spinlock_lock(&heap->lock);
ret = malloc_heap_add_external_memory(heap, msl);
+ msl->heap = 1; /* mark it as heap segment */
rte_spinlock_unlock(&heap->lock);
unlock:
diff --git a/lib/librte_eal/freebsd/eal/eal_memory.c b/lib/librte_eal/freebsd/eal/eal_memory.c
index 7fe3178898..a97d8f0f0c 100644
--- a/lib/librte_eal/freebsd/eal/eal_memory.c
+++ b/lib/librte_eal/freebsd/eal/eal_memory.c
@@ -93,6 +93,7 @@ rte_eal_hugepage_init(void)
msl->page_sz = page_sz;
msl->len = internal_config.memory;
msl->socket_id = 0;
+ msl->heap = 1;
/* populate memsegs. each memseg is 1 page long */
for (cur_seg = 0; cur_seg < n_segs; cur_seg++) {
diff --git a/lib/librte_eal/linux/eal/eal_memory.c b/lib/librte_eal/linux/eal/eal_memory.c
index accfd2e232..43e4ffc757 100644
--- a/lib/librte_eal/linux/eal/eal_memory.c
+++ b/lib/librte_eal/linux/eal/eal_memory.c
@@ -831,6 +831,7 @@ alloc_memseg_list(struct rte_memseg_list *msl, uint64_t page_sz,
msl->page_sz = page_sz;
msl->socket_id = socket_id;
msl->base_va = NULL;
+ msl->heap = 1; /* mark it as a heap segment */
RTE_LOG(DEBUG, EAL, "Memseg list allocated: 0x%zxkB at socket %i\n",
(size_t)page_sz >> 10, socket_id);
@@ -1405,6 +1406,7 @@ eal_legacy_hugepage_init(void)
msl->page_sz = page_sz;
msl->socket_id = 0;
msl->len = internal_config.memory;
+ msl->heap = 1;
/* we're in single-file segments mode, so only the segment list
* fd needs to be set up.
@@ -1677,6 +1679,7 @@ eal_legacy_hugepage_init(void)
mem_sz = msl->len;
munmap(msl->base_va, mem_sz);
msl->base_va = NULL;
+ msl->heap = 0;
/* destroy backing fbarray */
rte_fbarray_destroy(&msl->memseg_arr);
diff --git a/lib/librte_eal/linux/eal/eal_vfio.c b/lib/librte_eal/linux/eal/eal_vfio.c
index d9541b1220..d5a2bbea0d 100644
--- a/lib/librte_eal/linux/eal/eal_vfio.c
+++ b/lib/librte_eal/linux/eal/eal_vfio.c
@@ -1250,7 +1250,16 @@ type1_map(const struct rte_memseg_list *msl, const struct rte_memseg *ms,
{
int *vfio_container_fd = arg;
- if (msl->external)
+ /* skip external memory that isn't a heap */
+ if (msl->external && !msl->heap)
+ return 0;
+
+ /* skip any segments with invalid IOVA addresses */
+ if (ms->iova == RTE_BAD_IOVA)
+ return 0;
+
+ /* if IOVA mode is VA, we've already mapped the internal segments */
+ if (!msl->external && rte_eal_iova_mode() == RTE_IOVA_VA)
return 0;
return vfio_type1_dma_mem_map(*vfio_container_fd, ms->addr_64, ms->iova,
@@ -1313,12 +1322,18 @@ vfio_type1_dma_mem_map(int vfio_container_fd, uint64_t vaddr, uint64_t iova,
static int
vfio_type1_dma_map(int vfio_container_fd)
{
+ int ret;
if (rte_eal_iova_mode() == RTE_IOVA_VA) {
/* with IOVA as VA mode, we can get away with mapping contiguous
* chunks rather than going page-by-page.
*/
- return rte_memseg_contig_walk(type1_map_contig,
+ ret = rte_memseg_contig_walk(type1_map_contig,
&vfio_container_fd);
+ if (ret)
+ return ret;
+ /* we have to continue the walk because we've skipped the
+ * external segments during the config walk.
+ */
}
return rte_memseg_walk(type1_map, &vfio_container_fd);
}
@@ -1410,7 +1425,15 @@ vfio_spapr_map_walk(const struct rte_memseg_list *msl,
{
struct spapr_remap_walk_param *param = arg;
- if (msl->external || ms->addr_64 == param->addr_64)
+ /* skip external memory that isn't a heap */
+ if (msl->external && !msl->heap)
+ return 0;
+
+ /* skip any segments with invalid IOVA addresses */
+ if (ms->iova == RTE_BAD_IOVA)
+ return 0;
+
+ if (ms->addr_64 == param->addr_64)
return 0;
return vfio_spapr_dma_do_map(param->vfio_container_fd, ms->addr_64, ms->iova,
@@ -1423,7 +1446,15 @@ vfio_spapr_unmap_walk(const struct rte_memseg_list *msl,
{
struct spapr_remap_walk_param *param = arg;
- if (msl->external || ms->addr_64 == param->addr_64)
+ /* skip external memory that isn't a heap */
+ if (msl->external && !msl->heap)
+ return 0;
+
+ /* skip any segments with invalid IOVA addresses */
+ if (ms->iova == RTE_BAD_IOVA)
+ return 0;
+
+ if (ms->addr_64 == param->addr_64)
return 0;
return vfio_spapr_dma_do_map(param->vfio_container_fd, ms->addr_64, ms->iova,
@@ -1443,7 +1474,12 @@ vfio_spapr_window_size_walk(const struct rte_memseg_list *msl,
struct spapr_walk_param *param = arg;
uint64_t max = ms->iova + ms->len;
- if (msl->external)
+ /* skip external memory that isn't a heap */
+ if (msl->external && !msl->heap)
+ return 0;
+
+ /* skip any segments with invalid IOVA addresses */
+ if (ms->iova == RTE_BAD_IOVA)
return 0;
/* do not iterate ms we haven't mapped yet */
--
2.17.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
2019-11-03 7:50 0% ` Slava Ovsiienko
@ 2019-11-05 15:12 0% ` Ferruh Yigit
2019-11-05 15:54 0% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-11-05 15:12 UTC (permalink / raw)
To: Slava Ovsiienko, Damjan Marion (damarion)
Cc: Liu, Yu Y, Wang, Haiyue, Thomas Monjalon, dev, arybchenko,
jerinjacobk, Ye, Xiaolong, Ray Kinsella, Sun, Chenmin
On 11/3/2019 7:50 AM, Slava Ovsiienko wrote:
>
>
>> -----Original Message-----
>> From: Damjan Marion (damarion) <damarion@cisco.com>
>> Sent: Saturday, November 2, 2019 21:21
>> To: Slava Ovsiienko <viacheslavo@mellanox.com>
>> Cc: Liu, Yu Y <yu.y.liu@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
>> Thomas Monjalon <thomas@monjalon.net>; dev@dpdk.org;
>> arybchenko@solarflare.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
>> jerinjacobk@gmail.com; Ye, Xiaolong <xiaolong.ye@intel.com>; Ray Kinsella
>> <ray.kinsella@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>
>> Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
>> information
>>
>>
>>
>>> On 2 Nov 2019, at 09:38, Slava Ovsiienko <viacheslavo@mellanox.com>
>> wrote:
>>>
>>> Hi
>>>> -----Original Message-----
>>>> From: Liu, Yu Y <yu.y.liu@intel.com>
>>>> Sent: Saturday, November 2, 2019 8:56
>>>> To: Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
>>>> <thomas@monjalon.net>
>>>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
>>>> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
>>>> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
>>>> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
>>>> <viacheslavo@mellanox.com>; Damjan Marion (damarion)
>>>> <damarion@cisco.com>; Liu, Yu Y <yu.y.liu@intel.com>
>>>> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst
>>>> mode information
>>>>
>>>> Add Damjan from FD.io for awareness...
>>>>
>>>> Hi Thomas,
>>>>
>>>> Long time no see. Sorry I use outlook which is not friendly to
>>>> community email.
>>>>
>>>>> Anyway I will propose to replace this API in the next release.
>>>> Will your plan be affected by API/ABI stable plan?
>>>> BTW, if you propose new change in next release, it will make DPDK
>>>> consumer(FD.io) to change again.
>>>> So even if it is not affected to the API/ABI stable plan, do we still
>>>> have time to get a solution for everyone in DPDK 19.11 with your
>>>> contribution/acceleration?
>>>>
>>>>> I suspect a real hidden issue in Intel CPUs that you try to mitigate.
>>>> Please be rest assured it is not the case.
>>>> This request is just from one FD.io project internal bug " tx/rx
>>>> burst function is shown as nil" reported by Chenmin.
>>>
>>> Why just the presenting string with function name (possible with suffix) is
>> not enough?
>>> I would like to see this API (strings approach) in mlx5 either,
>>> dropping the entire feature does not look nice, as for me.
>>>
>>> We could consider some requirements for the name suffices to
>>> distinguish whether function uses vector instructions and which ones if any.
>>>
>>>> My understanding is DPDK behavior was taken as bug for someone in
>>>> FD.io project and potentially will mislead other DPDK consumer.
>>>
>>> Why does FD.io code want to know which vector extension is used by burst
>> routines?
>>> Is it going to share/preserve some resources (registers, etc.)? Is it robust ?
>>> Burst routines might not know whether vector extensions is used (they
>>> might call libraries, even rte_memcpy() can use vectors in implicit fashion).
>>
>> This is jut debug CLI print, it was added by me as a result of frustration of
>> dealing constantly with operational issues where people are reporting lower
>> performance caused by DPDK deciding for variety of reasons to switch from
>> vector PMD to scalar one.
>
> And it seems there is no need for flags, as for me.
> I think the simple string would be quite enough to identify the datapath routine.
> Also, we have exact the same issue with mlx5 PMD, so the API (in simple
> string version) is desirable (+1 from me).
>
Hi Thomas, Slava,
It has been discussed in the previous mail thread [1], there was no objection to
it and Haiyue seems send the version based on it.
For me having the flag still makes sense, because:
1) It helps standardizing the provided string.
2) Helps to the application to consume the provided data via API (not text)
The idea was PMD sets the flag for the know standard features, provides the text
for the non standard part.
The APIs converts the flag to the string and append to text so it will be
complete for the app if just wants to log it. Flags still has the standard part
for the application what to use it.
Initially standard part was just vectorization but it can be extended by time as
more common data path used by PMDs. Text part is always free text.
After above said, I think the API has been already discussed more than enough,
and Haiyue already sent an all string version, OK to go with it.
[1]
http://inbox.dpdk.org/dev/a6893929-f981-4701-7cce-52b5e8ec934e@intel.com/
> With best regards, Slava
>
>>>
>>>> Haiyue is working with Chenmin to address the issue and with your
>>>> support it will be even better.
>>>>
>>>> Your support will be highly appreciated!
>>>>
>>>> Thanks & Regards,
>>>> Yu Liu
>>>>
>>>> -----Original Message-----
>>>> From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
>>>> Sent: Saturday, November 2, 2019 1:30 PM
>>>> To: Thomas Monjalon <thomas@monjalon.net>
>>>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
>>>> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
>>>> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
>>>> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
>>>> <viacheslavo@mellanox.com>
>>>> Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for
>>>> getting burst mode information
>>>>
>>>>> -----Original Message-----
>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>> Sent: Saturday, November 2, 2019 06:46
>>>>> To: Wang, Haiyue <haiyue.wang@intel.com>
>>>>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
>>>>> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
>>>>> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
>>>>> Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
>>>>> <viacheslavo@mellanox.com>
>>>>> Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting
>>>>> burst mode information
>>>>>
>>>>> Thank you for trying to address comments done late.
>>>>>
>>>>> 31/10/2019 18:11, Haiyue Wang:
>>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>>>
>>>>
>>>>>> +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2)
>>>>>> +#define RTE_ETH_BURST_NEON (1ULL << 3)
>>>>>> +#define RTE_ETH_BURST_SSE (1ULL << 4)
>>>>>> +#define RTE_ETH_BURST_AVX2 (1ULL << 5)
>>>>>> +#define RTE_ETH_BURST_AVX512 (1ULL << 6)
>>>>>
>>>>> Of course, I still believe that giving a special treatment to vector
>>>>> instructions is wrong.
>>>>> You did not justify why it needs to be defined in bits instead of
>>>>> string. I am not asking again because anyway you don't really reply.
>>>>> I think you are executing an order you received and I don't want to
>>>>> blame you more.
>>>>> I suspect a real hidden issue in Intel CPUs that you try to mitigate.
>>>>> No need to reply to this comment.
>>>>> Anyway I will propose to replace this API in the next release.
>>>>
>>>> Never mind, if this design is truly ugly, drop it all now. I also
>>>> prefer to do the best, that's why open source is amazing, thanks! ;-)
>>>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 2/4] doc: changes to abi policy introducing major abi versions
2019-10-31 15:06 9% ` Mcnamara, John
@ 2019-11-05 15:11 5% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-11-05 15:11 UTC (permalink / raw)
To: Mcnamara, John, dev
Cc: thomas, stephen, Richardson, Bruce, Yigit, Ferruh, Ananyev,
Konstantin, jerinj, olivier.matz, nhorman, maxime.coquelin,
Kovacevic, Marko, hemant.agrawal, ktraynor, aconole
On 31/10/2019 15:06, Mcnamara, John wrote:
>
>
>> -----Original Message-----
>> From: Ray Kinsella <mdr@ashroe.eu>
>> Sent: Friday, October 25, 2019 5:29 PM
>> To: dev@dpdk.org
>> Cc: mdr@ashroe.eu; thomas@monjalon.net; stephen@networkplumber.org;
>> Richardson, Bruce <bruce.richardson@intel.com>; Yigit, Ferruh
>> <ferruh.yigit@intel.com>; Ananyev, Konstantin
>> <konstantin.ananyev@intel.com>; jerinj@marvell.com;
>> olivier.matz@6wind.com; nhorman@tuxdriver.com;
>> maxime.coquelin@redhat.com; Mcnamara, John <john.mcnamara@intel.com>;
>> Kovacevic, Marko <marko.kovacevic@intel.com>; hemant.agrawal@nxp.com;
>> ktraynor@redhat.com; aconole@redhat.com
>> Subject: [PATCH v7 2/4] doc: changes to abi policy introducing major abi
>> versions
>>
>> This policy change introduces major ABI versions, these are
>> declared every year, typically aligned with the LTS release
>> and are supported by subsequent releases in the following year.
>> This change is intended to improve ABI stabilty for those projects
>> consuming DPDK.
>>
>> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
>> ---
>> doc/guides/contributing/abi_policy.rst | 321 ++++--
>> .../contributing/img/abi_stability_policy.svg | 1059
>
>
> There are build warnings after this patch. I know they are fixed in patch 3 but there shouldn't be any build warnings in each patch of the patchset.
>
> $ make doc-guides-html
> sphinx processing guides-html...
> /work/dpdk_docs/doc/guides/contributing/abi_policy.rst:18:
> WARNING: undefined label: what_is_soname (if the link has no caption the label must precede a section header)
> /work/dpdk_docs/doc/guides/contributing/abi_policy.rst:22:
> WARNING: undefined label: abi_versioning (if the link has no caption the label must precede a section header)
> /work/dpdk_docs/doc/guides/contributing/abi_policy.rst:63:
> WARNING: undefined label: what_is_soname (if the link has no caption the label must precede a section header)
> /work/dpdk_docs/doc/guides/contributing/abi_policy.rst:73:
> WARNING: undefined label: major_abi_versions (if the link has no caption the label must precede a section header)
> /work/dpdk_docs/doc/guides/contributing/abi_policy.rst:145:
> WARNING: undefined label: abi_versioning (if the link has no caption the label must precede a section header)
> /work/dpdk_docs/doc/guides/contributing/abi_policy.rst:221:
> WARNING: undefined label: abi_versioning (if the link has no caption the label must precede a section header)
> /work/dpdk_docs/doc/guides/contributing/abi_policy.rst:318:
> WARNING: undefined label: abi_versioning (if the link has no caption the label must precede a section header)
> /work/dpdk_docs/doc/guides/contributing/patches.rst:159:
> WARNING: unknown document: /contributing/versioning
> /work/dpdk_docs/doc/guides/contributing/stable.rst:56:
> WARNING: undefined label: abi_policy (if the link has no caption the label must precede a section header)
> /work/dpdk_docs/doc/guides/rel_notes/deprecation.rst:7:
> WARNING: unknown document: /contributing/versioning
ACK resolved in v8
>
>
> The syntax of the following image caption is wrong:
>
> .. _figure_what_is_an_abi:
>
> .. figure:: img/what_is_an_abi.*
>
> *Figure 1. Illustration of DPDK API and ABI .*
>
> It should be indented and shouldn't have a figure number (that is added automatically) or bolding. Like this:
>
> .. _figure_what_is_an_abi:
>
> .. figure:: img/what_is_an_abi.*
>
> Illustration of DPDK API and ABI.
>
> See the following for details:
> http://doc.dpdk.org/guides/contributing/documentation.html#images
ACK resolved in v8 (for both figures)
>
> The is a stray backtick here:
>
>
> +changes must follow the `same process :ref:`described above <abi_changes>` as non-breaking
>
> It should be:
>
> +changes must follow the same process :ref:`described above <abi_changes>` as non-breaking
ACK resolved in v8
>
> John
>
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v7 1/4] doc: separate versioning.rst into version and policy
2019-10-31 15:02 0% ` Mcnamara, John
@ 2019-11-05 15:11 0% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-11-05 15:11 UTC (permalink / raw)
To: Mcnamara, John, dev
Cc: thomas, stephen, Richardson, Bruce, Yigit, Ferruh, Ananyev,
Konstantin, jerinj, olivier.matz, nhorman, maxime.coquelin,
Kovacevic, Marko, hemant.agrawal, ktraynor, aconole
On 31/10/2019 15:02, Mcnamara, John wrote:
>
>
>> -----Original Message-----
>> From: Ray Kinsella <mdr@ashroe.eu>
>> Sent: Friday, October 25, 2019 5:29 PM
>> To: dev@dpdk.org
>> Cc: mdr@ashroe.eu; thomas@monjalon.net; stephen@networkplumber.org;
>> Richardson, Bruce <bruce.richardson@intel.com>; Yigit, Ferruh
>> <ferruh.yigit@intel.com>; Ananyev, Konstantin
>> <konstantin.ananyev@intel.com>; jerinj@marvell.com;
>> olivier.matz@6wind.com; nhorman@tuxdriver.com;
>> maxime.coquelin@redhat.com; Mcnamara, John <john.mcnamara@intel.com>;
>> Kovacevic, Marko <marko.kovacevic@intel.com>; hemant.agrawal@nxp.com;
>> ktraynor@redhat.com; aconole@redhat.com
>> Subject: [PATCH v7 1/4] doc: separate versioning.rst into version and
>> policy
>>
>> Separate versioning.rst into abi versioning and abi policy guidance, in
>> preparation for adding more detail to the abi policy.
>>
>> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
>> ---
>> doc/guides/contributing/abi_policy.rst | 167 ++++++++
>> doc/guides/contributing/abi_versioning.rst | 427 +++++++++++++++++++++
>> doc/guides/contributing/index.rst | 3 +-
>> doc/guides/contributing/versioning.rst | 591 -----------------------
>
>
> I think the it would be better to "git mv" versioning.rst to abi_versioning.rst first to maintain the history and then extract out the policy part.
pls check git log --follow to follow rename, correctly tracks the git history at my end.
>
> Also, there is a build warning after this patch:
>
>
> $ make doc-guides-html
> sphinx processing guides-html...
> /work/dpdk_docs/doc/guides/contributing/patches.rst:159:
> WARNING: unknown document: /contributing/versioning
> /work/dpdk_docs/doc/guides/rel_notes/deprecation.rst:7:
> WARNING: unknown document: /contributing/versioning
ACK resolved in v8
>
> John
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 01/10] config: change ABI versioning to global
2019-11-05 11:05 4% ` David Marchand
@ 2019-11-05 13:50 4% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-11-05 13:50 UTC (permalink / raw)
To: David Marchand
Cc: Anatoly Burakov, dev, Marcin Baran, Thomas Monjalon, Mcnamara,
John, Kinsella, Ray, Pawel Modrak
On Tue, Nov 05, 2019 at 12:05:15PM +0100, David Marchand wrote:
> On Thu, Oct 24, 2019 at 11:46 AM Anatoly Burakov
> <anatoly.burakov@intel.com> wrote:
> >
> > From: Marcin Baran <marcinx.baran@intel.com>
> >
> > As per new ABI policy, all of the libraries are now versioned using
> > one global ABI version. Changes in this patch implement the
> > necessary steps to enable that.
> >
> > Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
> > Signed-off-by: Pawel Modrak <pawelx.modrak@intel.com>
> > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
> >
> > Notes:
> > v3:
> > - Removed Windows support from Makefile changes
> > - Removed unneeded path conversions from meson files
> >
> > buildtools/meson.build | 2 ++
> > config/ABI_VERSION | 1 +
> > config/meson.build | 4 +++-
> > drivers/meson.build | 20 ++++++++++++--------
> > lib/meson.build | 18 +++++++++++-------
> > meson_options.txt | 2 --
> > mk/rte.lib.mk | 13 ++++---------
> > 7 files changed, 33 insertions(+), 27 deletions(-)
> > create mode 100644 config/ABI_VERSION
> >
> > diff --git a/buildtools/meson.build b/buildtools/meson.build
> > index 32c79c1308..78ce69977d 100644
> > --- a/buildtools/meson.build
> > +++ b/buildtools/meson.build
> > @@ -12,3 +12,5 @@ if python3.found()
> > else
> > map_to_def_cmd = ['meson', 'runpython', files('map_to_def.py')]
> > endif
> > +
> > +is_experimental_cmd = [find_program('grep', 'findstr'), '^DPDK_']
>
> Traces from the windows stuff?
>
Yes, it's needed to ensure this doesn't error out on windows.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
2019-11-05 13:02 0% ` Thomas Monjalon
2019-11-05 13:23 3% ` Ori Kam
@ 2019-11-05 13:41 0% ` Andrew Rybchenko
1 sibling, 0 replies; 200+ results
From: Andrew Rybchenko @ 2019-11-05 13:41 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Ferruh Yigit, Ori Kam, John McNamara, Marko Kovacevic, dev,
jingjing.wu, stephen, Jerin Jacob
On 11/5/19 4:02 PM, Thomas Monjalon wrote:
> 05/11/2019 13:53, Andrew Rybchenko:
>> On 11/5/19 3:51 PM, Thomas Monjalon wrote:
>>> 05/11/2019 13:27, Andrew Rybchenko:
>>>> On 11/5/19 3:23 PM, Ferruh Yigit wrote:
>>>>> On 11/5/2019 12:12 PM, Andrew Rybchenko wrote:
>>>>>> On 11/5/19 3:05 PM, Ferruh Yigit wrote:
>>>>>>> On 11/5/2019 11:49 AM, Andrew Rybchenko wrote:
>>>>>>>> On 11/5/19 2:36 PM, Ori Kam wrote:
>>> >>>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>>>>>>>> /**
>>>>>>>>>>> + * @internal
>>>>>>>>>>> + * Check if the selected Rx queue is hairpin queue.
>>>>>>>>>>> + *
>>>>>>>>>>> + * @param dev
>>>>>>>>>>> + * Pointer to the selected device.
>>>>>>>>>>> + * @param queue_id
>>>>>>>>>>> + * The selected queue.
>>>>>>>>>>> + *
>>>>>>>>>>> + * @return
>>>>>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>>>>>>>>> + */
>>>>>>>>>>> +int
>>>>>>>>>>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>>>>>>>>>> queue_id);
>>>>>>>>>>> +
>>>>>>>>>>> +/**
>>>>>>>>>>> + * @internal
>>>>>>>>>>> + * Check if the selected Tx queue is hairpin queue.
>>>>>>>>>>> + *
>>>>>>>>>>> + * @param dev
>>>>>>>>>>> + * Pointer to the selected device.
>>>>>>>>>>> + * @param queue_id
>>>>>>>>>>> + * The selected queue.
>>>>>>>>>>> + *
>>>>>>>>>>> + * @return
>>>>>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>>>>>>>>> + */
>>>>>>>>>>> +int
>>>>>>>>>>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>>>>>>>>>> queue_id);
>>> [...]
>>>>>>>>>> These are causing build error, thanks Jerin for catching, because they are
>>>>>>>>>> internal and called by a public static inline API, so whoever calls
>>>>>>>>>> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find
>>>>>>>>>> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1],
>>>>>>>>>>
>>>>>>>>>> as far as I can see there are two options:
>>>>>>>>>> 1) Remove these checks
>>>>>>>>>> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead of internal
>>>>>>>>>>
>>>>>>>>>> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API
>>>>>>>>>> we
>>>>>>>>>> should go with (2) else (1).
>>>>>>>>>>
>>>>>>>>> I think we can skip the tests,
>>>>>>>>> But it was Andrew request so we must get is response.
>>>>>>>>> It was also his empathies that they should be internal.
>>>>>>>> It is important for me to keep rte_eth_dev_state internal and
>>>>>>>> few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline.
>>>>>>> Are you saying you don't want to option to make
>>>>>>> 'rte_eth_dev_is_rx_hairpin_queue()' static inline because it will force the
>>>>>>> 'RTE_ETH_QUEUE_STATE_xxx' being public?
>>>>>> Yes.
>>>>> +1
>>>>>
>>>>>>>> I'm OK to make the function experimental or keep it internal
>>>>>>>> (no API/ABI stability requirements) but externally visible (in .map).
>>>>>>> I think we can't do this, add a function deceleration to the public header file
>>>>>>> and add it to the .map file but keep it internal. Instead we can make it a
>>>>>>> proper API and it should be experimental at least first release.
>>>>>> We have discussed similar thing with Olivier recently [1].
>>>>>>
>>>>>> [1] http://inbox.dpdk.org/dev/20191030142938.bpi4txlrebqfq7uw@platinum/
>>>>> Yes we can say they are internal but there won't be anything preventing
>>>>> applications to use them.
>>>> That's true, but making it internal says - don't use it.
>>>> Anyway, I have no strong opinion on experimental vs internal.
>>>>
>>>>>>> The question above was do we need this API, or instead should remove the check
>>>>>>> from rx/tx_burst APIs?
>>>>>> I think these checks are useful to ensure that these functions
>>>>>> are not used for hairpin queues. At least to catch it with debug
>>>>>> enabled.
>>>>> OK, if so what not make them proper API? Any concern on it?
>>> Why we should not use this API in applications?
>> I think the valid question is why application needs the API.
>> Basically I don't mind, just want to be sure that only required
>> API is exposed.
> Because hairpin queues are not standard queues,
> we may need to distinguish them.
> I see it as a good helper for applications.
> Am I missing something obvious?
I think no. I would prefer explicit reason, but since
these function are simple, I'm OK to go with
"may need to distinguish them"
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
2019-11-05 13:27 0% ` Thomas Monjalon
@ 2019-11-05 13:34 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2019-11-05 13:34 UTC (permalink / raw)
To: Thomas Monjalon, Ori Kam, Ferruh Yigit
Cc: John McNamara, Marko Kovacevic, dev, jingjing.wu, stephen, Jerin Jacob
On 11/5/19 4:27 PM, Thomas Monjalon wrote:
> 05/11/2019 14:23, Ori Kam:
>> From: Thomas Monjalon <thomas@monjalon.net>
>>> 05/11/2019 13:53, Andrew Rybchenko:
>>>> On 11/5/19 3:51 PM, Thomas Monjalon wrote:
>>>>> 05/11/2019 13:27, Andrew Rybchenko:
>>>>>> On 11/5/19 3:23 PM, Ferruh Yigit wrote:
>>>>>>> On 11/5/2019 12:12 PM, Andrew Rybchenko wrote:
>>>>>>>> On 11/5/19 3:05 PM, Ferruh Yigit wrote:
>>>>>>>>> On 11/5/2019 11:49 AM, Andrew Rybchenko wrote:
>>>>>>>>>> On 11/5/19 2:36 PM, Ori Kam wrote:
>>>>> >>>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>>>>>>>>>> /**
>>>>>>>>>>>>> + * @internal
>>>>>>>>>>>>> + * Check if the selected Rx queue is hairpin queue.
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * @param dev
>>>>>>>>>>>>> + * Pointer to the selected device.
>>>>>>>>>>>>> + * @param queue_id
>>>>>>>>>>>>> + * The selected queue.
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * @return
>>>>>>>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>>>>>>>>>>> + */
>>>>>>>>>>>>> +int
>>>>>>>>>>>>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev,
>>> uint16_t
>>>>>>>>>>>> queue_id);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +/**
>>>>>>>>>>>>> + * @internal
>>>>>>>>>>>>> + * Check if the selected Tx queue is hairpin queue.
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * @param dev
>>>>>>>>>>>>> + * Pointer to the selected device.
>>>>>>>>>>>>> + * @param queue_id
>>>>>>>>>>>>> + * The selected queue.
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * @return
>>>>>>>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>>>>>>>>>>> + */
>>>>>>>>>>>>> +int
>>>>>>>>>>>>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev,
>>> uint16_t
>>>>>>>>>>>> queue_id);
>>>>> [...]
>>>>>>>>>>>> These are causing build error, thanks Jerin for catching, because
>>> they are
>>>>>>>>>>>> internal and called by a public static inline API, so whoever calls
>>>>>>>>>>>> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find
>>>>>>>>>>>> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1],
>>>>>>>>>>>>
>>>>>>>>>>>> as far as I can see there are two options:
>>>>>>>>>>>> 1) Remove these checks
>>>>>>>>>>>> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead
>>> of internal
>>>>>>>>>>>> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()'
>>> public API
>>>>>>>>>>>> we
>>>>>>>>>>>> should go with (2) else (1).
>>>>>>>>>>>>
>>>>>>>>>>> I think we can skip the tests,
>>>>>>>>>>> But it was Andrew request so we must get is response.
>>>>>>>>>>> It was also his empathies that they should be internal.
>>>>>>>>>> It is important for me to keep rte_eth_dev_state internal and
>>>>>>>>>> few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline.
>>>>>>>>> Are you saying you don't want to option to make
>>>>>>>>> 'rte_eth_dev_is_rx_hairpin_queue()' static inline because it will force
>>> the
>>>>>>>>> 'RTE_ETH_QUEUE_STATE_xxx' being public?
>>>>>>>> Yes.
>>>>>>> +1
>>>>>>>
>>>>>>>>>> I'm OK to make the function experimental or keep it internal
>>>>>>>>>> (no API/ABI stability requirements) but externally visible (in .map).
>>>>>>>>> I think we can't do this, add a function deceleration to the public
>>> header file
>>>>>>>>> and add it to the .map file but keep it internal. Instead we can make it
>>> a
>>>>>>>>> proper API and it should be experimental at least first release.
> Using an experimental function in an inline API may propagate the
> experimental flag further.
>
>> Moving the API to experimental results in the following error:
>> error: 'rte_eth_dev_is_rx_hairpin_queue' is deprecated (declared at /.autodirect/mtrswgwork/orika/pegasus04_share/dpdk.org/x86_64-native-linuxapp-gcc/include/rte_ethdev.h:4276): Symbol is not yet part of stable ABI [-Werror=deprecated-declarations]
>>
>> I suggest that we remove the checks, in any case this checks are only on debug mode, and when using data path the user must be very careful and what he
>> is doing.
> I agree it seems better to remove these checks for now.
> We can decide to re-introduce them later as non-experimental.
OK
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
2019-11-05 13:23 3% ` Ori Kam
@ 2019-11-05 13:27 0% ` Thomas Monjalon
2019-11-05 13:34 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-11-05 13:27 UTC (permalink / raw)
To: Ori Kam, Andrew Rybchenko, Ferruh Yigit
Cc: John McNamara, Marko Kovacevic, dev, jingjing.wu, stephen, Jerin Jacob
05/11/2019 14:23, Ori Kam:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 05/11/2019 13:53, Andrew Rybchenko:
> > > On 11/5/19 3:51 PM, Thomas Monjalon wrote:
> > > > 05/11/2019 13:27, Andrew Rybchenko:
> > > >> On 11/5/19 3:23 PM, Ferruh Yigit wrote:
> > > >>> On 11/5/2019 12:12 PM, Andrew Rybchenko wrote:
> > > >>>> On 11/5/19 3:05 PM, Ferruh Yigit wrote:
> > > >>>>> On 11/5/2019 11:49 AM, Andrew Rybchenko wrote:
> > > >>>>>> On 11/5/19 2:36 PM, Ori Kam wrote:
> > > > >>>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
> > > >>>>>>>>> /**
> > > >>>>>>>>> + * @internal
> > > >>>>>>>>> + * Check if the selected Rx queue is hairpin queue.
> > > >>>>>>>>> + *
> > > >>>>>>>>> + * @param dev
> > > >>>>>>>>> + * Pointer to the selected device.
> > > >>>>>>>>> + * @param queue_id
> > > >>>>>>>>> + * The selected queue.
> > > >>>>>>>>> + *
> > > >>>>>>>>> + * @return
> > > >>>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
> > > >>>>>>>>> + */
> > > >>>>>>>>> +int
> > > >>>>>>>>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev,
> > uint16_t
> > > >>>>>>>> queue_id);
> > > >>>>>>>>> +
> > > >>>>>>>>> +/**
> > > >>>>>>>>> + * @internal
> > > >>>>>>>>> + * Check if the selected Tx queue is hairpin queue.
> > > >>>>>>>>> + *
> > > >>>>>>>>> + * @param dev
> > > >>>>>>>>> + * Pointer to the selected device.
> > > >>>>>>>>> + * @param queue_id
> > > >>>>>>>>> + * The selected queue.
> > > >>>>>>>>> + *
> > > >>>>>>>>> + * @return
> > > >>>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
> > > >>>>>>>>> + */
> > > >>>>>>>>> +int
> > > >>>>>>>>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev,
> > uint16_t
> > > >>>>>>>> queue_id);
> > > > [...]
> > > >>>>>>>> These are causing build error, thanks Jerin for catching, because
> > they are
> > > >>>>>>>> internal and called by a public static inline API, so whoever calls
> > > >>>>>>>> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find
> > > >>>>>>>> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1],
> > > >>>>>>>>
> > > >>>>>>>> as far as I can see there are two options:
> > > >>>>>>>> 1) Remove these checks
> > > >>>>>>>> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead
> > of internal
> > > >>>>>>>>
> > > >>>>>>>> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()'
> > public API
> > > >>>>>>>> we
> > > >>>>>>>> should go with (2) else (1).
> > > >>>>>>>>
> > > >>>>>>> I think we can skip the tests,
> > > >>>>>>> But it was Andrew request so we must get is response.
> > > >>>>>>> It was also his empathies that they should be internal.
> > > >>>>>> It is important for me to keep rte_eth_dev_state internal and
> > > >>>>>> few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline.
> > > >>>>> Are you saying you don't want to option to make
> > > >>>>> 'rte_eth_dev_is_rx_hairpin_queue()' static inline because it will force
> > the
> > > >>>>> 'RTE_ETH_QUEUE_STATE_xxx' being public?
> > > >>>> Yes.
> > > >>> +1
> > > >>>
> > > >>>>>> I'm OK to make the function experimental or keep it internal
> > > >>>>>> (no API/ABI stability requirements) but externally visible (in .map).
> > > >>>>> I think we can't do this, add a function deceleration to the public
> > header file
> > > >>>>> and add it to the .map file but keep it internal. Instead we can make it
> > a
> > > >>>>> proper API and it should be experimental at least first release.
Using an experimental function in an inline API may propagate the
experimental flag further.
> Moving the API to experimental results in the following error:
> error: 'rte_eth_dev_is_rx_hairpin_queue' is deprecated (declared at /.autodirect/mtrswgwork/orika/pegasus04_share/dpdk.org/x86_64-native-linuxapp-gcc/include/rte_ethdev.h:4276): Symbol is not yet part of stable ABI [-Werror=deprecated-declarations]
>
> I suggest that we remove the checks, in any case this checks are only on debug mode, and when using data path the user must be very careful and what he
> is doing.
I agree it seems better to remove these checks for now.
We can decide to re-introduce them later as non-experimental.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
2019-11-05 13:02 0% ` Thomas Monjalon
@ 2019-11-05 13:23 3% ` Ori Kam
2019-11-05 13:27 0% ` Thomas Monjalon
2019-11-05 13:41 0% ` Andrew Rybchenko
1 sibling, 1 reply; 200+ results
From: Ori Kam @ 2019-11-05 13:23 UTC (permalink / raw)
To: Thomas Monjalon, Andrew Rybchenko
Cc: Ferruh Yigit, John McNamara, Marko Kovacevic, dev, jingjing.wu,
stephen, Jerin Jacob
Hi All
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, November 5, 2019 3:02 PM
> To: Andrew Rybchenko <arybchenko@solarflare.com>
> Cc: Ferruh Yigit <ferruh.yigit@intel.com>; Ori Kam <orika@mellanox.com>;
> John McNamara <john.mcnamara@intel.com>; Marko Kovacevic
> <marko.kovacevic@intel.com>; dev@dpdk.org; jingjing.wu@intel.com;
> stephen@networkplumber.org; Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Subject: Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
>
> 05/11/2019 13:53, Andrew Rybchenko:
> > On 11/5/19 3:51 PM, Thomas Monjalon wrote:
> > > 05/11/2019 13:27, Andrew Rybchenko:
> > >> On 11/5/19 3:23 PM, Ferruh Yigit wrote:
> > >>> On 11/5/2019 12:12 PM, Andrew Rybchenko wrote:
> > >>>> On 11/5/19 3:05 PM, Ferruh Yigit wrote:
> > >>>>> On 11/5/2019 11:49 AM, Andrew Rybchenko wrote:
> > >>>>>> On 11/5/19 2:36 PM, Ori Kam wrote:
> > > >>>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
> > >>>>>>>>> /**
> > >>>>>>>>> + * @internal
> > >>>>>>>>> + * Check if the selected Rx queue is hairpin queue.
> > >>>>>>>>> + *
> > >>>>>>>>> + * @param dev
> > >>>>>>>>> + * Pointer to the selected device.
> > >>>>>>>>> + * @param queue_id
> > >>>>>>>>> + * The selected queue.
> > >>>>>>>>> + *
> > >>>>>>>>> + * @return
> > >>>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
> > >>>>>>>>> + */
> > >>>>>>>>> +int
> > >>>>>>>>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev,
> uint16_t
> > >>>>>>>> queue_id);
> > >>>>>>>>> +
> > >>>>>>>>> +/**
> > >>>>>>>>> + * @internal
> > >>>>>>>>> + * Check if the selected Tx queue is hairpin queue.
> > >>>>>>>>> + *
> > >>>>>>>>> + * @param dev
> > >>>>>>>>> + * Pointer to the selected device.
> > >>>>>>>>> + * @param queue_id
> > >>>>>>>>> + * The selected queue.
> > >>>>>>>>> + *
> > >>>>>>>>> + * @return
> > >>>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
> > >>>>>>>>> + */
> > >>>>>>>>> +int
> > >>>>>>>>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev,
> uint16_t
> > >>>>>>>> queue_id);
> > > [...]
> > >>>>>>>> These are causing build error, thanks Jerin for catching, because
> they are
> > >>>>>>>> internal and called by a public static inline API, so whoever calls
> > >>>>>>>> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find
> > >>>>>>>> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1],
> > >>>>>>>>
> > >>>>>>>> as far as I can see there are two options:
> > >>>>>>>> 1) Remove these checks
> > >>>>>>>> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead
> of internal
> > >>>>>>>>
> > >>>>>>>> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()'
> public API
> > >>>>>>>> we
> > >>>>>>>> should go with (2) else (1).
> > >>>>>>>>
> > >>>>>>> I think we can skip the tests,
> > >>>>>>> But it was Andrew request so we must get is response.
> > >>>>>>> It was also his empathies that they should be internal.
> > >>>>>> It is important for me to keep rte_eth_dev_state internal and
> > >>>>>> few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline.
> > >>>>> Are you saying you don't want to option to make
> > >>>>> 'rte_eth_dev_is_rx_hairpin_queue()' static inline because it will force
> the
> > >>>>> 'RTE_ETH_QUEUE_STATE_xxx' being public?
> > >>>> Yes.
> > >>> +1
> > >>>
> > >>>>>> I'm OK to make the function experimental or keep it internal
> > >>>>>> (no API/ABI stability requirements) but externally visible (in .map).
> > >>>>> I think we can't do this, add a function deceleration to the public
> header file
> > >>>>> and add it to the .map file but keep it internal. Instead we can make it
> a
> > >>>>> proper API and it should be experimental at least first release.
> > >>>> We have discussed similar thing with Olivier recently [1].
> > >>>>
> > >>>> [1]
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Finbox.dpdk
> .org%2Fdev%2F20191030142938.bpi4txlrebqfq7uw%40platinum%2F&data
> =02%7C01%7Corika%40mellanox.com%7Cb065a7e085aa47723cc408d761f06c9
> f%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C6370855575589250
> 92&sdata=6kY30p%2BEr4DMQiMqbBPX%2BJZ7h0eMp0FxnzhnE%2F7U%2
> BeM%3D&reserved=0
> > >>> Yes we can say they are internal but there won't be anything preventing
> > >>> applications to use them.
> > >>
> > >> That's true, but making it internal says - don't use it.
> > >> Anyway, I have no strong opinion on experimental vs internal.
> > >>
> > >>>>> The question above was do we need this API, or instead should remove
> the check
> > >>>>> from rx/tx_burst APIs?
> > >>>> I think these checks are useful to ensure that these functions
> > >>>> are not used for hairpin queues. At least to catch it with debug
> > >>>> enabled.
> > >>> OK, if so what not make them proper API? Any concern on it?
> > >
> > > Why we should not use this API in applications?
> >
> > I think the valid question is why application needs the API.
> > Basically I don't mind, just want to be sure that only required
> > API is exposed.
>
> Because hairpin queues are not standard queues,
> we may need to distinguish them.
> I see it as a good helper for applications.
> Am I missing something obvious?
>
>
Moving the API to experimental results in the following error:
error: 'rte_eth_dev_is_rx_hairpin_queue' is deprecated (declared at /.autodirect/mtrswgwork/orika/pegasus04_share/dpdk.org/x86_64-native-linuxapp-gcc/include/rte_ethdev.h:4276): Symbol is not yet part of stable ABI [-Werror=deprecated-declarations]
I suggest that we remove the checks, in any case this checks are only on debug mode, and when using data path the user must be very careful and what he
is doing.
Best,
Ori
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
2019-11-05 12:53 0% ` Andrew Rybchenko
@ 2019-11-05 13:02 0% ` Thomas Monjalon
2019-11-05 13:23 3% ` Ori Kam
2019-11-05 13:41 0% ` Andrew Rybchenko
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-11-05 13:02 UTC (permalink / raw)
To: Andrew Rybchenko
Cc: Ferruh Yigit, Ori Kam, John McNamara, Marko Kovacevic, dev,
jingjing.wu, stephen, Jerin Jacob
05/11/2019 13:53, Andrew Rybchenko:
> On 11/5/19 3:51 PM, Thomas Monjalon wrote:
> > 05/11/2019 13:27, Andrew Rybchenko:
> >> On 11/5/19 3:23 PM, Ferruh Yigit wrote:
> >>> On 11/5/2019 12:12 PM, Andrew Rybchenko wrote:
> >>>> On 11/5/19 3:05 PM, Ferruh Yigit wrote:
> >>>>> On 11/5/2019 11:49 AM, Andrew Rybchenko wrote:
> >>>>>> On 11/5/19 2:36 PM, Ori Kam wrote:
> > >>>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
> >>>>>>>>> /**
> >>>>>>>>> + * @internal
> >>>>>>>>> + * Check if the selected Rx queue is hairpin queue.
> >>>>>>>>> + *
> >>>>>>>>> + * @param dev
> >>>>>>>>> + * Pointer to the selected device.
> >>>>>>>>> + * @param queue_id
> >>>>>>>>> + * The selected queue.
> >>>>>>>>> + *
> >>>>>>>>> + * @return
> >>>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
> >>>>>>>>> + */
> >>>>>>>>> +int
> >>>>>>>>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
> >>>>>>>> queue_id);
> >>>>>>>>> +
> >>>>>>>>> +/**
> >>>>>>>>> + * @internal
> >>>>>>>>> + * Check if the selected Tx queue is hairpin queue.
> >>>>>>>>> + *
> >>>>>>>>> + * @param dev
> >>>>>>>>> + * Pointer to the selected device.
> >>>>>>>>> + * @param queue_id
> >>>>>>>>> + * The selected queue.
> >>>>>>>>> + *
> >>>>>>>>> + * @return
> >>>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
> >>>>>>>>> + */
> >>>>>>>>> +int
> >>>>>>>>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
> >>>>>>>> queue_id);
> > [...]
> >>>>>>>> These are causing build error, thanks Jerin for catching, because they are
> >>>>>>>> internal and called by a public static inline API, so whoever calls
> >>>>>>>> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find
> >>>>>>>> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1],
> >>>>>>>>
> >>>>>>>> as far as I can see there are two options:
> >>>>>>>> 1) Remove these checks
> >>>>>>>> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead of internal
> >>>>>>>>
> >>>>>>>> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API
> >>>>>>>> we
> >>>>>>>> should go with (2) else (1).
> >>>>>>>>
> >>>>>>> I think we can skip the tests,
> >>>>>>> But it was Andrew request so we must get is response.
> >>>>>>> It was also his empathies that they should be internal.
> >>>>>> It is important for me to keep rte_eth_dev_state internal and
> >>>>>> few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline.
> >>>>> Are you saying you don't want to option to make
> >>>>> 'rte_eth_dev_is_rx_hairpin_queue()' static inline because it will force the
> >>>>> 'RTE_ETH_QUEUE_STATE_xxx' being public?
> >>>> Yes.
> >>> +1
> >>>
> >>>>>> I'm OK to make the function experimental or keep it internal
> >>>>>> (no API/ABI stability requirements) but externally visible (in .map).
> >>>>> I think we can't do this, add a function deceleration to the public header file
> >>>>> and add it to the .map file but keep it internal. Instead we can make it a
> >>>>> proper API and it should be experimental at least first release.
> >>>> We have discussed similar thing with Olivier recently [1].
> >>>>
> >>>> [1] http://inbox.dpdk.org/dev/20191030142938.bpi4txlrebqfq7uw@platinum/
> >>> Yes we can say they are internal but there won't be anything preventing
> >>> applications to use them.
> >>
> >> That's true, but making it internal says - don't use it.
> >> Anyway, I have no strong opinion on experimental vs internal.
> >>
> >>>>> The question above was do we need this API, or instead should remove the check
> >>>>> from rx/tx_burst APIs?
> >>>> I think these checks are useful to ensure that these functions
> >>>> are not used for hairpin queues. At least to catch it with debug
> >>>> enabled.
> >>> OK, if so what not make them proper API? Any concern on it?
> >
> > Why we should not use this API in applications?
>
> I think the valid question is why application needs the API.
> Basically I don't mind, just want to be sure that only required
> API is exposed.
Because hairpin queues are not standard queues,
we may need to distinguish them.
I see it as a good helper for applications.
Am I missing something obvious?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
2019-11-05 12:51 0% ` Thomas Monjalon
@ 2019-11-05 12:53 0% ` Andrew Rybchenko
2019-11-05 13:02 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-11-05 12:53 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Ferruh Yigit, Ori Kam, John McNamara, Marko Kovacevic, dev,
jingjing.wu, stephen, Jerin Jacob
On 11/5/19 3:51 PM, Thomas Monjalon wrote:
> 05/11/2019 13:27, Andrew Rybchenko:
>> On 11/5/19 3:23 PM, Ferruh Yigit wrote:
>>> On 11/5/2019 12:12 PM, Andrew Rybchenko wrote:
>>>> On 11/5/19 3:05 PM, Ferruh Yigit wrote:
>>>>> On 11/5/2019 11:49 AM, Andrew Rybchenko wrote:
>>>>>> On 11/5/19 2:36 PM, Ori Kam wrote:
> >>>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>>>>>> /**
>>>>>>>>> + * @internal
>>>>>>>>> + * Check if the selected Rx queue is hairpin queue.
>>>>>>>>> + *
>>>>>>>>> + * @param dev
>>>>>>>>> + * Pointer to the selected device.
>>>>>>>>> + * @param queue_id
>>>>>>>>> + * The selected queue.
>>>>>>>>> + *
>>>>>>>>> + * @return
>>>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>>>>>>> + */
>>>>>>>>> +int
>>>>>>>>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>>>>>>>> queue_id);
>>>>>>>>> +
>>>>>>>>> +/**
>>>>>>>>> + * @internal
>>>>>>>>> + * Check if the selected Tx queue is hairpin queue.
>>>>>>>>> + *
>>>>>>>>> + * @param dev
>>>>>>>>> + * Pointer to the selected device.
>>>>>>>>> + * @param queue_id
>>>>>>>>> + * The selected queue.
>>>>>>>>> + *
>>>>>>>>> + * @return
>>>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>>>>>>> + */
>>>>>>>>> +int
>>>>>>>>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>>>>>>>> queue_id);
> [...]
>>>>>>>> These are causing build error, thanks Jerin for catching, because they are
>>>>>>>> internal and called by a public static inline API, so whoever calls
>>>>>>>> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find
>>>>>>>> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1],
>>>>>>>>
>>>>>>>> as far as I can see there are two options:
>>>>>>>> 1) Remove these checks
>>>>>>>> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead of internal
>>>>>>>>
>>>>>>>> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API
>>>>>>>> we
>>>>>>>> should go with (2) else (1).
>>>>>>>>
>>>>>>> I think we can skip the tests,
>>>>>>> But it was Andrew request so we must get is response.
>>>>>>> It was also his empathies that they should be internal.
>>>>>> It is important for me to keep rte_eth_dev_state internal and
>>>>>> few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline.
>>>>> Are you saying you don't want to option to make
>>>>> 'rte_eth_dev_is_rx_hairpin_queue()' static inline because it will force the
>>>>> 'RTE_ETH_QUEUE_STATE_xxx' being public?
>>>> Yes.
>>> +1
>>>
>>>>>> I'm OK to make the function experimental or keep it internal
>>>>>> (no API/ABI stability requirements) but externally visible (in .map).
>>>>> I think we can't do this, add a function deceleration to the public header file
>>>>> and add it to the .map file but keep it internal. Instead we can make it a
>>>>> proper API and it should be experimental at least first release.
>>>> We have discussed similar thing with Olivier recently [1].
>>>>
>>>> [1] http://inbox.dpdk.org/dev/20191030142938.bpi4txlrebqfq7uw@platinum/
>>> Yes we can say they are internal but there won't be anything preventing
>>> applications to use them.
>>
>> That's true, but making it internal says - don't use it.
>> Anyway, I have no strong opinion on experimental vs internal.
>>
>>>>> The question above was do we need this API, or instead should remove the check
>>>>> from rx/tx_burst APIs?
>>>> I think these checks are useful to ensure that these functions
>>>> are not used for hairpin queues. At least to catch it with debug
>>>> enabled.
>>> OK, if so what not make them proper API? Any concern on it?
>
> Why we should not use this API in applications?
I think the valid question is why application needs the API.
Basically I don't mind, just want to be sure that only required
API is exposed.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
2019-11-05 12:27 0% ` Andrew Rybchenko
@ 2019-11-05 12:51 0% ` Thomas Monjalon
2019-11-05 12:53 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-11-05 12:51 UTC (permalink / raw)
To: Andrew Rybchenko
Cc: Ferruh Yigit, Ori Kam, John McNamara, Marko Kovacevic, dev,
jingjing.wu, stephen, Jerin Jacob
05/11/2019 13:27, Andrew Rybchenko:
> On 11/5/19 3:23 PM, Ferruh Yigit wrote:
> > On 11/5/2019 12:12 PM, Andrew Rybchenko wrote:
> >> On 11/5/19 3:05 PM, Ferruh Yigit wrote:
> >>> On 11/5/2019 11:49 AM, Andrew Rybchenko wrote:
> >>>> On 11/5/19 2:36 PM, Ori Kam wrote:
>>>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
> >>>>>>> /**
> >>>>>>> + * @internal
> >>>>>>> + * Check if the selected Rx queue is hairpin queue.
> >>>>>>> + *
> >>>>>>> + * @param dev
> >>>>>>> + * Pointer to the selected device.
> >>>>>>> + * @param queue_id
> >>>>>>> + * The selected queue.
> >>>>>>> + *
> >>>>>>> + * @return
> >>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
> >>>>>>> + */
> >>>>>>> +int
> >>>>>>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
> >>>>>> queue_id);
> >>>>>>> +
> >>>>>>> +/**
> >>>>>>> + * @internal
> >>>>>>> + * Check if the selected Tx queue is hairpin queue.
> >>>>>>> + *
> >>>>>>> + * @param dev
> >>>>>>> + * Pointer to the selected device.
> >>>>>>> + * @param queue_id
> >>>>>>> + * The selected queue.
> >>>>>>> + *
> >>>>>>> + * @return
> >>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
> >>>>>>> + */
> >>>>>>> +int
> >>>>>>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
> >>>>>> queue_id);
[...]
> >>>>>> These are causing build error, thanks Jerin for catching, because they are
> >>>>>> internal and called by a public static inline API, so whoever calls
> >>>>>> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find
> >>>>>> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1],
> >>>>>>
> >>>>>> as far as I can see there are two options:
> >>>>>> 1) Remove these checks
> >>>>>> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead of internal
> >>>>>>
> >>>>>> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API
> >>>>>> we
> >>>>>> should go with (2) else (1).
> >>>>>>
> >>>>> I think we can skip the tests,
> >>>>> But it was Andrew request so we must get is response.
> >>>>> It was also his empathies that they should be internal.
> >>>> It is important for me to keep rte_eth_dev_state internal and
> >>>> few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline.
> >>> Are you saying you don't want to option to make
> >>> 'rte_eth_dev_is_rx_hairpin_queue()' static inline because it will force the
> >>> 'RTE_ETH_QUEUE_STATE_xxx' being public?
> >> Yes.
> > +1
> >
> >>>> I'm OK to make the function experimental or keep it internal
> >>>> (no API/ABI stability requirements) but externally visible (in .map).
> >>> I think we can't do this, add a function deceleration to the public header file
> >>> and add it to the .map file but keep it internal. Instead we can make it a
> >>> proper API and it should be experimental at least first release.
> >> We have discussed similar thing with Olivier recently [1].
> >>
> >> [1] http://inbox.dpdk.org/dev/20191030142938.bpi4txlrebqfq7uw@platinum/
> > Yes we can say they are internal but there won't be anything preventing
> > applications to use them.
>
> That's true, but making it internal says - don't use it.
> Anyway, I have no strong opinion on experimental vs internal.
>
> >>> The question above was do we need this API, or instead should remove the check
> >>> from rx/tx_burst APIs?
> >> I think these checks are useful to ensure that these functions
> >> are not used for hairpin queues. At least to catch it with debug
> >> enabled.
> > OK, if so what not make them proper API? Any concern on it?
Why we should not use this API in applications?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
2019-11-05 12:23 0% ` Ferruh Yigit
@ 2019-11-05 12:27 0% ` Andrew Rybchenko
2019-11-05 12:51 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-11-05 12:27 UTC (permalink / raw)
To: Ferruh Yigit, Ori Kam, John McNamara, Marko Kovacevic, Thomas Monjalon
Cc: dev, jingjing.wu, stephen, Jerin Jacob
On 11/5/19 3:23 PM, Ferruh Yigit wrote:
> On 11/5/2019 12:12 PM, Andrew Rybchenko wrote:
>> On 11/5/19 3:05 PM, Ferruh Yigit wrote:
>>> On 11/5/2019 11:49 AM, Andrew Rybchenko wrote:
>>>> On 11/5/19 2:36 PM, Ori Kam wrote:
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>>> Sent: Tuesday, November 5, 2019 1:25 PM
>>>>>> To: Ori Kam <orika@mellanox.com>; John McNamara
>>>>>> <john.mcnamara@intel.com>; Marko Kovacevic
>>>>>> <marko.kovacevic@intel.com>; Thomas Monjalon <thomas@monjalon.net>;
>>>>>> Andrew Rybchenko <arybchenko@solarflare.com>
>>>>>> Cc: dev@dpdk.org; jingjing.wu@intel.com; stephen@networkplumber.org; Jerin
>>>>>> Jacob <jerin.jacob@caviumnetworks.com>
>>>>>> Subject: Re: [PATCH v7 02/14] ethdev: add support for hairpin queue
>>>>>>
>>>>>> On 10/30/2019 11:53 PM, Ori Kam wrote:
>>>>>>> This commit introduce hairpin queue type.
>>>>>>>
>>>>>>> The hairpin queue in build from Rx queue binded to Tx queue.
>>>>>>> It is used to offload traffic coming from the wire and redirect it back
>>>>>>> to the wire.
>>>>>>>
>>>>>>> There are 3 new functions:
>>>>>>> - rte_eth_dev_hairpin_capability_get
>>>>>>> - rte_eth_rx_hairpin_queue_setup
>>>>>>> - rte_eth_tx_hairpin_queue_setup
>>>>>>>
>>>>>>> In order to use the queue, there is a need to create rte_flow
>>>>>>> with queue / RSS action that targets one or more of the Rx queues.
>>>>>>>
>>>>>>> Signed-off-by: Ori Kam <orika@mellanox.com>
>>>>>>> Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>>>>> <...>
>>>>>>
>>>>>>> #include <rte_ethdev_core.h>
>>>>>>>
>>>>>>> /**
>>>>>>> + * @internal
>>>>>>> + * Check if the selected Rx queue is hairpin queue.
>>>>>>> + *
>>>>>>> + * @param dev
>>>>>>> + * Pointer to the selected device.
>>>>>>> + * @param queue_id
>>>>>>> + * The selected queue.
>>>>>>> + *
>>>>>>> + * @return
>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>>>>> + */
>>>>>>> +int
>>>>>>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>>>>>> queue_id);
>>>>>>> +
>>>>>>> +/**
>>>>>>> + * @internal
>>>>>>> + * Check if the selected Tx queue is hairpin queue.
>>>>>>> + *
>>>>>>> + * @param dev
>>>>>>> + * Pointer to the selected device.
>>>>>>> + * @param queue_id
>>>>>>> + * The selected queue.
>>>>>>> + *
>>>>>>> + * @return
>>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>>>>> + */
>>>>>>> +int
>>>>>>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>>>>>> queue_id);
>>>>>>> +
>>>>>>> +/**
>>>>>> If these functions are internal why there are in 'rte_ethdev.h' ?
>>>>>>
>>>>>>> *
>>>>>>> * Retrieve a burst of input packets from a receive queue of an Ethernet
>>>>>>> * device. The retrieved packets are stored in *rte_mbuf* structures whose
>>>>>>> @@ -4251,6 +4400,11 @@ int rte_eth_dev_adjust_nb_rx_tx_desc(uint16_t
>>>>>> port_id,
>>>>>>> RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n",
>>>>>> queue_id);
>>>>>>> return 0;
>>>>>>> }
>>>>>>> + if (rte_eth_dev_is_rx_hairpin_queue(dev, queue_id)) {
>>>>>>> + RTE_ETHDEV_LOG(ERR, "Rx burst failed, queue_id=%u is
>>>>>> hairpin queue\n",
>>>>>>> + queue_id);
>>>>>>> + return 0;
>>>>>>> + }
>>>>>>> #endif
>>>>>>> nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
>>>>>>> rx_pkts, nb_pkts);
>>>>>>> @@ -4517,6 +4671,11 @@ static inline int
>>>>>> rte_eth_tx_descriptor_status(uint16_t port_id,
>>>>>>> RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n",
>>>>>> queue_id);
>>>>>>> return 0;
>>>>>>> }
>>>>>>> + if (rte_eth_dev_is_tx_hairpin_queue(dev, queue_id)) {
>>>>>>> + RTE_ETHDEV_LOG(ERR, "Tx burst failed, queue_id=%u is
>>>>>> hairpin queue\n",
>>>>>>> + queue_id);
>>>>>>> + return 0;
>>>>>>> + }
>>>>>>> #endif
>>>>>> Hi Ori,
>>>>>>
>>>>>> These are causing build error, thanks Jerin for catching, because they are
>>>>>> internal and called by a public static inline API, so whoever calls
>>>>>> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find
>>>>>> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1],
>>>>>>
>>>>>> as far as I can see there are two options:
>>>>>> 1) Remove these checks
>>>>>> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead of internal
>>>>>>
>>>>>> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API
>>>>>> we
>>>>>> should go with (2) else (1).
>>>>>>
>>>>> I think we can skip the tests,
>>>>> But it was Andrew request so we must get is response.
>>>>> It was also his empathies that they should be internal.
>>>> It is important for me to keep rte_eth_dev_state internal and
>>>> few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline.
>>> Are you saying you don't want to option to make
>>> 'rte_eth_dev_is_rx_hairpin_queue()' static inline because it will force the
>>> 'RTE_ETH_QUEUE_STATE_xxx' being public?
>> Yes.
> +1
>
>>>> I'm OK to make the function experimental or keep it internal
>>>> (no API/ABI stability requirements) but externally visible (in .map).
>>> I think we can't do this, add a function deceleration to the public header file
>>> and add it to the .map file but keep it internal. Instead we can make it a
>>> proper API and it should be experimental at least first release.
>> We have discussed similar thing with Olivier recently [1].
>>
>> [1] http://inbox.dpdk.org/dev/20191030142938.bpi4txlrebqfq7uw@platinum/
> Yes we can say they are internal but there won't be anything preventing
> applications to use them.
That's true, but making it internal says - don't use it.
Anyway, I have no strong opinion on experimental vs internal.
>>> The question above was do we need this API, or instead should remove the check
>>> from rx/tx_burst APIs?
>> I think these checks are useful to ensure that these functions
>> are not used for hairpin queues. At least to catch it with debug
>> enabled.
> OK, if so what not make them proper API? Any concern on it?
>
>>>>>> [1]
>>>>>> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_eth_rx':
>>>>>> rte_event_eth_rx_adapter.c:(.text+0x1728): undefined reference to
>>>>>> `rte_eth_dev_is_rx_hairpin_queue'
>>>>>> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_service_func':
>>>>>> rte_event_eth_rx_adapter.c:(.text+0x22ab): undefined reference to
>>>>>> `rte_eth_dev_is_rx_hairpin_queue'
>>>>>> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function `txa_service_buffer_retry':
>>>>>> rte_event_eth_tx_adapter.c:(.text+0xa43): undefined reference to
>>>>>> `rte_eth_dev_is_tx_hairpin_queue'
>>>>>> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function `txa_service_func':
>>>>>> rte_event_eth_tx_adapter.c:(.text+0xe7d): undefined reference to
>>>>>> `rte_eth_dev_is_tx_hairpin_queue'
>>>>>> /usr/bin/ld: rte_event_eth_tx_adapter.c:(.text+0x1155): undefined reference to
>>>>>> `rte_eth_dev_is_tx_hairpin_queue'
>>>>>> collect2: error: ld returned 1 exit status
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
2019-11-05 12:12 0% ` Andrew Rybchenko
@ 2019-11-05 12:23 0% ` Ferruh Yigit
2019-11-05 12:27 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-11-05 12:23 UTC (permalink / raw)
To: Andrew Rybchenko, Ori Kam, John McNamara, Marko Kovacevic,
Thomas Monjalon
Cc: dev, jingjing.wu, stephen, Jerin Jacob
On 11/5/2019 12:12 PM, Andrew Rybchenko wrote:
> On 11/5/19 3:05 PM, Ferruh Yigit wrote:
>> On 11/5/2019 11:49 AM, Andrew Rybchenko wrote:
>>> On 11/5/19 2:36 PM, Ori Kam wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>> Sent: Tuesday, November 5, 2019 1:25 PM
>>>>> To: Ori Kam <orika@mellanox.com>; John McNamara
>>>>> <john.mcnamara@intel.com>; Marko Kovacevic
>>>>> <marko.kovacevic@intel.com>; Thomas Monjalon <thomas@monjalon.net>;
>>>>> Andrew Rybchenko <arybchenko@solarflare.com>
>>>>> Cc: dev@dpdk.org; jingjing.wu@intel.com; stephen@networkplumber.org; Jerin
>>>>> Jacob <jerin.jacob@caviumnetworks.com>
>>>>> Subject: Re: [PATCH v7 02/14] ethdev: add support for hairpin queue
>>>>>
>>>>> On 10/30/2019 11:53 PM, Ori Kam wrote:
>>>>>> This commit introduce hairpin queue type.
>>>>>>
>>>>>> The hairpin queue in build from Rx queue binded to Tx queue.
>>>>>> It is used to offload traffic coming from the wire and redirect it back
>>>>>> to the wire.
>>>>>>
>>>>>> There are 3 new functions:
>>>>>> - rte_eth_dev_hairpin_capability_get
>>>>>> - rte_eth_rx_hairpin_queue_setup
>>>>>> - rte_eth_tx_hairpin_queue_setup
>>>>>>
>>>>>> In order to use the queue, there is a need to create rte_flow
>>>>>> with queue / RSS action that targets one or more of the Rx queues.
>>>>>>
>>>>>> Signed-off-by: Ori Kam <orika@mellanox.com>
>>>>>> Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>>>>
>>>>> <...>
>>>>>
>>>>>> #include <rte_ethdev_core.h>
>>>>>>
>>>>>> /**
>>>>>> + * @internal
>>>>>> + * Check if the selected Rx queue is hairpin queue.
>>>>>> + *
>>>>>> + * @param dev
>>>>>> + * Pointer to the selected device.
>>>>>> + * @param queue_id
>>>>>> + * The selected queue.
>>>>>> + *
>>>>>> + * @return
>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>>>> + */
>>>>>> +int
>>>>>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>>>>> queue_id);
>>>>>> +
>>>>>> +/**
>>>>>> + * @internal
>>>>>> + * Check if the selected Tx queue is hairpin queue.
>>>>>> + *
>>>>>> + * @param dev
>>>>>> + * Pointer to the selected device.
>>>>>> + * @param queue_id
>>>>>> + * The selected queue.
>>>>>> + *
>>>>>> + * @return
>>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>>>> + */
>>>>>> +int
>>>>>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>>>>> queue_id);
>>>>>> +
>>>>>> +/**
>>>>>
>>>>> If these functions are internal why there are in 'rte_ethdev.h' ?
>>>>>
>>>>>> *
>>>>>> * Retrieve a burst of input packets from a receive queue of an Ethernet
>>>>>> * device. The retrieved packets are stored in *rte_mbuf* structures whose
>>>>>> @@ -4251,6 +4400,11 @@ int rte_eth_dev_adjust_nb_rx_tx_desc(uint16_t
>>>>> port_id,
>>>>>> RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n",
>>>>> queue_id);
>>>>>> return 0;
>>>>>> }
>>>>>> + if (rte_eth_dev_is_rx_hairpin_queue(dev, queue_id)) {
>>>>>> + RTE_ETHDEV_LOG(ERR, "Rx burst failed, queue_id=%u is
>>>>> hairpin queue\n",
>>>>>> + queue_id);
>>>>>> + return 0;
>>>>>> + }
>>>>>> #endif
>>>>>> nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
>>>>>> rx_pkts, nb_pkts);
>>>>>> @@ -4517,6 +4671,11 @@ static inline int
>>>>> rte_eth_tx_descriptor_status(uint16_t port_id,
>>>>>> RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n",
>>>>> queue_id);
>>>>>> return 0;
>>>>>> }
>>>>>> + if (rte_eth_dev_is_tx_hairpin_queue(dev, queue_id)) {
>>>>>> + RTE_ETHDEV_LOG(ERR, "Tx burst failed, queue_id=%u is
>>>>> hairpin queue\n",
>>>>>> + queue_id);
>>>>>> + return 0;
>>>>>> + }
>>>>>> #endif
>>>>>
>>>>> Hi Ori,
>>>>>
>>>>> These are causing build error, thanks Jerin for catching, because they are
>>>>> internal and called by a public static inline API, so whoever calls
>>>>> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find
>>>>> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1],
>>>>>
>>>>> as far as I can see there are two options:
>>>>> 1) Remove these checks
>>>>> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead of internal
>>>>>
>>>>> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API
>>>>> we
>>>>> should go with (2) else (1).
>>>>>
>>>>
>>>> I think we can skip the tests,
>>>> But it was Andrew request so we must get is response.
>>>> It was also his empathies that they should be internal.
>>>
>>> It is important for me to keep rte_eth_dev_state internal and
>>> few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline.
>>
>> Are you saying you don't want to option to make
>> 'rte_eth_dev_is_rx_hairpin_queue()' static inline because it will force the
>> 'RTE_ETH_QUEUE_STATE_xxx' being public?
>
> Yes.
+1
>
>>> I'm OK to make the function experimental or keep it internal
>>> (no API/ABI stability requirements) but externally visible (in .map).
>>
>> I think we can't do this, add a function deceleration to the public header file
>> and add it to the .map file but keep it internal. Instead we can make it a
>> proper API and it should be experimental at least first release.
>
> We have discussed similar thing with Olivier recently [1].
>
> [1] http://inbox.dpdk.org/dev/20191030142938.bpi4txlrebqfq7uw@platinum/
Yes we can say they are internal but there won't be anything preventing
applications to use them.
>
>> The question above was do we need this API, or instead should remove the check
>> from rx/tx_burst APIs?
>
> I think these checks are useful to ensure that these functions
> are not used for hairpin queues. At least to catch it with debug
> enabled.
OK, if so what not make them proper API? Any concern on it?
>
>>>>> [1]
>>>>> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_eth_rx':
>>>>> rte_event_eth_rx_adapter.c:(.text+0x1728): undefined reference to
>>>>> `rte_eth_dev_is_rx_hairpin_queue'
>>>>> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_service_func':
>>>>> rte_event_eth_rx_adapter.c:(.text+0x22ab): undefined reference to
>>>>> `rte_eth_dev_is_rx_hairpin_queue'
>>>>> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function `txa_service_buffer_retry':
>>>>> rte_event_eth_tx_adapter.c:(.text+0xa43): undefined reference to
>>>>> `rte_eth_dev_is_tx_hairpin_queue'
>>>>> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function `txa_service_func':
>>>>> rte_event_eth_tx_adapter.c:(.text+0xe7d): undefined reference to
>>>>> `rte_eth_dev_is_tx_hairpin_queue'
>>>>> /usr/bin/ld: rte_event_eth_tx_adapter.c:(.text+0x1155): undefined reference to
>>>>> `rte_eth_dev_is_tx_hairpin_queue'
>>>>> collect2: error: ld returned 1 exit status
>>>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
2019-11-05 12:05 0% ` Ferruh Yigit
@ 2019-11-05 12:12 0% ` Andrew Rybchenko
2019-11-05 12:23 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-11-05 12:12 UTC (permalink / raw)
To: Ferruh Yigit, Ori Kam, John McNamara, Marko Kovacevic, Thomas Monjalon
Cc: dev, jingjing.wu, stephen, Jerin Jacob
On 11/5/19 3:05 PM, Ferruh Yigit wrote:
> On 11/5/2019 11:49 AM, Andrew Rybchenko wrote:
>> On 11/5/19 2:36 PM, Ori Kam wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>>> Sent: Tuesday, November 5, 2019 1:25 PM
>>>> To: Ori Kam <orika@mellanox.com>; John McNamara
>>>> <john.mcnamara@intel.com>; Marko Kovacevic
>>>> <marko.kovacevic@intel.com>; Thomas Monjalon <thomas@monjalon.net>;
>>>> Andrew Rybchenko <arybchenko@solarflare.com>
>>>> Cc: dev@dpdk.org; jingjing.wu@intel.com; stephen@networkplumber.org; Jerin
>>>> Jacob <jerin.jacob@caviumnetworks.com>
>>>> Subject: Re: [PATCH v7 02/14] ethdev: add support for hairpin queue
>>>>
>>>> On 10/30/2019 11:53 PM, Ori Kam wrote:
>>>>> This commit introduce hairpin queue type.
>>>>>
>>>>> The hairpin queue in build from Rx queue binded to Tx queue.
>>>>> It is used to offload traffic coming from the wire and redirect it back
>>>>> to the wire.
>>>>>
>>>>> There are 3 new functions:
>>>>> - rte_eth_dev_hairpin_capability_get
>>>>> - rte_eth_rx_hairpin_queue_setup
>>>>> - rte_eth_tx_hairpin_queue_setup
>>>>>
>>>>> In order to use the queue, there is a need to create rte_flow
>>>>> with queue / RSS action that targets one or more of the Rx queues.
>>>>>
>>>>> Signed-off-by: Ori Kam <orika@mellanox.com>
>>>>> Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>>>
>>>> <...>
>>>>
>>>>> #include <rte_ethdev_core.h>
>>>>>
>>>>> /**
>>>>> + * @internal
>>>>> + * Check if the selected Rx queue is hairpin queue.
>>>>> + *
>>>>> + * @param dev
>>>>> + * Pointer to the selected device.
>>>>> + * @param queue_id
>>>>> + * The selected queue.
>>>>> + *
>>>>> + * @return
>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>>> + */
>>>>> +int
>>>>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>>>> queue_id);
>>>>> +
>>>>> +/**
>>>>> + * @internal
>>>>> + * Check if the selected Tx queue is hairpin queue.
>>>>> + *
>>>>> + * @param dev
>>>>> + * Pointer to the selected device.
>>>>> + * @param queue_id
>>>>> + * The selected queue.
>>>>> + *
>>>>> + * @return
>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>>> + */
>>>>> +int
>>>>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>>>> queue_id);
>>>>> +
>>>>> +/**
>>>>
>>>> If these functions are internal why there are in 'rte_ethdev.h' ?
>>>>
>>>>> *
>>>>> * Retrieve a burst of input packets from a receive queue of an Ethernet
>>>>> * device. The retrieved packets are stored in *rte_mbuf* structures whose
>>>>> @@ -4251,6 +4400,11 @@ int rte_eth_dev_adjust_nb_rx_tx_desc(uint16_t
>>>> port_id,
>>>>> RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n",
>>>> queue_id);
>>>>> return 0;
>>>>> }
>>>>> + if (rte_eth_dev_is_rx_hairpin_queue(dev, queue_id)) {
>>>>> + RTE_ETHDEV_LOG(ERR, "Rx burst failed, queue_id=%u is
>>>> hairpin queue\n",
>>>>> + queue_id);
>>>>> + return 0;
>>>>> + }
>>>>> #endif
>>>>> nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
>>>>> rx_pkts, nb_pkts);
>>>>> @@ -4517,6 +4671,11 @@ static inline int
>>>> rte_eth_tx_descriptor_status(uint16_t port_id,
>>>>> RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n",
>>>> queue_id);
>>>>> return 0;
>>>>> }
>>>>> + if (rte_eth_dev_is_tx_hairpin_queue(dev, queue_id)) {
>>>>> + RTE_ETHDEV_LOG(ERR, "Tx burst failed, queue_id=%u is
>>>> hairpin queue\n",
>>>>> + queue_id);
>>>>> + return 0;
>>>>> + }
>>>>> #endif
>>>>
>>>> Hi Ori,
>>>>
>>>> These are causing build error, thanks Jerin for catching, because they are
>>>> internal and called by a public static inline API, so whoever calls
>>>> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find
>>>> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1],
>>>>
>>>> as far as I can see there are two options:
>>>> 1) Remove these checks
>>>> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead of internal
>>>>
>>>> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API
>>>> we
>>>> should go with (2) else (1).
>>>>
>>>
>>> I think we can skip the tests,
>>> But it was Andrew request so we must get is response.
>>> It was also his empathies that they should be internal.
>>
>> It is important for me to keep rte_eth_dev_state internal and
>> few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline.
>
> Are you saying you don't want to option to make
> 'rte_eth_dev_is_rx_hairpin_queue()' static inline because it will force the
> 'RTE_ETH_QUEUE_STATE_xxx' being public?
Yes.
>> I'm OK to make the function experimental or keep it internal
>> (no API/ABI stability requirements) but externally visible (in .map).
>
> I think we can't do this, add a function deceleration to the public header file
> and add it to the .map file but keep it internal. Instead we can make it a
> proper API and it should be experimental at least first release.
We have discussed similar thing with Olivier recently [1].
[1] http://inbox.dpdk.org/dev/20191030142938.bpi4txlrebqfq7uw@platinum/
> The question above was do we need this API, or instead should remove the check
> from rx/tx_burst APIs?
I think these checks are useful to ensure that these functions
are not used for hairpin queues. At least to catch it with debug
enabled.
>>>> [1]
>>>> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_eth_rx':
>>>> rte_event_eth_rx_adapter.c:(.text+0x1728): undefined reference to
>>>> `rte_eth_dev_is_rx_hairpin_queue'
>>>> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_service_func':
>>>> rte_event_eth_rx_adapter.c:(.text+0x22ab): undefined reference to
>>>> `rte_eth_dev_is_rx_hairpin_queue'
>>>> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function `txa_service_buffer_retry':
>>>> rte_event_eth_tx_adapter.c:(.text+0xa43): undefined reference to
>>>> `rte_eth_dev_is_tx_hairpin_queue'
>>>> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function `txa_service_func':
>>>> rte_event_eth_tx_adapter.c:(.text+0xe7d): undefined reference to
>>>> `rte_eth_dev_is_tx_hairpin_queue'
>>>> /usr/bin/ld: rte_event_eth_tx_adapter.c:(.text+0x1155): undefined reference to
>>>> `rte_eth_dev_is_tx_hairpin_queue'
>>>> collect2: error: ld returned 1 exit status
>>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
2019-11-05 11:49 3% ` Andrew Rybchenko
2019-11-05 12:00 0% ` Ori Kam
@ 2019-11-05 12:05 0% ` Ferruh Yigit
2019-11-05 12:12 0% ` Andrew Rybchenko
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-11-05 12:05 UTC (permalink / raw)
To: Andrew Rybchenko, Ori Kam, John McNamara, Marko Kovacevic,
Thomas Monjalon
Cc: dev, jingjing.wu, stephen, Jerin Jacob
On 11/5/2019 11:49 AM, Andrew Rybchenko wrote:
> On 11/5/19 2:36 PM, Ori Kam wrote:
>>
>>
>>> -----Original Message-----
>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>> Sent: Tuesday, November 5, 2019 1:25 PM
>>> To: Ori Kam <orika@mellanox.com>; John McNamara
>>> <john.mcnamara@intel.com>; Marko Kovacevic
>>> <marko.kovacevic@intel.com>; Thomas Monjalon <thomas@monjalon.net>;
>>> Andrew Rybchenko <arybchenko@solarflare.com>
>>> Cc: dev@dpdk.org; jingjing.wu@intel.com; stephen@networkplumber.org; Jerin
>>> Jacob <jerin.jacob@caviumnetworks.com>
>>> Subject: Re: [PATCH v7 02/14] ethdev: add support for hairpin queue
>>>
>>> On 10/30/2019 11:53 PM, Ori Kam wrote:
>>>> This commit introduce hairpin queue type.
>>>>
>>>> The hairpin queue in build from Rx queue binded to Tx queue.
>>>> It is used to offload traffic coming from the wire and redirect it back
>>>> to the wire.
>>>>
>>>> There are 3 new functions:
>>>> - rte_eth_dev_hairpin_capability_get
>>>> - rte_eth_rx_hairpin_queue_setup
>>>> - rte_eth_tx_hairpin_queue_setup
>>>>
>>>> In order to use the queue, there is a need to create rte_flow
>>>> with queue / RSS action that targets one or more of the Rx queues.
>>>>
>>>> Signed-off-by: Ori Kam <orika@mellanox.com>
>>>> Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>>
>>> <...>
>>>
>>>> #include <rte_ethdev_core.h>
>>>>
>>>> /**
>>>> + * @internal
>>>> + * Check if the selected Rx queue is hairpin queue.
>>>> + *
>>>> + * @param dev
>>>> + * Pointer to the selected device.
>>>> + * @param queue_id
>>>> + * The selected queue.
>>>> + *
>>>> + * @return
>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>> + */
>>>> +int
>>>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>>> queue_id);
>>>> +
>>>> +/**
>>>> + * @internal
>>>> + * Check if the selected Tx queue is hairpin queue.
>>>> + *
>>>> + * @param dev
>>>> + * Pointer to the selected device.
>>>> + * @param queue_id
>>>> + * The selected queue.
>>>> + *
>>>> + * @return
>>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>>> + */
>>>> +int
>>>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>>> queue_id);
>>>> +
>>>> +/**
>>>
>>> If these functions are internal why there are in 'rte_ethdev.h' ?
>>>
>>>> *
>>>> * Retrieve a burst of input packets from a receive queue of an Ethernet
>>>> * device. The retrieved packets are stored in *rte_mbuf* structures whose
>>>> @@ -4251,6 +4400,11 @@ int rte_eth_dev_adjust_nb_rx_tx_desc(uint16_t
>>> port_id,
>>>> RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n",
>>> queue_id);
>>>> return 0;
>>>> }
>>>> + if (rte_eth_dev_is_rx_hairpin_queue(dev, queue_id)) {
>>>> + RTE_ETHDEV_LOG(ERR, "Rx burst failed, queue_id=%u is
>>> hairpin queue\n",
>>>> + queue_id);
>>>> + return 0;
>>>> + }
>>>> #endif
>>>> nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
>>>> rx_pkts, nb_pkts);
>>>> @@ -4517,6 +4671,11 @@ static inline int
>>> rte_eth_tx_descriptor_status(uint16_t port_id,
>>>> RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n",
>>> queue_id);
>>>> return 0;
>>>> }
>>>> + if (rte_eth_dev_is_tx_hairpin_queue(dev, queue_id)) {
>>>> + RTE_ETHDEV_LOG(ERR, "Tx burst failed, queue_id=%u is
>>> hairpin queue\n",
>>>> + queue_id);
>>>> + return 0;
>>>> + }
>>>> #endif
>>>
>>> Hi Ori,
>>>
>>> These are causing build error, thanks Jerin for catching, because they are
>>> internal and called by a public static inline API, so whoever calls
>>> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find
>>> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1],
>>>
>>> as far as I can see there are two options:
>>> 1) Remove these checks
>>> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead of internal
>>>
>>> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API
>>> we
>>> should go with (2) else (1).
>>>
>>
>> I think we can skip the tests,
>> But it was Andrew request so we must get is response.
>> It was also his empathies that they should be internal.
>
> It is important for me to keep rte_eth_dev_state internal and
> few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline.
Are you saying you don't want to option to make
'rte_eth_dev_is_rx_hairpin_queue()' static inline because it will force the
'RTE_ETH_QUEUE_STATE_xxx' being public?
> I'm OK to make the function experimental or keep it internal
> (no API/ABI stability requirements) but externally visible (in .map).
I think we can't do this, add a function deceleration to the public header file
and add it to the .map file but keep it internal. Instead we can make it a
proper API and it should be experimental at least first release.
The question above was do we need this API, or instead should remove the check
from rx/tx_burst APIs?
>
>>> [1]
>>> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_eth_rx':
>>> rte_event_eth_rx_adapter.c:(.text+0x1728): undefined reference to
>>> `rte_eth_dev_is_rx_hairpin_queue'
>>> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_service_func':
>>> rte_event_eth_rx_adapter.c:(.text+0x22ab): undefined reference to
>>> `rte_eth_dev_is_rx_hairpin_queue'
>>> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function `txa_service_buffer_retry':
>>> rte_event_eth_tx_adapter.c:(.text+0xa43): undefined reference to
>>> `rte_eth_dev_is_tx_hairpin_queue'
>>> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function `txa_service_func':
>>> rte_event_eth_tx_adapter.c:(.text+0xe7d): undefined reference to
>>> `rte_eth_dev_is_tx_hairpin_queue'
>>> /usr/bin/ld: rte_event_eth_tx_adapter.c:(.text+0x1155): undefined reference to
>>> `rte_eth_dev_is_tx_hairpin_queue'
>>> collect2: error: ld returned 1 exit status
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
2019-11-05 11:49 3% ` Andrew Rybchenko
@ 2019-11-05 12:00 0% ` Ori Kam
2019-11-05 12:05 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ori Kam @ 2019-11-05 12:00 UTC (permalink / raw)
To: Andrew Rybchenko, Ferruh Yigit, John McNamara, Marko Kovacevic,
Thomas Monjalon
Cc: dev, jingjing.wu, stephen, Jerin Jacob
> -----Original Message-----
> From: Andrew Rybchenko <arybchenko@solarflare.com>
> Sent: Tuesday, November 5, 2019 1:49 PM
> To: Ori Kam <orika@mellanox.com>; Ferruh Yigit <ferruh.yigit@intel.com>;
> John McNamara <john.mcnamara@intel.com>; Marko Kovacevic
> <marko.kovacevic@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> Cc: dev@dpdk.org; jingjing.wu@intel.com; stephen@networkplumber.org; Jerin
> Jacob <jerin.jacob@caviumnetworks.com>
> Subject: Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
>
> On 11/5/19 2:36 PM, Ori Kam wrote:
> >
> >
> >> -----Original Message-----
> >> From: Ferruh Yigit <ferruh.yigit@intel.com>
> >> Sent: Tuesday, November 5, 2019 1:25 PM
> >> To: Ori Kam <orika@mellanox.com>; John McNamara
> >> <john.mcnamara@intel.com>; Marko Kovacevic
> >> <marko.kovacevic@intel.com>; Thomas Monjalon <thomas@monjalon.net>;
> >> Andrew Rybchenko <arybchenko@solarflare.com>
> >> Cc: dev@dpdk.org; jingjing.wu@intel.com; stephen@networkplumber.org;
> Jerin
> >> Jacob <jerin.jacob@caviumnetworks.com>
> >> Subject: Re: [PATCH v7 02/14] ethdev: add support for hairpin queue
> >>
> >> On 10/30/2019 11:53 PM, Ori Kam wrote:
> >>> This commit introduce hairpin queue type.
> >>>
> >>> The hairpin queue in build from Rx queue binded to Tx queue.
> >>> It is used to offload traffic coming from the wire and redirect it back
> >>> to the wire.
> >>>
> >>> There are 3 new functions:
> >>> - rte_eth_dev_hairpin_capability_get
> >>> - rte_eth_rx_hairpin_queue_setup
> >>> - rte_eth_tx_hairpin_queue_setup
> >>>
> >>> In order to use the queue, there is a need to create rte_flow
> >>> with queue / RSS action that targets one or more of the Rx queues.
> >>>
> >>> Signed-off-by: Ori Kam <orika@mellanox.com>
> >>> Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
> >>
> >> <...>
> >>
> >>> #include <rte_ethdev_core.h>
> >>>
> >>> /**
> >>> + * @internal
> >>> + * Check if the selected Rx queue is hairpin queue.
> >>> + *
> >>> + * @param dev
> >>> + * Pointer to the selected device.
> >>> + * @param queue_id
> >>> + * The selected queue.
> >>> + *
> >>> + * @return
> >>> + * - (1) if the queue is hairpin queue, 0 otherwise.
> >>> + */
> >>> +int
> >>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
> >> queue_id);
> >>> +
> >>> +/**
> >>> + * @internal
> >>> + * Check if the selected Tx queue is hairpin queue.
> >>> + *
> >>> + * @param dev
> >>> + * Pointer to the selected device.
> >>> + * @param queue_id
> >>> + * The selected queue.
> >>> + *
> >>> + * @return
> >>> + * - (1) if the queue is hairpin queue, 0 otherwise.
> >>> + */
> >>> +int
> >>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
> >> queue_id);
> >>> +
> >>> +/**
> >>
> >> If these functions are internal why there are in 'rte_ethdev.h' ?
> >>
> >>> *
> >>> * Retrieve a burst of input packets from a receive queue of an Ethernet
> >>> * device. The retrieved packets are stored in *rte_mbuf* structures
> whose
> >>> @@ -4251,6 +4400,11 @@ int rte_eth_dev_adjust_nb_rx_tx_desc(uint16_t
> >> port_id,
> >>> RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n",
> >> queue_id);
> >>> return 0;
> >>> }
> >>> + if (rte_eth_dev_is_rx_hairpin_queue(dev, queue_id)) {
> >>> + RTE_ETHDEV_LOG(ERR, "Rx burst failed, queue_id=%u is
> >> hairpin queue\n",
> >>> + queue_id);
> >>> + return 0;
> >>> + }
> >>> #endif
> >>> nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
> >>> rx_pkts, nb_pkts);
> >>> @@ -4517,6 +4671,11 @@ static inline int
> >> rte_eth_tx_descriptor_status(uint16_t port_id,
> >>> RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n",
> >> queue_id);
> >>> return 0;
> >>> }
> >>> + if (rte_eth_dev_is_tx_hairpin_queue(dev, queue_id)) {
> >>> + RTE_ETHDEV_LOG(ERR, "Tx burst failed, queue_id=%u is
> >> hairpin queue\n",
> >>> + queue_id);
> >>> + return 0;
> >>> + }
> >>> #endif
> >>
> >> Hi Ori,
> >>
> >> These are causing build error, thanks Jerin for catching, because they are
> >> internal and called by a public static inline API, so whoever calls
> >> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find
> >> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1],
> >>
> >> as far as I can see there are two options:
> >> 1) Remove these checks
> >> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead of
> internal
> >>
> >> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API
> >> we
> >> should go with (2) else (1).
> >>
> >
> > I think we can skip the tests,
> > But it was Andrew request so we must get is response.
> > It was also his empathies that they should be internal.
>
> It is important for me to keep rte_eth_dev_state internal and
> few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline.
> I'm OK to make the function experimental or keep it internal
> (no API/ABI stability requirements) but externally visible (in .map).
>
Just to make sure I understand you mean just to add the is_rx_hairpin_queue to the map file right?
> >> [1]
> >> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_eth_rx':
> >> rte_event_eth_rx_adapter.c:(.text+0x1728): undefined reference to
> >> `rte_eth_dev_is_rx_hairpin_queue'
> >> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_service_func':
> >> rte_event_eth_rx_adapter.c:(.text+0x22ab): undefined reference to
> >> `rte_eth_dev_is_rx_hairpin_queue'
> >> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function
> `txa_service_buffer_retry':
> >> rte_event_eth_tx_adapter.c:(.text+0xa43): undefined reference to
> >> `rte_eth_dev_is_tx_hairpin_queue'
> >> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function `txa_service_func':
> >> rte_event_eth_tx_adapter.c:(.text+0xe7d): undefined reference to
> >> `rte_eth_dev_is_tx_hairpin_queue'
> >> /usr/bin/ld: rte_event_eth_tx_adapter.c:(.text+0x1155): undefined reference
> to
> >> `rte_eth_dev_is_tx_hairpin_queue'
> >> collect2: error: ld returned 1 exit status
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue
@ 2019-11-05 11:49 3% ` Andrew Rybchenko
2019-11-05 12:00 0% ` Ori Kam
2019-11-05 12:05 0% ` Ferruh Yigit
0 siblings, 2 replies; 200+ results
From: Andrew Rybchenko @ 2019-11-05 11:49 UTC (permalink / raw)
To: Ori Kam, Ferruh Yigit, John McNamara, Marko Kovacevic, Thomas Monjalon
Cc: dev, jingjing.wu, stephen, Jerin Jacob
On 11/5/19 2:36 PM, Ori Kam wrote:
>
>
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> Sent: Tuesday, November 5, 2019 1:25 PM
>> To: Ori Kam <orika@mellanox.com>; John McNamara
>> <john.mcnamara@intel.com>; Marko Kovacevic
>> <marko.kovacevic@intel.com>; Thomas Monjalon <thomas@monjalon.net>;
>> Andrew Rybchenko <arybchenko@solarflare.com>
>> Cc: dev@dpdk.org; jingjing.wu@intel.com; stephen@networkplumber.org; Jerin
>> Jacob <jerin.jacob@caviumnetworks.com>
>> Subject: Re: [PATCH v7 02/14] ethdev: add support for hairpin queue
>>
>> On 10/30/2019 11:53 PM, Ori Kam wrote:
>>> This commit introduce hairpin queue type.
>>>
>>> The hairpin queue in build from Rx queue binded to Tx queue.
>>> It is used to offload traffic coming from the wire and redirect it back
>>> to the wire.
>>>
>>> There are 3 new functions:
>>> - rte_eth_dev_hairpin_capability_get
>>> - rte_eth_rx_hairpin_queue_setup
>>> - rte_eth_tx_hairpin_queue_setup
>>>
>>> In order to use the queue, there is a need to create rte_flow
>>> with queue / RSS action that targets one or more of the Rx queues.
>>>
>>> Signed-off-by: Ori Kam <orika@mellanox.com>
>>> Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>
>> <...>
>>
>>> #include <rte_ethdev_core.h>
>>>
>>> /**
>>> + * @internal
>>> + * Check if the selected Rx queue is hairpin queue.
>>> + *
>>> + * @param dev
>>> + * Pointer to the selected device.
>>> + * @param queue_id
>>> + * The selected queue.
>>> + *
>>> + * @return
>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>> + */
>>> +int
>>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>> queue_id);
>>> +
>>> +/**
>>> + * @internal
>>> + * Check if the selected Tx queue is hairpin queue.
>>> + *
>>> + * @param dev
>>> + * Pointer to the selected device.
>>> + * @param queue_id
>>> + * The selected queue.
>>> + *
>>> + * @return
>>> + * - (1) if the queue is hairpin queue, 0 otherwise.
>>> + */
>>> +int
>>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev, uint16_t
>> queue_id);
>>> +
>>> +/**
>>
>> If these functions are internal why there are in 'rte_ethdev.h' ?
>>
>>> *
>>> * Retrieve a burst of input packets from a receive queue of an Ethernet
>>> * device. The retrieved packets are stored in *rte_mbuf* structures whose
>>> @@ -4251,6 +4400,11 @@ int rte_eth_dev_adjust_nb_rx_tx_desc(uint16_t
>> port_id,
>>> RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n",
>> queue_id);
>>> return 0;
>>> }
>>> + if (rte_eth_dev_is_rx_hairpin_queue(dev, queue_id)) {
>>> + RTE_ETHDEV_LOG(ERR, "Rx burst failed, queue_id=%u is
>> hairpin queue\n",
>>> + queue_id);
>>> + return 0;
>>> + }
>>> #endif
>>> nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
>>> rx_pkts, nb_pkts);
>>> @@ -4517,6 +4671,11 @@ static inline int
>> rte_eth_tx_descriptor_status(uint16_t port_id,
>>> RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n",
>> queue_id);
>>> return 0;
>>> }
>>> + if (rte_eth_dev_is_tx_hairpin_queue(dev, queue_id)) {
>>> + RTE_ETHDEV_LOG(ERR, "Tx burst failed, queue_id=%u is
>> hairpin queue\n",
>>> + queue_id);
>>> + return 0;
>>> + }
>>> #endif
>>
>> Hi Ori,
>>
>> These are causing build error, thanks Jerin for catching, because they are
>> internal and called by a public static inline API, so whoever calls
>> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find
>> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1],
>>
>> as far as I can see there are two options:
>> 1) Remove these checks
>> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead of internal
>>
>> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API
>> we
>> should go with (2) else (1).
>>
>
> I think we can skip the tests,
> But it was Andrew request so we must get is response.
> It was also his empathies that they should be internal.
It is important for me to keep rte_eth_dev_state internal and
few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline.
I'm OK to make the function experimental or keep it internal
(no API/ABI stability requirements) but externally visible (in .map).
>> [1]
>> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_eth_rx':
>> rte_event_eth_rx_adapter.c:(.text+0x1728): undefined reference to
>> `rte_eth_dev_is_rx_hairpin_queue'
>> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_service_func':
>> rte_event_eth_rx_adapter.c:(.text+0x22ab): undefined reference to
>> `rte_eth_dev_is_rx_hairpin_queue'
>> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function `txa_service_buffer_retry':
>> rte_event_eth_tx_adapter.c:(.text+0xa43): undefined reference to
>> `rte_eth_dev_is_tx_hairpin_queue'
>> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function `txa_service_func':
>> rte_event_eth_tx_adapter.c:(.text+0xe7d): undefined reference to
>> `rte_eth_dev_is_tx_hairpin_queue'
>> /usr/bin/ld: rte_event_eth_tx_adapter.c:(.text+0x1155): undefined reference to
>> `rte_eth_dev_is_tx_hairpin_queue'
>> collect2: error: ld returned 1 exit status
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 1/1] fbarray: fix duplicated fbarray file in secondary
2019-11-05 11:31 0% ` Burakov, Anatoly
@ 2019-11-05 11:41 0% ` Ananyev, Konstantin
2019-11-06 10:37 0% ` Burakov, Anatoly
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2019-11-05 11:41 UTC (permalink / raw)
To: Burakov, Anatoly, David Marchand, Yasufumi Ogawa
Cc: dev, dpdk stable, Yasufumi Ogawa
> -----Original Message-----
> From: Burakov, Anatoly <anatoly.burakov@intel.com>
> Sent: Tuesday, November 5, 2019 11:31 AM
> To: David Marchand <david.marchand@redhat.com>; Yasufumi Ogawa <yasufum.o@gmail.com>
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev <dev@dpdk.org>; dpdk stable <stable@dpdk.org>; Yasufumi Ogawa
> <ogawa.yasufumi@lab.ntt.co.jp>
> Subject: Re: [PATCH v6 1/1] fbarray: fix duplicated fbarray file in secondary
>
> On 05-Nov-19 10:13 AM, David Marchand wrote:
> > Hello Anatoly, Yasufumi,
> >
> > On Mon, Nov 4, 2019 at 11:20 AM Burakov, Anatoly
> > <anatoly.burakov@intel.com> wrote:
> >>
> >> On 01-Nov-19 9:04 AM, yasufum.o@gmail.com wrote:
> >>> From: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp>
> >>>
> >>> In secondary_msl_create_walk(), it creates a file for fbarrays with its
> >>> PID for reserving unique name among secondary processes. However, it
> >>> does not work if several secondaries run as app containers because each
> >>> of containerized secondary has PID 1, and failed to reserve unique name
> >>> other than first one. To reserve unique name in each of containers, use
> >>> hostname in addition to PID.
> >>>
> >>> Cc: stable@dpdk.org
> >
> > We can't backport this as is, see below.
> >
> >
> >>>
> >>> Signed-off-by: Yasufumi Ogawa <yasufum.o@gmail.com>
> >>> ---
> >>> lib/librte_eal/common/include/rte_fbarray.h | 2 +-
> >>> lib/librte_eal/linux/eal/eal_memalloc.c | 11 ++++++++---
> >>> 2 files changed, 9 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/lib/librte_eal/common/include/rte_fbarray.h b/lib/librte_eal/common/include/rte_fbarray.h
> >>> index 6dccdbec9..5c2815093 100644
> >>> --- a/lib/librte_eal/common/include/rte_fbarray.h
> >>> +++ b/lib/librte_eal/common/include/rte_fbarray.h
> >>> @@ -39,7 +39,7 @@ extern "C" {
> >>> #include <rte_compat.h>
> >>> #include <rte_rwlock.h>
> >>>
> >>> -#define RTE_FBARRAY_NAME_LEN 64
> >>> +#define RTE_FBARRAY_NAME_LEN NAME_MAX
> >
> > The change on RTE_FBARRAY_NAME_LEN breaks the ABI, so we cannot
> > backport this as is.
> > For 19.11, we can allow this breakage, but we need an update of the
> > release notes.
> >
> > Besides, what is the impact in terms of memory consumption?
> >
> >
> >>>
> >>> struct rte_fbarray {
> >>> char name[RTE_FBARRAY_NAME_LEN]; /**< name associated with an array */
> >>> diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c b/lib/librte_eal/linux/eal/eal_memalloc.c
> >>> index af6d0d023..24f0275c9 100644
> >>> --- a/lib/librte_eal/linux/eal/eal_memalloc.c
> >>> +++ b/lib/librte_eal/linux/eal/eal_memalloc.c
> >>> @@ -1365,6 +1365,7 @@ secondary_msl_create_walk(const struct rte_memseg_list *msl,
> >>> struct rte_memseg_list *primary_msl, *local_msl;
> >>> char name[PATH_MAX];
> >>> int msl_idx, ret;
> >>> + char hostname[HOST_NAME_MAX] = { 0 };
> >>>
> >>> if (msl->external)
> >>> return 0;
> >>> @@ -1373,9 +1374,13 @@ secondary_msl_create_walk(const struct rte_memseg_list *msl,
> >>> primary_msl = &mcfg->memsegs[msl_idx];
> >>> local_msl = &local_memsegs[msl_idx];
> >>>
> >>> - /* create distinct fbarrays for each secondary */
> >>> - snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%i",
> >>> - primary_msl->memseg_arr.name, getpid());
> >>> + /* Create distinct fbarrays for each secondary by using PID and
> >>> + * hostname. The reason why using hostname is because PID could be
> >>> + * duplicated among secondaries if it is launched in a container.
> >>> + */
> >>> + gethostname(hostname, HOST_NAME_MAX);
> >
> > Personal preference, s/HOST_NAME_MAX/sizeof(hostname)/.
> >
> >
> > hostname[] is HOST_NAME_MAX bytes long.
> > In the worst case, we can get a non NULL terminated hostname string.
> > "
> > gethostname() returns the null-terminated hostname in the
> > character array name, which has a length of len bytes. If the
> > null-terminated hostname is too large to fit, then the name is
> > truncated, and
> > no error is returned (but see NOTES below). POSIX.1-2001 says
> > that if such truncation occurs, then it is unspecified whether the
> > returned buffer includes a terminating null byte.
> > ...
> > NOTES
> > SUSv2 guarantees that "Host names are limited to 255 bytes".
> > POSIX.1-2001 guarantees that "Host names (not including the
> > terminating null byte) are limited to HOST_NAME_MAX bytes". On
> > Linux,
> > HOST_NAME_MAX is defined with the value 64, which has been the
> > limit since Linux 1.0 (earlier kernels imposed a limit of 8 bytes).
> > "
> >
> > How about making hostname[] HOST_NAME_MAX+1 bytes long?
> >
> >>> + snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%s_%d",
> >>> + primary_msl->memseg_arr.name, hostname, (int)getpid());
> >>>
> >>> ret = rte_fbarray_init(&local_msl->memseg_arr, name,
> >>> primary_msl->memseg_arr.len,
> >>>
> >>
> >> I think the order should be reversed. Both containers and non-containers
> >> can have their hostname set, and RTE_FBARRAY_NAME_LEN is of fairly
> >> limited length, so if the hostname is long enough, the PID never gets
> >> into the name string, resulting in duplicates. It is better have pid first.
> >
> > Anatoly,
> >
> > On the principle, it seems better, yes.
> > Just the comment on RTE_FBARRAY_NAME_LEN indicates that you missed the
> > change at the top of the patch.
> > What do you think of this change?
> >
>
> Yes, i did miss that, apologies.
>
> I don't have a strong opinion on this change, however the above comment
> would still be true if we make fbarray size to be hostname_max + 1 - we
> still potentially get no space for a pid. So if we're going to have pid
> in there as well, it should be hostname_max + pid_max (5 digits?) +
> whatever underscores we have + null terminator, to ensure it fits under
> any and all circumstances.#
I think that at least on linux we have more than enough space here:
$ find /usr/include -type f | xargs grep ' NAME_MAX' | grep define
/usr/include/linux/limits.h:#define NAME_MAX 255 /* # chars in a file name */
$ find /usr/include -type f | xargs grep ' HOST_NAME_MAX' | grep define
/usr/include/i386-linux-gnu/bits/local_lim.h:#define HOST_NAME_MAX 64
/usr/include/x86_64-linux-gnu/bits/local_lim.h:#define HOST_NAME_MAX 64
>
> Wrt memory usage, honestly, we don't live in a "640K should be enough
> for everyone" era any more. I don't see this being a major issue. This
> is not a hotpath, and we reserve half a terabyte of virtual memory at
> startup as it is. A few kilo/megabytes more isn't going to make much of
> a difference here.
>
> --
> Thanks,
> Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] eal: add option --iso-cmem for external custom memory
@ 2019-11-05 11:41 4% ` Burakov, Anatoly
2019-11-05 14:10 0% ` Rajesh Ravi
0 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-11-05 11:41 UTC (permalink / raw)
To: Rajesh Ravi
Cc: Ajit Khaparde, dev, Jonathan Richardson, Scott Branden,
Vikram Mysore Prakash, Srinath Mannam
On 04-Nov-19 10:25 AM, Burakov, Anatoly wrote:
> On 30-Oct-19 7:50 PM, Rajesh Ravi wrote:
>> Thanks Anatoly.
>> Please find inline below:
>>
>> [Anatoly] vfio_mem_event_callback() is called every time memory is
>> added to a
>> heap. That includes internal and external memory
>>
>> [Rajesh] malloc_heap_add_external_memory() does call
>> eal_memalloc_mem_event_notify [ instead of vfio_mem_event_callback() ]
>> But, no callback function is getting called from inside
>> eal_memalloc_mem_event_notify()
>> execution flow is not entering inside following loop:
>>
>> /TAILQ_FOREACH(entry, &mem_event_callback_list, next) {/
>> / RTE_LOG(DEBUG, EAL, "Calling mem event callback
>> '%s:%p'\n",
>> entry->name, entry->arg);
>> entry->clb(event, start, len, entry->arg);
>> }/
>>
>> Do you mean to say, we are supposed to explicitly register a callback
>> which separately builds iommu tables in addition to calling
>> rte_malloc_heap_memory_add() API?
>
> Hi,
>
> No, the callback in VFIO should be registered automatically [1] at EAL
> initialization (or, more precisely, when default container is
> initialized). Does that not happen in your case?
>
> [1] http://git.dpdk.org/dpdk/tree/lib/librte_eal/linux/eal/eal_vfio.c#n791
>
Hi Rajesh,
I think i figured it out. It is a defect in design of how external
memory heaps are handled.
When VFIO initializes, it will find first VFIO-bound device, initialize
the container, and set up DMA mappings. Then, you can add more memory
through creating custom memory regions without adding them to heap
(mmap() + rte_extmem_register() + rte_dev_dma_map()), or with adding
them to heap (mmap() + rte_malloc_heap_add_memory()).
The problem is, memory registered through rte_dev_dma_map() will get
added into a list of user maps, while heap memory will not - the
assumption is that the DMA mapping will happen through the callback, but
there is no record left anywhere that this memory is supposed to be mapped.
This makes it so that, if there are no VFIO-bound devices at startup,
then you create a heap, and *then* you hotplug a device, the heap will
not be mapped because (as you have correctly pointed out) type1_map()
skips it, and it's not present in a list of user mem maps either,
because it is heap memory, so EAL is supposed to handle it by itself and
not through user map list.
There could be two fixes here. The easiest one is to just add another
flag to the memseglist - that will work for 19.11, and that's what i
intend on doing since we're breaking ABI anyway.
For older releases, a different approach would be required (i think
scanning heaps is best we can do here) in order to keep the ABI and not
introduce new stuff into rte_memseg_list.
I'll submit a patch shortly, it would be great if you could test it.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 1/1] fbarray: fix duplicated fbarray file in secondary
2019-11-05 10:13 3% ` David Marchand
@ 2019-11-05 11:31 0% ` Burakov, Anatoly
2019-11-05 11:41 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-11-05 11:31 UTC (permalink / raw)
To: David Marchand, Yasufumi Ogawa
Cc: Ananyev, Konstantin, dev, dpdk stable, Yasufumi Ogawa
On 05-Nov-19 10:13 AM, David Marchand wrote:
> Hello Anatoly, Yasufumi,
>
> On Mon, Nov 4, 2019 at 11:20 AM Burakov, Anatoly
> <anatoly.burakov@intel.com> wrote:
>>
>> On 01-Nov-19 9:04 AM, yasufum.o@gmail.com wrote:
>>> From: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp>
>>>
>>> In secondary_msl_create_walk(), it creates a file for fbarrays with its
>>> PID for reserving unique name among secondary processes. However, it
>>> does not work if several secondaries run as app containers because each
>>> of containerized secondary has PID 1, and failed to reserve unique name
>>> other than first one. To reserve unique name in each of containers, use
>>> hostname in addition to PID.
>>>
>>> Cc: stable@dpdk.org
>
> We can't backport this as is, see below.
>
>
>>>
>>> Signed-off-by: Yasufumi Ogawa <yasufum.o@gmail.com>
>>> ---
>>> lib/librte_eal/common/include/rte_fbarray.h | 2 +-
>>> lib/librte_eal/linux/eal/eal_memalloc.c | 11 ++++++++---
>>> 2 files changed, 9 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/lib/librte_eal/common/include/rte_fbarray.h b/lib/librte_eal/common/include/rte_fbarray.h
>>> index 6dccdbec9..5c2815093 100644
>>> --- a/lib/librte_eal/common/include/rte_fbarray.h
>>> +++ b/lib/librte_eal/common/include/rte_fbarray.h
>>> @@ -39,7 +39,7 @@ extern "C" {
>>> #include <rte_compat.h>
>>> #include <rte_rwlock.h>
>>>
>>> -#define RTE_FBARRAY_NAME_LEN 64
>>> +#define RTE_FBARRAY_NAME_LEN NAME_MAX
>
> The change on RTE_FBARRAY_NAME_LEN breaks the ABI, so we cannot
> backport this as is.
> For 19.11, we can allow this breakage, but we need an update of the
> release notes.
>
> Besides, what is the impact in terms of memory consumption?
>
>
>>>
>>> struct rte_fbarray {
>>> char name[RTE_FBARRAY_NAME_LEN]; /**< name associated with an array */
>>> diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c b/lib/librte_eal/linux/eal/eal_memalloc.c
>>> index af6d0d023..24f0275c9 100644
>>> --- a/lib/librte_eal/linux/eal/eal_memalloc.c
>>> +++ b/lib/librte_eal/linux/eal/eal_memalloc.c
>>> @@ -1365,6 +1365,7 @@ secondary_msl_create_walk(const struct rte_memseg_list *msl,
>>> struct rte_memseg_list *primary_msl, *local_msl;
>>> char name[PATH_MAX];
>>> int msl_idx, ret;
>>> + char hostname[HOST_NAME_MAX] = { 0 };
>>>
>>> if (msl->external)
>>> return 0;
>>> @@ -1373,9 +1374,13 @@ secondary_msl_create_walk(const struct rte_memseg_list *msl,
>>> primary_msl = &mcfg->memsegs[msl_idx];
>>> local_msl = &local_memsegs[msl_idx];
>>>
>>> - /* create distinct fbarrays for each secondary */
>>> - snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%i",
>>> - primary_msl->memseg_arr.name, getpid());
>>> + /* Create distinct fbarrays for each secondary by using PID and
>>> + * hostname. The reason why using hostname is because PID could be
>>> + * duplicated among secondaries if it is launched in a container.
>>> + */
>>> + gethostname(hostname, HOST_NAME_MAX);
>
> Personal preference, s/HOST_NAME_MAX/sizeof(hostname)/.
>
>
> hostname[] is HOST_NAME_MAX bytes long.
> In the worst case, we can get a non NULL terminated hostname string.
> "
> gethostname() returns the null-terminated hostname in the
> character array name, which has a length of len bytes. If the
> null-terminated hostname is too large to fit, then the name is
> truncated, and
> no error is returned (but see NOTES below). POSIX.1-2001 says
> that if such truncation occurs, then it is unspecified whether the
> returned buffer includes a terminating null byte.
> ...
> NOTES
> SUSv2 guarantees that "Host names are limited to 255 bytes".
> POSIX.1-2001 guarantees that "Host names (not including the
> terminating null byte) are limited to HOST_NAME_MAX bytes". On
> Linux,
> HOST_NAME_MAX is defined with the value 64, which has been the
> limit since Linux 1.0 (earlier kernels imposed a limit of 8 bytes).
> "
>
> How about making hostname[] HOST_NAME_MAX+1 bytes long?
>
>>> + snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%s_%d",
>>> + primary_msl->memseg_arr.name, hostname, (int)getpid());
>>>
>>> ret = rte_fbarray_init(&local_msl->memseg_arr, name,
>>> primary_msl->memseg_arr.len,
>>>
>>
>> I think the order should be reversed. Both containers and non-containers
>> can have their hostname set, and RTE_FBARRAY_NAME_LEN is of fairly
>> limited length, so if the hostname is long enough, the PID never gets
>> into the name string, resulting in duplicates. It is better have pid first.
>
> Anatoly,
>
> On the principle, it seems better, yes.
> Just the comment on RTE_FBARRAY_NAME_LEN indicates that you missed the
> change at the top of the patch.
> What do you think of this change?
>
Yes, i did miss that, apologies.
I don't have a strong opinion on this change, however the above comment
would still be true if we make fbarray size to be hostname_max + 1 - we
still potentially get no space for a pid. So if we're going to have pid
in there as well, it should be hostname_max + pid_max (5 digits?) +
whatever underscores we have + null terminator, to ensure it fits under
any and all circumstances.
Wrt memory usage, honestly, we don't live in a "640K should be enough
for everyone" era any more. I don't see this being a major issue. This
is not a hotpath, and we reserve half a terabyte of virtual memory at
startup as it is. A few kilo/megabytes more isn't going to make much of
a difference here.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 01/10] config: change ABI versioning to global
@ 2019-11-05 11:05 4% ` David Marchand
2019-11-05 13:50 4% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-11-05 11:05 UTC (permalink / raw)
To: Anatoly Burakov
Cc: dev, Marcin Baran, Thomas Monjalon, Bruce Richardson, Mcnamara,
John, Kinsella, Ray, Pawel Modrak
On Thu, Oct 24, 2019 at 11:46 AM Anatoly Burakov
<anatoly.burakov@intel.com> wrote:
>
> From: Marcin Baran <marcinx.baran@intel.com>
>
> As per new ABI policy, all of the libraries are now versioned using
> one global ABI version. Changes in this patch implement the
> necessary steps to enable that.
>
> Signed-off-by: Marcin Baran <marcinx.baran@intel.com>
> Signed-off-by: Pawel Modrak <pawelx.modrak@intel.com>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
>
> Notes:
> v3:
> - Removed Windows support from Makefile changes
> - Removed unneeded path conversions from meson files
>
> buildtools/meson.build | 2 ++
> config/ABI_VERSION | 1 +
> config/meson.build | 4 +++-
> drivers/meson.build | 20 ++++++++++++--------
> lib/meson.build | 18 +++++++++++-------
> meson_options.txt | 2 --
> mk/rte.lib.mk | 13 ++++---------
> 7 files changed, 33 insertions(+), 27 deletions(-)
> create mode 100644 config/ABI_VERSION
>
> diff --git a/buildtools/meson.build b/buildtools/meson.build
> index 32c79c1308..78ce69977d 100644
> --- a/buildtools/meson.build
> +++ b/buildtools/meson.build
> @@ -12,3 +12,5 @@ if python3.found()
> else
> map_to_def_cmd = ['meson', 'runpython', files('map_to_def.py')]
> endif
> +
> +is_experimental_cmd = [find_program('grep', 'findstr'), '^DPDK_']
Traces from the windows stuff?
> diff --git a/config/ABI_VERSION b/config/ABI_VERSION
> new file mode 100644
> index 0000000000..9a7c1e503f
> --- /dev/null
> +++ b/config/ABI_VERSION
> @@ -0,0 +1 @@
> +20.0
> diff --git a/config/meson.build b/config/meson.build
> index acacba704a..40ad34345f 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -18,6 +18,8 @@ endforeach
> # depending on the configuration options
> pver = meson.project_version().split('.')
> major_version = '@0@.@1@'.format(pver.get(0), pver.get(1))
> +abi_version = run_command(find_program('cat', 'more'),
Idem.
> + files('ABI_VERSION')).stdout().strip()
>
> # extract all version information into the build configuration
> dpdk_conf.set('RTE_VER_YEAR', pver.get(0).to_int())
> @@ -37,7 +39,7 @@ endif
>
> pmd_subdir_opt = get_option('drivers_install_subdir')
> if pmd_subdir_opt.contains('<VERSION>')
> - pmd_subdir_opt = major_version.join(pmd_subdir_opt.split('<VERSION>'))
> + pmd_subdir_opt = abi_version.join(pmd_subdir_opt.split('<VERSION>'))
> endif
> driver_install_path = join_paths(get_option('libdir'), pmd_subdir_opt)
> eal_pmd_path = join_paths(get_option('prefix'), driver_install_path)
> diff --git a/drivers/meson.build b/drivers/meson.build
> index 4a1cb8b5be..1c1190053e 100644
> --- a/drivers/meson.build
> +++ b/drivers/meson.build
> @@ -119,12 +119,19 @@ foreach class:dpdk_driver_classes
> output: out_filename,
> depends: [pmdinfogen, tmp_lib])
>
> - if get_option('per_library_versions')
> - lib_version = '@0@.1'.format(version)
> - so_version = '@0@'.format(version)
> + version_map = '@0@/@1@/@2@_version.map'.format(
> + meson.current_source_dir(),
> + drv_path, lib_name)
> +
> + is_experimental = run_command(is_experimental_cmd,
> + files(version_map)).returncode()
> +
> + if is_experimental != 0
> + lib_version = '0.1'
> + so_version = '0'
> else
> - lib_version = major_version
> - so_version = major_version
> + lib_version = abi_version
> + so_version = abi_version
> endif
>
> # now build the static driver
> @@ -137,9 +144,6 @@ foreach class:dpdk_driver_classes
> install: true)
>
> # now build the shared driver
> - version_map = '@0@/@1@/@2@_version.map'.format(
> - meson.current_source_dir(),
> - drv_path, lib_name)
> shared_lib = shared_library(lib_name,
> sources,
> objects: objs,
> diff --git a/lib/meson.build b/lib/meson.build
> index 8ea3671c04..6302c0b680 100644
> --- a/lib/meson.build
> +++ b/lib/meson.build
> @@ -100,12 +100,18 @@ foreach l:libraries
> cflags += '-DALLOW_EXPERIMENTAL_API'
> endif
>
> - if get_option('per_library_versions')
> - lib_version = '@0@.1'.format(version)
> - so_version = '@0@'.format(version)
> + version_map = '@0@/@1@/rte_@2@_version.map'.format(
> + meson.current_source_dir(), dir_name, name)
> +
> + is_experimental = run_command(is_experimental_cmd,
> + files(version_map)).returncode()
> +
> + if is_experimental != 0
> + lib_version = '0.1'
> + so_version = '0'
> else
> - lib_version = major_version
> - so_version = major_version
> + lib_version = abi_version
> + so_version = abi_version
> endif
>
> # first build static lib
> @@ -123,8 +129,6 @@ foreach l:libraries
> # then use pre-build objects to build shared lib
> sources = []
> objs += static_lib.extract_all_objects(recursive: false)
> - version_map = '@0@/@1@/rte_@2@_version.map'.format(
> - meson.current_source_dir(), dir_name, name)
> implib = dir_name + '.dll.a'
>
> def_file = custom_target(name + '_def',
> diff --git a/meson_options.txt b/meson_options.txt
> index 89650b0e9c..da6a7f0302 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -30,8 +30,6 @@ option('max_lcores', type: 'integer', value: 128,
> description: 'maximum number of cores/threads supported by EAL')
> option('max_numa_nodes', type: 'integer', value: 4,
> description: 'maximum number of NUMA nodes supported by EAL')
> -option('per_library_versions', type: 'boolean', value: true,
> - description: 'true: each lib gets its own version number, false: DPDK version used for each lib')
> option('tests', type: 'boolean', value: true,
> description: 'build unit tests')
> option('use_hpet', type: 'boolean', value: false,
> diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
> index 4df8849a08..e1ea292b6e 100644
> --- a/mk/rte.lib.mk
> +++ b/mk/rte.lib.mk
> @@ -11,20 +11,15 @@ EXTLIB_BUILD ?= n
> # VPATH contains at least SRCDIR
> VPATH += $(SRCDIR)
>
> -ifneq ($(CONFIG_RTE_MAJOR_ABI),)
> -ifneq ($(LIBABIVER),)
> -LIBABIVER := $(CONFIG_RTE_MAJOR_ABI)
> -endif
> +ifneq ($(shell grep "^DPDK_" $(SRCDIR)/$(EXPORT_MAP)),)
This generates noise for the ethtool lib in the associated example:
== ethtool
== lib
grep: /home/dmarchan/dpdk/examples/ethtool/lib/: Is a directory
LD librte_ethtool.so.0
INSTALL-LIB librte_ethtool.so.0
== ethtool-app
So either we add a map file for this example lib (a bit odd), or we
silence this warning.
> +LIBABIVER := $(shell cat $(RTE_SRCDIR)/config/ABI_VERSION)
> +else
> +LIBABIVER := 0
> endif
>
> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> LIB := $(patsubst %.a,%.so.$(LIBABIVER),$(LIB))
> ifeq ($(EXTLIB_BUILD),n)
> -ifeq ($(CONFIG_RTE_MAJOR_ABI),)
> -ifeq ($(CONFIG_RTE_NEXT_ABI),y)
> -LIB := $(LIB).1
> -endif
> -endif
> CPU_LDFLAGS += --version-script=$(SRCDIR)/$(EXPORT_MAP)
> endif
> endif
> --
> 2.17.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 1/1] fbarray: fix duplicated fbarray file in secondary
@ 2019-11-05 10:13 3% ` David Marchand
2019-11-05 11:31 0% ` Burakov, Anatoly
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-11-05 10:13 UTC (permalink / raw)
To: Burakov, Anatoly, Yasufumi Ogawa
Cc: Ananyev, Konstantin, dev, dpdk stable, Yasufumi Ogawa
Hello Anatoly, Yasufumi,
On Mon, Nov 4, 2019 at 11:20 AM Burakov, Anatoly
<anatoly.burakov@intel.com> wrote:
>
> On 01-Nov-19 9:04 AM, yasufum.o@gmail.com wrote:
> > From: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp>
> >
> > In secondary_msl_create_walk(), it creates a file for fbarrays with its
> > PID for reserving unique name among secondary processes. However, it
> > does not work if several secondaries run as app containers because each
> > of containerized secondary has PID 1, and failed to reserve unique name
> > other than first one. To reserve unique name in each of containers, use
> > hostname in addition to PID.
> >
> > Cc: stable@dpdk.org
We can't backport this as is, see below.
> >
> > Signed-off-by: Yasufumi Ogawa <yasufum.o@gmail.com>
> > ---
> > lib/librte_eal/common/include/rte_fbarray.h | 2 +-
> > lib/librte_eal/linux/eal/eal_memalloc.c | 11 ++++++++---
> > 2 files changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/lib/librte_eal/common/include/rte_fbarray.h b/lib/librte_eal/common/include/rte_fbarray.h
> > index 6dccdbec9..5c2815093 100644
> > --- a/lib/librte_eal/common/include/rte_fbarray.h
> > +++ b/lib/librte_eal/common/include/rte_fbarray.h
> > @@ -39,7 +39,7 @@ extern "C" {
> > #include <rte_compat.h>
> > #include <rte_rwlock.h>
> >
> > -#define RTE_FBARRAY_NAME_LEN 64
> > +#define RTE_FBARRAY_NAME_LEN NAME_MAX
The change on RTE_FBARRAY_NAME_LEN breaks the ABI, so we cannot
backport this as is.
For 19.11, we can allow this breakage, but we need an update of the
release notes.
Besides, what is the impact in terms of memory consumption?
> >
> > struct rte_fbarray {
> > char name[RTE_FBARRAY_NAME_LEN]; /**< name associated with an array */
> > diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c b/lib/librte_eal/linux/eal/eal_memalloc.c
> > index af6d0d023..24f0275c9 100644
> > --- a/lib/librte_eal/linux/eal/eal_memalloc.c
> > +++ b/lib/librte_eal/linux/eal/eal_memalloc.c
> > @@ -1365,6 +1365,7 @@ secondary_msl_create_walk(const struct rte_memseg_list *msl,
> > struct rte_memseg_list *primary_msl, *local_msl;
> > char name[PATH_MAX];
> > int msl_idx, ret;
> > + char hostname[HOST_NAME_MAX] = { 0 };
> >
> > if (msl->external)
> > return 0;
> > @@ -1373,9 +1374,13 @@ secondary_msl_create_walk(const struct rte_memseg_list *msl,
> > primary_msl = &mcfg->memsegs[msl_idx];
> > local_msl = &local_memsegs[msl_idx];
> >
> > - /* create distinct fbarrays for each secondary */
> > - snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%i",
> > - primary_msl->memseg_arr.name, getpid());
> > + /* Create distinct fbarrays for each secondary by using PID and
> > + * hostname. The reason why using hostname is because PID could be
> > + * duplicated among secondaries if it is launched in a container.
> > + */
> > + gethostname(hostname, HOST_NAME_MAX);
Personal preference, s/HOST_NAME_MAX/sizeof(hostname)/.
hostname[] is HOST_NAME_MAX bytes long.
In the worst case, we can get a non NULL terminated hostname string.
"
gethostname() returns the null-terminated hostname in the
character array name, which has a length of len bytes. If the
null-terminated hostname is too large to fit, then the name is
truncated, and
no error is returned (but see NOTES below). POSIX.1-2001 says
that if such truncation occurs, then it is unspecified whether the
returned buffer includes a terminating null byte.
...
NOTES
SUSv2 guarantees that "Host names are limited to 255 bytes".
POSIX.1-2001 guarantees that "Host names (not including the
terminating null byte) are limited to HOST_NAME_MAX bytes". On
Linux,
HOST_NAME_MAX is defined with the value 64, which has been the
limit since Linux 1.0 (earlier kernels imposed a limit of 8 bytes).
"
How about making hostname[] HOST_NAME_MAX+1 bytes long?
> > + snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%s_%d",
> > + primary_msl->memseg_arr.name, hostname, (int)getpid());
> >
> > ret = rte_fbarray_init(&local_msl->memseg_arr, name,
> > primary_msl->memseg_arr.len,
> >
>
> I think the order should be reversed. Both containers and non-containers
> can have their hostname set, and RTE_FBARRAY_NAME_LEN is of fairly
> limited length, so if the hostname is long enough, the PID never gets
> into the name string, resulting in duplicates. It is better have pid first.
Anatoly,
On the principle, it seems better, yes.
Just the comment on RTE_FBARRAY_NAME_LEN indicates that you missed the
change at the top of the patch.
What do you think of this change?
--
David Marchand
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 1/3] ethdev: support API to set max LRO packet size
@ 2019-11-05 8:40 3% ` Dekel Peled
2019-11-08 23:07 4% ` [dpdk-dev] [PATCH v6] ethdev: add " Thomas Monjalon
2 siblings, 0 replies; 200+ results
From: Dekel Peled @ 2019-11-05 8:40 UTC (permalink / raw)
To: john.mcnamara, marko.kovacevic, nhorman, ajit.khaparde,
somnath.kotur, anatoly.burakov, xuanziyang2, cloud.wangxiaoyun,
zhouguoyang, wenzhuo.lu, konstantin.ananyev, matan, shahafs,
viacheslavo, rmody, shshaikh, maxime.coquelin, tiwei.bie,
zhihong.wang, yongwang, thomas, ferruh.yigit, arybchenko,
jingjing.wu, bernard.iremonger
Cc: dev
This patch implements [1], to support API for configuration and
validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11
are updated accordingly.
Various PMDs using LRO offload are updated, the new data members are
initialized to ensure they don't fail validation.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/
Signed-off-by: Dekel Peled <dekelp@mellanox.com>
---
doc/guides/nics/features.rst | 2 ++
doc/guides/rel_notes/deprecation.rst | 4 ---
doc/guides/rel_notes/release_19_11.rst | 8 ++++++
drivers/net/bnxt/bnxt_ethdev.c | 1 +
drivers/net/hinic/hinic_pmd_ethdev.c | 1 +
drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++
drivers/net/ixgbe/ixgbe_vf_representor.c | 1 +
drivers/net/mlx5/mlx5.h | 3 +++
drivers/net/mlx5/mlx5_ethdev.c | 1 +
drivers/net/mlx5/mlx5_rxq.c | 1 -
drivers/net/qede/qede_ethdev.c | 1 +
drivers/net/virtio/virtio_ethdev.c | 1 +
drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 +
lib/librte_ethdev/rte_ethdev.c | 44 ++++++++++++++++++++++++++++++++
lib/librte_ethdev/rte_ethdev.h | 4 +++
15 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index d966968..4d1bb5a 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -193,10 +193,12 @@ LRO
Supports Large Receive Offload.
* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_TCP_LRO``.
+ ``dev_conf.rxmode.max_lro_pkt_size``.
* **[implements] datapath**: ``LRO functionality``.
* **[implements] rte_eth_dev_data**: ``lro``.
* **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``.
* **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``.
+* **[provides] rte_eth_dev_info**: ``max_lro_pkt_size``.
.. _nic_features_tso:
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index c10dc30..fdec33d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -87,10 +87,6 @@ Deprecation Notices
This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and
thereby improve Rx performance if application wishes do so.
-* ethdev: New 32-bit fields may be added for maximum LRO session size, in
- struct ``rte_eth_dev_info`` for the port capability and in struct
- ``rte_eth_rxmode`` for the port configuration.
-
* cryptodev: support for using IV with all sizes is added, J0 still can
be used but only when IV length in following structs ``rte_crypto_auth_xform``,
``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index f96ac38..9bffb16 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -380,6 +380,14 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
+* ethdev: Added 32-bit fields for maximum LRO aggregated packet size, in
+ struct ``rte_eth_dev_info`` for the port capability and in struct
+ ``rte_eth_rxmode`` for the port configuration.
+ Application should use the new field in struct ``rte_eth_rxmode`` to configure
+ the requested size.
+ PMD should use the new field in struct ``rte_eth_dev_info`` to report the
+ supported port capability.
+
Shared Library Versions
-----------------------
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 7d9459f..88af61b 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -535,6 +535,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,
/* Fast path specifics */
dev_info->min_rx_bufsize = 1;
dev_info->max_rx_pktlen = BNXT_MAX_PKT_LEN;
+ dev_info->max_lro_pkt_size = BNXT_MAX_PKT_LEN;
dev_info->rx_offload_capa = BNXT_DEV_RX_OFFLOAD_SUPPORT;
if (bp->flags & BNXT_FLAG_PTP_SUPPORTED)
diff --git a/drivers/net/hinic/hinic_pmd_ethdev.c b/drivers/net/hinic/hinic_pmd_ethdev.c
index 9f37a40..b33b2cf 100644
--- a/drivers/net/hinic/hinic_pmd_ethdev.c
+++ b/drivers/net/hinic/hinic_pmd_ethdev.c
@@ -727,6 +727,7 @@ static void hinic_get_speed_capa(struct rte_eth_dev *dev, uint32_t *speed_capa)
info->max_tx_queues = nic_dev->nic_cap.max_sqs;
info->min_rx_bufsize = HINIC_MIN_RX_BUF_SIZE;
info->max_rx_pktlen = HINIC_MAX_JUMBO_FRAME_SIZE;
+ info->max_lro_pkt_size = HINIC_MAX_JUMBO_FRAME_SIZE;
info->max_mac_addrs = HINIC_MAX_UC_MAC_ADDRS;
info->min_mtu = HINIC_MIN_MTU_SIZE;
info->max_mtu = HINIC_MAX_MTU_SIZE;
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index dbce7a8..a561886 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3804,6 +3804,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
}
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL register */
dev_info->max_rx_pktlen = 15872; /* includes CRC, cf MAXFRS register */
+ dev_info->max_lro_pkt_size = 15872;
dev_info->max_mac_addrs = hw->mac.num_rar_entries;
dev_info->max_hash_mac_addrs = IXGBE_VMDQ_NUM_UC_MAC;
dev_info->max_vfs = pci_dev->max_vfs;
@@ -3927,6 +3928,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues;
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL reg */
dev_info->max_rx_pktlen = 9728; /* includes CRC, cf MAXFRS reg */
+ dev_info->max_lro_pkt_size = 9728;
dev_info->max_mtu = dev_info->max_rx_pktlen - IXGBE_ETH_OVERHEAD;
dev_info->max_mac_addrs = hw->mac.num_rar_entries;
dev_info->max_hash_mac_addrs = IXGBE_VMDQ_NUM_UC_MAC;
diff --git a/drivers/net/ixgbe/ixgbe_vf_representor.c b/drivers/net/ixgbe/ixgbe_vf_representor.c
index dbbef29..28dfa3a 100644
--- a/drivers/net/ixgbe/ixgbe_vf_representor.c
+++ b/drivers/net/ixgbe/ixgbe_vf_representor.c
@@ -48,6 +48,7 @@
dev_info->min_rx_bufsize = 1024;
/**< Minimum size of RX buffer. */
dev_info->max_rx_pktlen = 9728;
+ dev_info->max_lro_pkt_size = 9728;
/**< Maximum configurable length of RX pkt. */
dev_info->max_rx_queues = IXGBE_VF_MAX_RX_QUEUES;
/**< Maximum number of RX queues. */
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index f644998..fdfc99b 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -203,6 +203,9 @@ struct mlx5_hca_attr {
#define MLX5_LRO_SUPPORTED(dev) \
(((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported)
+/* Maximal size of aggregated LRO packet. */
+#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)
+
/* LRO configurations structure. */
struct mlx5_lro_config {
uint32_t supported:1; /* Whether LRO is supported. */
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index c2bed2f..1443faa 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -606,6 +606,7 @@ struct ethtool_link_settings {
/* FIXME: we should ask the device for these values. */
info->min_rx_bufsize = 32;
info->max_rx_pktlen = 65536;
+ info->max_lro_pkt_size = MLX5_MAX_LRO_SIZE;
/*
* Since we need one CQ per QP, the limit is the minimum number
* between the two values.
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index 24d0eaa..9423e7b 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -1701,7 +1701,6 @@ struct mlx5_rxq_obj *
return 0;
}
-#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)
#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \
sizeof(struct rte_vlan_hdr) * 2 + \
sizeof(struct rte_ipv6_hdr)))
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 575982f..9c960cd 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev)
dev_info->min_rx_bufsize = (uint32_t)QEDE_MIN_RX_BUFF_SIZE;
dev_info->max_rx_pktlen = (uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
+ dev_info->max_lro_pkt_size = (uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
dev_info->rx_desc_lim = qede_rx_desc_lim;
dev_info->tx_desc_lim = qede_tx_desc_lim;
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 646de99..fa33c45 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -2435,6 +2435,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)
RTE_MIN(hw->max_queue_pairs, VIRTIO_MAX_TX_QUEUES);
dev_info->min_rx_bufsize = VIRTIO_MIN_RX_BUFSIZE;
dev_info->max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN;
+ dev_info->max_lro_pkt_size = VIRTIO_MAX_RX_PKTLEN;
dev_info->max_mac_addrs = VIRTIO_MAX_MAC_ADDRS;
host_features = VTPCI_OPS(hw)->get_features(hw);
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index d1faeaa..d18e8bc 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -1161,6 +1161,7 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device *pci_dev)
dev_info->max_tx_queues = VMXNET3_MAX_TX_QUEUES;
dev_info->min_rx_bufsize = 1518 + RTE_PKTMBUF_HEADROOM;
dev_info->max_rx_pktlen = 16384; /* includes CRC, cf MAXFRS register */
+ dev_info->max_lro_pkt_size = 16384;
dev_info->speed_capa = ETH_LINK_SPEED_10G;
dev_info->max_mac_addrs = VMXNET3_MAX_MAC_ADDRS;
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 85ab5f0..2f52090 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -1156,6 +1156,26 @@ struct rte_eth_dev *
return name;
}
+static inline int
+rte_eth_check_lro_pkt_size(uint16_t port_id, uint32_t config_size,
+ uint32_t dev_info_size)
+{
+ int ret = 0;
+
+ if (config_size > dev_info_size) {
+ RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d max_lro_pkt_size %u > "
+ "max allowed value %u\n",
+ port_id, config_size, dev_info_size);
+ ret = -EINVAL;
+ } else if (config_size < RTE_ETHER_MIN_LEN) {
+ RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d max_lro_pkt_size %u < "
+ "min allowed value %u\n", port_id, config_size,
+ (unsigned int)RTE_ETHER_MIN_LEN);
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
int
rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
const struct rte_eth_conf *dev_conf)
@@ -1286,6 +1306,18 @@ struct rte_eth_dev *
RTE_ETHER_MAX_LEN;
}
+ /*
+ * If LRO is enabled, check that the maximum aggregated packet
+ * size is supported by the configured device.
+ */
+ if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
+ ret = rte_eth_check_lro_pkt_size(
+ port_id, dev_conf->rxmode.max_lro_pkt_size,
+ dev_info.max_lro_pkt_size);
+ if (ret)
+ goto rollback;
+ }
+
/* Any requested offloading must be within its device capabilities */
if ((dev_conf->rxmode.offloads & dev_info.rx_offload_capa) !=
dev_conf->rxmode.offloads) {
@@ -1790,6 +1822,18 @@ struct rte_eth_dev *
return -EINVAL;
}
+ /*
+ * If LRO is enabled, check that the maximum aggregated packet
+ * size is supported by the configured device.
+ */
+ if (local_conf.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
+ int ret = rte_eth_check_lro_pkt_size(port_id,
+ dev->data->dev_conf.rxmode.max_lro_pkt_size,
+ dev_info.max_lro_pkt_size);
+ if (ret)
+ return ret;
+ }
+
ret = (*dev->dev_ops->rx_queue_setup)(dev, rx_queue_id, nb_rx_desc,
socket_id, &local_conf, mp);
if (!ret) {
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index e6ef4b4..e10128d 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -395,6 +395,8 @@ struct rte_eth_rxmode {
/** The multi-queue packet distribution mode to be used, e.g. RSS. */
enum rte_eth_rx_mq_mode mq_mode;
uint32_t max_rx_pkt_len; /**< Only used if JUMBO_FRAME enabled. */
+ /** Maximal allowed size of LRO aggregated packet. */
+ uint32_t max_lro_pkt_size;
uint16_t split_hdr_size; /**< hdr buf size (header_split enabled).*/
/**
* Per-port Rx offloads to be set using DEV_RX_OFFLOAD_* flags.
@@ -1223,6 +1225,8 @@ struct rte_eth_dev_info {
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
+ /** Maximum configurable size of LRO aggregated packet. */
+ uint32_t max_lro_pkt_size;
uint16_t max_rx_queues; /**< Maximum number of RX queues. */
uint16_t max_tx_queues; /**< Maximum number of TX queues. */
uint32_t max_mac_addrs; /**< Maximum number of MAC addresses. */
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
2019-11-04 13:48 4% ` Ray Kinsella
@ 2019-11-04 14:17 0% ` Wang, Haiyue
0 siblings, 0 replies; 200+ results
From: Wang, Haiyue @ 2019-11-04 14:17 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: dev, Yigit, Ferruh, 'Damjan Marion',
Jerin Jacob Kollanukkaran, viacheslavo, stephen, arybchenko
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Monday, November 4, 2019 21:49
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>; 'Damjan Marion' <dmarion@me.com>; Wang,
> Haiyue <haiyue.wang@intel.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> viacheslavo@mellanox.com; stephen@networkplumber.org; arybchenko@solarflare.com
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
>
>
>
> On 04/11/2019 13:09, Thomas Monjalon wrote:
> > 04/11/2019 13:07, Ray Kinsella:
> >>
> >> On 04/11/2019 11:30, Thomas Monjalon wrote:
> >>> 04/11/2019 11:03, Ray Kinsella:
> >>>> On 04/11/2019 09:54, Thomas Monjalon wrote:
> >>>>> 04/11/2019 10:49, Ray Kinsella:
> >>>>>> On 03/11/2019 22:41, Thomas Monjalon wrote:
> >>>>>>> 03/11/2019 21:35, Ray Kinsella:
> >>>>>>>> On 29/10/2019 14:27, Ferruh Yigit wrote:
> >>>>>>>>> On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
> >>>>>>>>>> 26/10/2019 11:23, Wang, Haiyue:
> >>>>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>>>>>>>> 26/10/2019 06:40, Wang, Haiyue:
> >>>>>>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>>>>>>>>>> 25/10/2019 18:02, Jerin Jacob:
> >>>>>>>>>>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >>>>>>>>>>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
> >>>>>>>>>>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> >>>>>>>>>>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
> >>>>>>>>>>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> >>>>>>>>>>>>>>>>>>> that allows an application to retrieve the mode information about
> >>>>>>>>>>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> >>>>>>>>>>>>>>>>>>> like AVX2.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> >>>>>>>>>>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
> >>>>>>>>>>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
> >>>>>>>>>>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I'm not saying blocking the merge.
> >>>>>>>>>>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
> >>>>>>>>>>>>>>>> in this case. Same for Andrew I guess.
> >>>>>>>>>>>>>>>> Note: it is merged in master and I am looking to improve this feature.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
> >>>>>>>>>>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
> >>>>>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>>>>> +struct rte_eth_burst_mode {
> >>>>>>>>>>>>>>>>>>> + uint64_t options;
> >>>>>>>>>>>>>>>>>>> +};
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Why a struct for an integer?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
> >>>>>>>>>>>>>>>>> thing in the future.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I would replace it with a string. This is the most flexible API.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> IMO, Probably, best of both worlds make a good option here,
> >>>>>>>>>>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
> >>>>>>>>>>>>>>> and when a pass to the application, let common code make final string as
> >>>>>>>>>>>>>>> (options flags to string + dev_specific)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> options flag can be zero if PMD does not have any generic flags nor
> >>>>>>>>>>>>>>> interested in such a scheme.
> >>>>>>>>>>>>>>> Generic flags will help at least to have some common code.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>> struct rte_eth_burst_mode {
> >>>>>>>>>>>>>>> uint64_t options;
> >>>>>>>>>>>>>>> char dev_specific[128]; /* PMD has specific burst mode information */
> >>>>>>>>>>>>>>> };
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I really don't see how we can have generic flags.
> >>>>>>>>>>>>>> The flags which are proposed are just matching
> >>>>>>>>>>>>>> the functions implemented in Intel PMDs.
> >>>>>>>>>>>>>> And this is a complicate solution.
> >>>>>>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
> >>>>>>>>>>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
> >>>>>>>>>>>>> that consists of libraries to accelerate packet processing workloads running on a wide
> >>>>>>>>>>>>> variety of CPU architectures."
> >>>>>>>>>>>>
> >>>>>>>>>>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
> >>>>>>>>>>>> They just match some features of the Intel PMDs.
> >>>>>>>>>>>> Why not exposing other optimizations of the Rx/Tx implementations?
> >>>>>>>>>>>> You totally missed the point of generic burst mode description.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> If understand these new experimental APIs from above, then bit options is the best,
> >>>>>>>>>>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
> >>>>>>>>>>>>> technology. And the application can loop to check which kind of burst is running by
> >>>>>>>>>>>>> just simple bit test.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
> >>>>>>>>>>>>> like MLX5 supports ARM NEON, x86 SSE.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I have no word!
> >>>>>>>>>>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
> >>>>>>>>>>>> You talk about mlx5, did you look at its code? Did you see the burst modes
> >>>>>>>>>>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
> >>>>>>>>>>>> Or depending on which offloads are handled?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Again, the instruction set used by the function is a small part
> >>>>>>>>>>>> of the burst mode optimization.
> >>>>>>>>>>>>
> >>>>>>>>>>>> So you did not reply to my question:
> >>>>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>>>>>>>
> >>>>>>>>>>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
> >>>>>>>>>>> application to do further processing, strcmp, strstr ? Not so nice
> >>>>>>>>>>> for C code, and it is not so standard, So switch it to bit definition.
> >>>>>>>>>>
> >>>>>>>>>> Again, please answer my question: why do you need it?
> >>>>>>>>>> I think it is just informative, that's why a string should be enough.
> >>>>>>>>>> I am clearly against the bitmap because it is way too much restrictive.
> >>>>>>>>>> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
> >>>>>>>>>> What you would like to know is whether it is processing packets 4 by 4,
> >>>>>>>>>> for instance, or to know which offload is supported, or what hardware trick
> >>>>>>>>>> is used in the datapath design.
> >>>>>>>>>> There are so many options in a datapath design that it cannot be
> >>>>>>>>>> represented with a bitmap. And it makes no sense to have some design
> >>>>>>>>>> criterias more important than others.
> >>>>>>>>>> I Cc an Intel architect (Edwin) who could explain you how much
> >>>>>>>>>> a datapath design is more complicate than just using AVX instructions.
> >>>>>>>>>
> >>>>>>>>> As I understand this is to let applications to give informed decision based on
> >>>>>>>>> what vectorization is used in the driver, currently this is not know by the
> >>>>>>>>> application.
> >>>>>>>>>
> >>>>>>>>> And as previously replied, the main target of the API is to define the vector
> >>>>>>>>> path, not all optimizations, so the number is limited.
> >>>>>>>
> >>>>>>> No!
> >>>>>>> The name of this API is "burst mode information",
> >>>>>>> not "vector instructions used".
> >>>>>>> I think the main error is that in Intel PMDs,
> >>>>>>> each Rx/Tx function use different vector instructions.
> >>>>>>> So you generalize that knowing the vectors instructions
> >>>>>>> will give you a good information about the performance.
> >>>>>>> But this is generally wrong!
> >>>>>>> The right level of infos is much more complex.
> >>>>>>
> >>>>>> I don't think anyone was suggesting limiting it to purely describing PMD optimization
> >>>>>> with vector instructions. If there are other commonalities let's describe those also.
> >>>>>>
> >>>>>> Vectorization was thought to be a good starting point - IMHO it is.
> >>>>>>
> >>>>>>>
> >>>>>>>>> There are many optimization in the data path, I agree we may not represent all
> >>>>>>>>> of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
> >>>>>>>>> causing this confusion, perhaps we can remove them.
> >>>>>>>>>
> >>>>>>>>> And if the requirement from the application is just informative, I would agree
> >>>>>>>>> that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
> >>>>>>>>> is the main API to provide the information and
> >>>>>>>>> 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
> >>>>>>>>> this information.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Well look we have a general deficit of information about what is happening under
> >>>>>>>> the covers in DPDK. The end user may get wildly different performance characteristics
> >>>>>>>> based on the DPDK configuration. Simple example is using flow director causes the i40e
> >>>>>>>> PMD to switch to using a scalar code path, and performance may as much as half.
> >>>>>>>>
> >>>>>>>> This can cause no end of head-scratching in consuming products, I have done some
> >>>>>>>> of that head scratching myself, it is a usability nightmare.
> >>>>>>>>
> >>>>>>>> FD.io VPP tries to work around this by mining the call stack, to give the user _some_
> >>>>>>>> kind of information about what is happening. These kind of heroics should not be necessary.
> >>>>>>>>
> >>>>>>>> For exactly the same reasons as telemetry, we should be trying to give the users as much
> >>>>>>>> information as possible, in as standard as format as possible. Otherwise DPDK
> >>>>>>>> becomes arcane leaving the user running gdb to understand what is going on, as I
> >>>>>>>> frequently do.
> >>>>>>>
> >>>>>>> I agree we must provide a clue to understand the performance result.
> >>>>>>> As Stephen commented at the very beginning, a log is enough for such debug.
> >>>>>>> But his comment was ignored.
> >>>>>>
> >>>>>> Do we expect applications built on DPDK to have to grep it's log to make such discoveries?
> >>>>>> It's very brittle and arcane way to provide information, if nothing else.
> >>>>>>
> >>>>>>> You wanted an API, fine.
> >>>>>>> I am OK to have an API to request infos which are also in logs.
> >>>>>>
> >>>>>> I would point out that an API to query meta-data is common practice else where.
> >>>>>> GStreamer GstCaps and Linux Sysfs are the closest example I can think of.
> >>>>>>
> >>>>>>>
> >>>>>>>> Finally, again for the same reasons as telemetry, I would say that machine readable is the
> >>>>>>>> ideal here.
> >>>>>>>
> >>>>>>> I disagree here. There is no need to make this info machine readable.
> >>>>>>> We want a clue about the optimizations which are all about creativity.
> >>>>>>> And we cannot make creativity of developers "machine readable".
> >>>>>>
> >>>>>> I am more concerned about the creativity in how developers describe optimizations.
> >>>>>> If there is no standardization of strings (or bits), the API will be challenging to use.
> >>>>>
> >>>>> No it won't be challenging because it will be just a string to print.
> >>>>
> >>>> Well the challenge is getting everyone to use the same set of strings,
> >>>> such that what is returned by the API has common meaning.
> >>>>
> >>>> I am fine with strings.
> >>>> So long as we have a method of encouraging folks to use a standard set were possible.
> >>>
> >>> I don't understand why you insist on standardizing.
> >>> Every drivers are different.
> >>> The routine names will have a sense only in the context of the driver.
> >>
> >> The more diversity in description, the more the user is reaching for documentation.
> >> If the user is lucky enough that description has documentation.
> >
> > I would go even further:
> > The documentation will not explain each Rx/Tx routine.
> > The user can have some guess, but the main information is to see
> > that the routine changed from one run to the other, so he can expect
> > a change in the performance result.
> > And as a bonus, he can ask more explanation to the maintainers
> > by giving the routine name he got from the API.
> >
> >> We can argue about this indefinitely, instead of proposing a standard. :-)
> >> The best way to this is to leave as the API as experimental for some period - as Haiyue suggests.
> >> And then review as the API drops experimental status, with a view to standardizing if possible?
> >
> > Yes we can argue indefinitely.
> > My position is against standardizing this information.
> > (not even talking about the ABI breaks it could cause)
>
> So here is my proposed work-around.
>
> We are probably to early to describe any commonalities beyond vectorization.
> Vectorization is seen as too Intel specific.
>
> Instead let's go with the PMD-specific strings for v20 ABI.
> Let's review the PMD-specific strings that emerge during v20 + Experimental,
> and see if it possible to start to standardize for v21 ABI?
>
> My position is that some degree of standardization is necessary here, for usability if no other reason.
> I am happy to give it time for that to emerge instead of trying to dictate it.
>
> So go with PMD-specific strings, and review after 1 year to see if we can improve?
>
Hi Experts,
Please give feedback on new patch. :-)
http://patchwork.dpdk.org/patch/62368/
struct rte_eth_burst_mode {
uint64_t flags; /**< The ORed values of RTE_ETH_BURST_FLAG_xxx */
#define RTE_ETH_BURST_MODE_INFO_SIZE 1024 /**< Maximum size for information */
char info[RTE_ETH_BURST_MODE_INFO_SIZE]; /**< burst mode information */
};
If most of PMDs want to follow some rule to format string, maybe new flag can be
defined like: RTE_ETH_BURST_FLAG_FMT_BY_XXX, then the 'info' has some kind of the
same format. And the old application can still just *display* it. New application
can parse it by the known format as indicated by RTE_ETH_BURST_FLAG_FMT_BY_XXX.
Buy in this design ?
> >
> >>>>> The challenge is trying to fix the design characteristics in an API.
> >>>>
> >>>> I thought Haiyue's patch with a fair degree of input from Ferruh and others is a pretty solid
> start.
> >>>> Let's describe those commonalities that _do_ exist today - it may not be enough, but it's better
> than we had.
> >>>
> >>> The initial requirement is to describe what makes the performance
> >>> change from one routine to the other.
> >>> We don't want to describe the commonalities but the specific differences.
> >>> Please let's focus on the real requirement and build an API which really helps.
> >>> As said several times, a PMD-specific string would be a good API.
> >
> >
> >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
2019-11-04 13:09 3% ` Thomas Monjalon
@ 2019-11-04 13:48 4% ` Ray Kinsella
2019-11-04 14:17 0% ` Wang, Haiyue
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-11-04 13:48 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Yigit, Ferruh, 'Damjan Marion',
Wang, Haiyue, Jerin Jacob Kollanukkaran, viacheslavo, stephen,
arybchenko
On 04/11/2019 13:09, Thomas Monjalon wrote:
> 04/11/2019 13:07, Ray Kinsella:
>>
>> On 04/11/2019 11:30, Thomas Monjalon wrote:
>>> 04/11/2019 11:03, Ray Kinsella:
>>>> On 04/11/2019 09:54, Thomas Monjalon wrote:
>>>>> 04/11/2019 10:49, Ray Kinsella:
>>>>>> On 03/11/2019 22:41, Thomas Monjalon wrote:
>>>>>>> 03/11/2019 21:35, Ray Kinsella:
>>>>>>>> On 29/10/2019 14:27, Ferruh Yigit wrote:
>>>>>>>>> On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
>>>>>>>>>> 26/10/2019 11:23, Wang, Haiyue:
>>>>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>>>>>>>>> 26/10/2019 06:40, Wang, Haiyue:
>>>>>>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>>>>>>>>>>> 25/10/2019 18:02, Jerin Jacob:
>>>>>>>>>>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>>>>>>>>>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
>>>>>>>>>>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
>>>>>>>>>>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
>>>>>>>>>>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
>>>>>>>>>>>>>>>>>>> that allows an application to retrieve the mode information about
>>>>>>>>>>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
>>>>>>>>>>>>>>>>>>> like AVX2.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
>>>>>>>>>>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
>>>>>>>>>>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
>>>>>>>>>>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm not saying blocking the merge.
>>>>>>>>>>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
>>>>>>>>>>>>>>>> in this case. Same for Andrew I guess.
>>>>>>>>>>>>>>>> Note: it is merged in master and I am looking to improve this feature.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
>>>>>>>>>>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
>>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>>>> +struct rte_eth_burst_mode {
>>>>>>>>>>>>>>>>>>> + uint64_t options;
>>>>>>>>>>>>>>>>>>> +};
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Why a struct for an integer?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
>>>>>>>>>>>>>>>>> thing in the future.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would replace it with a string. This is the most flexible API.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> IMO, Probably, best of both worlds make a good option here,
>>>>>>>>>>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
>>>>>>>>>>>>>>> and when a pass to the application, let common code make final string as
>>>>>>>>>>>>>>> (options flags to string + dev_specific)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> options flag can be zero if PMD does not have any generic flags nor
>>>>>>>>>>>>>>> interested in such a scheme.
>>>>>>>>>>>>>>> Generic flags will help at least to have some common code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>> struct rte_eth_burst_mode {
>>>>>>>>>>>>>>> uint64_t options;
>>>>>>>>>>>>>>> char dev_specific[128]; /* PMD has specific burst mode information */
>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I really don't see how we can have generic flags.
>>>>>>>>>>>>>> The flags which are proposed are just matching
>>>>>>>>>>>>>> the functions implemented in Intel PMDs.
>>>>>>>>>>>>>> And this is a complicate solution.
>>>>>>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
>>>>>>>>>>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
>>>>>>>>>>>>> that consists of libraries to accelerate packet processing workloads running on a wide
>>>>>>>>>>>>> variety of CPU architectures."
>>>>>>>>>>>>
>>>>>>>>>>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
>>>>>>>>>>>> They just match some features of the Intel PMDs.
>>>>>>>>>>>> Why not exposing other optimizations of the Rx/Tx implementations?
>>>>>>>>>>>> You totally missed the point of generic burst mode description.
>>>>>>>>>>>>
>>>>>>>>>>>>> If understand these new experimental APIs from above, then bit options is the best,
>>>>>>>>>>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
>>>>>>>>>>>>> technology. And the application can loop to check which kind of burst is running by
>>>>>>>>>>>>> just simple bit test.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
>>>>>>>>>>>>> like MLX5 supports ARM NEON, x86 SSE.
>>>>>>>>>>>>
>>>>>>>>>>>> I have no word!
>>>>>>>>>>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
>>>>>>>>>>>> You talk about mlx5, did you look at its code? Did you see the burst modes
>>>>>>>>>>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
>>>>>>>>>>>> Or depending on which offloads are handled?
>>>>>>>>>>>>
>>>>>>>>>>>> Again, the instruction set used by the function is a small part
>>>>>>>>>>>> of the burst mode optimization.
>>>>>>>>>>>>
>>>>>>>>>>>> So you did not reply to my question:
>>>>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
>>>>>>>>>>>
>>>>>>>>>>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
>>>>>>>>>>> application to do further processing, strcmp, strstr ? Not so nice
>>>>>>>>>>> for C code, and it is not so standard, So switch it to bit definition.
>>>>>>>>>>
>>>>>>>>>> Again, please answer my question: why do you need it?
>>>>>>>>>> I think it is just informative, that's why a string should be enough.
>>>>>>>>>> I am clearly against the bitmap because it is way too much restrictive.
>>>>>>>>>> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
>>>>>>>>>> What you would like to know is whether it is processing packets 4 by 4,
>>>>>>>>>> for instance, or to know which offload is supported, or what hardware trick
>>>>>>>>>> is used in the datapath design.
>>>>>>>>>> There are so many options in a datapath design that it cannot be
>>>>>>>>>> represented with a bitmap. And it makes no sense to have some design
>>>>>>>>>> criterias more important than others.
>>>>>>>>>> I Cc an Intel architect (Edwin) who could explain you how much
>>>>>>>>>> a datapath design is more complicate than just using AVX instructions.
>>>>>>>>>
>>>>>>>>> As I understand this is to let applications to give informed decision based on
>>>>>>>>> what vectorization is used in the driver, currently this is not know by the
>>>>>>>>> application.
>>>>>>>>>
>>>>>>>>> And as previously replied, the main target of the API is to define the vector
>>>>>>>>> path, not all optimizations, so the number is limited.
>>>>>>>
>>>>>>> No!
>>>>>>> The name of this API is "burst mode information",
>>>>>>> not "vector instructions used".
>>>>>>> I think the main error is that in Intel PMDs,
>>>>>>> each Rx/Tx function use different vector instructions.
>>>>>>> So you generalize that knowing the vectors instructions
>>>>>>> will give you a good information about the performance.
>>>>>>> But this is generally wrong!
>>>>>>> The right level of infos is much more complex.
>>>>>>
>>>>>> I don't think anyone was suggesting limiting it to purely describing PMD optimization
>>>>>> with vector instructions. If there are other commonalities let's describe those also.
>>>>>>
>>>>>> Vectorization was thought to be a good starting point - IMHO it is.
>>>>>>
>>>>>>>
>>>>>>>>> There are many optimization in the data path, I agree we may not represent all
>>>>>>>>> of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
>>>>>>>>> causing this confusion, perhaps we can remove them.
>>>>>>>>>
>>>>>>>>> And if the requirement from the application is just informative, I would agree
>>>>>>>>> that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
>>>>>>>>> is the main API to provide the information and
>>>>>>>>> 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
>>>>>>>>> this information.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Well look we have a general deficit of information about what is happening under
>>>>>>>> the covers in DPDK. The end user may get wildly different performance characteristics
>>>>>>>> based on the DPDK configuration. Simple example is using flow director causes the i40e
>>>>>>>> PMD to switch to using a scalar code path, and performance may as much as half.
>>>>>>>>
>>>>>>>> This can cause no end of head-scratching in consuming products, I have done some
>>>>>>>> of that head scratching myself, it is a usability nightmare.
>>>>>>>>
>>>>>>>> FD.io VPP tries to work around this by mining the call stack, to give the user _some_
>>>>>>>> kind of information about what is happening. These kind of heroics should not be necessary.
>>>>>>>>
>>>>>>>> For exactly the same reasons as telemetry, we should be trying to give the users as much
>>>>>>>> information as possible, in as standard as format as possible. Otherwise DPDK
>>>>>>>> becomes arcane leaving the user running gdb to understand what is going on, as I
>>>>>>>> frequently do.
>>>>>>>
>>>>>>> I agree we must provide a clue to understand the performance result.
>>>>>>> As Stephen commented at the very beginning, a log is enough for such debug.
>>>>>>> But his comment was ignored.
>>>>>>
>>>>>> Do we expect applications built on DPDK to have to grep it's log to make such discoveries?
>>>>>> It's very brittle and arcane way to provide information, if nothing else.
>>>>>>
>>>>>>> You wanted an API, fine.
>>>>>>> I am OK to have an API to request infos which are also in logs.
>>>>>>
>>>>>> I would point out that an API to query meta-data is common practice else where.
>>>>>> GStreamer GstCaps and Linux Sysfs are the closest example I can think of.
>>>>>>
>>>>>>>
>>>>>>>> Finally, again for the same reasons as telemetry, I would say that machine readable is the
>>>>>>>> ideal here.
>>>>>>>
>>>>>>> I disagree here. There is no need to make this info machine readable.
>>>>>>> We want a clue about the optimizations which are all about creativity.
>>>>>>> And we cannot make creativity of developers "machine readable".
>>>>>>
>>>>>> I am more concerned about the creativity in how developers describe optimizations.
>>>>>> If there is no standardization of strings (or bits), the API will be challenging to use.
>>>>>
>>>>> No it won't be challenging because it will be just a string to print.
>>>>
>>>> Well the challenge is getting everyone to use the same set of strings,
>>>> such that what is returned by the API has common meaning.
>>>>
>>>> I am fine with strings.
>>>> So long as we have a method of encouraging folks to use a standard set were possible.
>>>
>>> I don't understand why you insist on standardizing.
>>> Every drivers are different.
>>> The routine names will have a sense only in the context of the driver.
>>
>> The more diversity in description, the more the user is reaching for documentation.
>> If the user is lucky enough that description has documentation.
>
> I would go even further:
> The documentation will not explain each Rx/Tx routine.
> The user can have some guess, but the main information is to see
> that the routine changed from one run to the other, so he can expect
> a change in the performance result.
> And as a bonus, he can ask more explanation to the maintainers
> by giving the routine name he got from the API.
>
>> We can argue about this indefinitely, instead of proposing a standard. :-)
>> The best way to this is to leave as the API as experimental for some period - as Haiyue suggests.
>> And then review as the API drops experimental status, with a view to standardizing if possible?
>
> Yes we can argue indefinitely.
> My position is against standardizing this information.
> (not even talking about the ABI breaks it could cause)
So here is my proposed work-around.
We are probably to early to describe any commonalities beyond vectorization.
Vectorization is seen as too Intel specific.
Instead let's go with the PMD-specific strings for v20 ABI.
Let's review the PMD-specific strings that emerge during v20 + Experimental,
and see if it possible to start to standardize for v21 ABI?
My position is that some degree of standardization is necessary here, for usability if no other reason.
I am happy to give it time for that to emerge instead of trying to dictate it.
So go with PMD-specific strings, and review after 1 year to see if we can improve?
>
>>>>> The challenge is trying to fix the design characteristics in an API.
>>>>
>>>> I thought Haiyue's patch with a fair degree of input from Ferruh and others is a pretty solid start.
>>>> Let's describe those commonalities that _do_ exist today - it may not be enough, but it's better than we had.
>>>
>>> The initial requirement is to describe what makes the performance
>>> change from one routine to the other.
>>> We don't want to describe the commonalities but the specific differences.
>>> Please let's focus on the real requirement and build an API which really helps.
>>> As said several times, a PMD-specific string would be a good API.
>
>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
@ 2019-11-04 13:09 3% ` Thomas Monjalon
2019-11-04 13:48 4% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-11-04 13:09 UTC (permalink / raw)
To: Ray Kinsella
Cc: dev, Yigit, Ferruh, 'Damjan Marion',
Wang, Haiyue, Jerin Jacob Kollanukkaran, viacheslavo, stephen,
arybchenko
04/11/2019 13:07, Ray Kinsella:
>
> On 04/11/2019 11:30, Thomas Monjalon wrote:
> > 04/11/2019 11:03, Ray Kinsella:
> >> On 04/11/2019 09:54, Thomas Monjalon wrote:
> >>> 04/11/2019 10:49, Ray Kinsella:
> >>>> On 03/11/2019 22:41, Thomas Monjalon wrote:
> >>>>> 03/11/2019 21:35, Ray Kinsella:
> >>>>>> On 29/10/2019 14:27, Ferruh Yigit wrote:
> >>>>>>> On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
> >>>>>>>> 26/10/2019 11:23, Wang, Haiyue:
> >>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>>>>>> 26/10/2019 06:40, Wang, Haiyue:
> >>>>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>>>>>>>> 25/10/2019 18:02, Jerin Jacob:
> >>>>>>>>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >>>>>>>>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
> >>>>>>>>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> >>>>>>>>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
> >>>>>>>>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> >>>>>>>>>>>>>>>>> that allows an application to retrieve the mode information about
> >>>>>>>>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> >>>>>>>>>>>>>>>>> like AVX2.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> >>>>>>>>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
> >>>>>>>>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
> >>>>>>>>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I'm not saying blocking the merge.
> >>>>>>>>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
> >>>>>>>>>>>>>> in this case. Same for Andrew I guess.
> >>>>>>>>>>>>>> Note: it is merged in master and I am looking to improve this feature.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
> >>>>>>>>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
> >>>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>>> +struct rte_eth_burst_mode {
> >>>>>>>>>>>>>>>>> + uint64_t options;
> >>>>>>>>>>>>>>>>> +};
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Why a struct for an integer?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
> >>>>>>>>>>>>>>> thing in the future.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I would replace it with a string. This is the most flexible API.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> IMO, Probably, best of both worlds make a good option here,
> >>>>>>>>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
> >>>>>>>>>>>>> and when a pass to the application, let common code make final string as
> >>>>>>>>>>>>> (options flags to string + dev_specific)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> options flag can be zero if PMD does not have any generic flags nor
> >>>>>>>>>>>>> interested in such a scheme.
> >>>>>>>>>>>>> Generic flags will help at least to have some common code.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1]
> >>>>>>>>>>>>> struct rte_eth_burst_mode {
> >>>>>>>>>>>>> uint64_t options;
> >>>>>>>>>>>>> char dev_specific[128]; /* PMD has specific burst mode information */
> >>>>>>>>>>>>> };
> >>>>>>>>>>>>
> >>>>>>>>>>>> I really don't see how we can have generic flags.
> >>>>>>>>>>>> The flags which are proposed are just matching
> >>>>>>>>>>>> the functions implemented in Intel PMDs.
> >>>>>>>>>>>> And this is a complicate solution.
> >>>>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>>>>>>>
> >>>>>>>>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
> >>>>>>>>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
> >>>>>>>>>>> that consists of libraries to accelerate packet processing workloads running on a wide
> >>>>>>>>>>> variety of CPU architectures."
> >>>>>>>>>>
> >>>>>>>>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
> >>>>>>>>>> They just match some features of the Intel PMDs.
> >>>>>>>>>> Why not exposing other optimizations of the Rx/Tx implementations?
> >>>>>>>>>> You totally missed the point of generic burst mode description.
> >>>>>>>>>>
> >>>>>>>>>>> If understand these new experimental APIs from above, then bit options is the best,
> >>>>>>>>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
> >>>>>>>>>>> technology. And the application can loop to check which kind of burst is running by
> >>>>>>>>>>> just simple bit test.
> >>>>>>>>>>>
> >>>>>>>>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
> >>>>>>>>>>> like MLX5 supports ARM NEON, x86 SSE.
> >>>>>>>>>>
> >>>>>>>>>> I have no word!
> >>>>>>>>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
> >>>>>>>>>> You talk about mlx5, did you look at its code? Did you see the burst modes
> >>>>>>>>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
> >>>>>>>>>> Or depending on which offloads are handled?
> >>>>>>>>>>
> >>>>>>>>>> Again, the instruction set used by the function is a small part
> >>>>>>>>>> of the burst mode optimization.
> >>>>>>>>>>
> >>>>>>>>>> So you did not reply to my question:
> >>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>>>>>
> >>>>>>>>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
> >>>>>>>>> application to do further processing, strcmp, strstr ? Not so nice
> >>>>>>>>> for C code, and it is not so standard, So switch it to bit definition.
> >>>>>>>>
> >>>>>>>> Again, please answer my question: why do you need it?
> >>>>>>>> I think it is just informative, that's why a string should be enough.
> >>>>>>>> I am clearly against the bitmap because it is way too much restrictive.
> >>>>>>>> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
> >>>>>>>> What you would like to know is whether it is processing packets 4 by 4,
> >>>>>>>> for instance, or to know which offload is supported, or what hardware trick
> >>>>>>>> is used in the datapath design.
> >>>>>>>> There are so many options in a datapath design that it cannot be
> >>>>>>>> represented with a bitmap. And it makes no sense to have some design
> >>>>>>>> criterias more important than others.
> >>>>>>>> I Cc an Intel architect (Edwin) who could explain you how much
> >>>>>>>> a datapath design is more complicate than just using AVX instructions.
> >>>>>>>
> >>>>>>> As I understand this is to let applications to give informed decision based on
> >>>>>>> what vectorization is used in the driver, currently this is not know by the
> >>>>>>> application.
> >>>>>>>
> >>>>>>> And as previously replied, the main target of the API is to define the vector
> >>>>>>> path, not all optimizations, so the number is limited.
> >>>>>
> >>>>> No!
> >>>>> The name of this API is "burst mode information",
> >>>>> not "vector instructions used".
> >>>>> I think the main error is that in Intel PMDs,
> >>>>> each Rx/Tx function use different vector instructions.
> >>>>> So you generalize that knowing the vectors instructions
> >>>>> will give you a good information about the performance.
> >>>>> But this is generally wrong!
> >>>>> The right level of infos is much more complex.
> >>>>
> >>>> I don't think anyone was suggesting limiting it to purely describing PMD optimization
> >>>> with vector instructions. If there are other commonalities let's describe those also.
> >>>>
> >>>> Vectorization was thought to be a good starting point - IMHO it is.
> >>>>
> >>>>>
> >>>>>>> There are many optimization in the data path, I agree we may not represent all
> >>>>>>> of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
> >>>>>>> causing this confusion, perhaps we can remove them.
> >>>>>>>
> >>>>>>> And if the requirement from the application is just informative, I would agree
> >>>>>>> that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
> >>>>>>> is the main API to provide the information and
> >>>>>>> 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
> >>>>>>> this information.
> >>>>>>>
> >>>>>>
> >>>>>> Well look we have a general deficit of information about what is happening under
> >>>>>> the covers in DPDK. The end user may get wildly different performance characteristics
> >>>>>> based on the DPDK configuration. Simple example is using flow director causes the i40e
> >>>>>> PMD to switch to using a scalar code path, and performance may as much as half.
> >>>>>>
> >>>>>> This can cause no end of head-scratching in consuming products, I have done some
> >>>>>> of that head scratching myself, it is a usability nightmare.
> >>>>>>
> >>>>>> FD.io VPP tries to work around this by mining the call stack, to give the user _some_
> >>>>>> kind of information about what is happening. These kind of heroics should not be necessary.
> >>>>>>
> >>>>>> For exactly the same reasons as telemetry, we should be trying to give the users as much
> >>>>>> information as possible, in as standard as format as possible. Otherwise DPDK
> >>>>>> becomes arcane leaving the user running gdb to understand what is going on, as I
> >>>>>> frequently do.
> >>>>>
> >>>>> I agree we must provide a clue to understand the performance result.
> >>>>> As Stephen commented at the very beginning, a log is enough for such debug.
> >>>>> But his comment was ignored.
> >>>>
> >>>> Do we expect applications built on DPDK to have to grep it's log to make such discoveries?
> >>>> It's very brittle and arcane way to provide information, if nothing else.
> >>>>
> >>>>> You wanted an API, fine.
> >>>>> I am OK to have an API to request infos which are also in logs.
> >>>>
> >>>> I would point out that an API to query meta-data is common practice else where.
> >>>> GStreamer GstCaps and Linux Sysfs are the closest example I can think of.
> >>>>
> >>>>>
> >>>>>> Finally, again for the same reasons as telemetry, I would say that machine readable is the
> >>>>>> ideal here.
> >>>>>
> >>>>> I disagree here. There is no need to make this info machine readable.
> >>>>> We want a clue about the optimizations which are all about creativity.
> >>>>> And we cannot make creativity of developers "machine readable".
> >>>>
> >>>> I am more concerned about the creativity in how developers describe optimizations.
> >>>> If there is no standardization of strings (or bits), the API will be challenging to use.
> >>>
> >>> No it won't be challenging because it will be just a string to print.
> >>
> >> Well the challenge is getting everyone to use the same set of strings,
> >> such that what is returned by the API has common meaning.
> >>
> >> I am fine with strings.
> >> So long as we have a method of encouraging folks to use a standard set were possible.
> >
> > I don't understand why you insist on standardizing.
> > Every drivers are different.
> > The routine names will have a sense only in the context of the driver.
>
> The more diversity in description, the more the user is reaching for documentation.
> If the user is lucky enough that description has documentation.
I would go even further:
The documentation will not explain each Rx/Tx routine.
The user can have some guess, but the main information is to see
that the routine changed from one run to the other, so he can expect
a change in the performance result.
And as a bonus, he can ask more explanation to the maintainers
by giving the routine name he got from the API.
> We can argue about this indefinitely, instead of proposing a standard. :-)
> The best way to this is to leave as the API as experimental for some period - as Haiyue suggests.
> And then review as the API drops experimental status, with a view to standardizing if possible?
Yes we can argue indefinitely.
My position is against standardizing this information.
(not even talking about the ABI breaks it could cause)
> >>> The challenge is trying to fix the design characteristics in an API.
> >>
> >> I thought Haiyue's patch with a fair degree of input from Ferruh and others is a pretty solid start.
> >> Let's describe those commonalities that _do_ exist today - it may not be enough, but it's better than we had.
> >
> > The initial requirement is to describe what makes the performance
> > change from one routine to the other.
> > We don't want to describe the commonalities but the specific differences.
> > Please let's focus on the real requirement and build an API which really helps.
> > As said several times, a PMD-specific string would be a good API.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
2019-11-03 19:31 0% ` Slava Ovsiienko
@ 2019-11-04 1:01 0% ` Wang, Haiyue
0 siblings, 0 replies; 200+ results
From: Wang, Haiyue @ 2019-11-04 1:01 UTC (permalink / raw)
To: Slava Ovsiienko, Liu, Yu Y, Thomas Monjalon
Cc: dev, arybchenko, Yigit, Ferruh, jerinjacobk, Ye, Xiaolong,
Kinsella, Ray, Sun, Chenmin, Damjan Marion (damarion)
Hi Slava,
Thanks for your reply. I've no more description to talk about the code
design. And I agree with your thinking, all roads lead to Rome, please
don't hesitate to submit a patch to clean up things. Your rich experience
is very appreciated to speed up the design, thanks! ;-)
BR,
Haiyue
> -----Original Message-----
> From: Slava Ovsiienko <viacheslavo@mellanox.com>
> Sent: Monday, November 4, 2019 03:31
> To: Wang, Haiyue <haiyue.wang@intel.com>; Liu, Yu Y <yu.y.liu@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> jerinjacobk@gmail.com; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Sun, Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion) <damarion@cisco.com>
> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
>
> Hi, Haiyue
>
> > -----Original Message-----
> > From: Wang, Haiyue <haiyue.wang@intel.com>
> > Sent: Sunday, November 3, 2019 13:38
> > To: Slava Ovsiienko <viacheslavo@mellanox.com>; Liu, Yu Y
> > <yu.y.liu@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion)
> > <damarion@cisco.com>
> > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
> > information
> >
> > Hi Slava,
> >
> > > -----Original Message-----
> > > From: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > Sent: Sunday, November 3, 2019 16:59
> > > To: Wang, Haiyue <haiyue.wang@intel.com>; Liu, Yu Y
> > <yu.y.liu@intel.com>; Thomas Monjalon
> > > <thomas@monjalon.net>
> > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > <ferruh.yigit@intel.com>;
> > > jerinjacobk@gmail.com; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella,
> > Ray <ray.kinsella@intel.com>;
> > > Sun, Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion)
> > <damarion@cisco.com>
> > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> > mode information
> > >
> > > > -----Original Message-----
> > > > From: Wang, Haiyue <haiyue.wang@intel.com>
> > > > Sent: Sunday, November 3, 2019 4:34
> > > > To: Slava Ovsiienko <viacheslavo@mellanox.com>; Liu, Yu Y
> > > > <yu.y.liu@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > > > Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion)
> > > > <damarion@cisco.com>
> > > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> > mode
> > > > information
> > > >
> > > > Hi Thomas, Slava,
> > > >
> > > > Please see the inline reply in one place.
> > > >
> > > > > -----Original Message-----
> > > > > From: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > > Sent: Saturday, November 2, 2019 16:39
> > > > > To: Liu, Yu Y <yu.y.liu@intel.com>; Wang, Haiyue
> > > > > <haiyue.wang@intel.com>; Thomas Monjalon
> > <thomas@monjalon.net>
> > > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > > > > Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion)
> > > > > <damarion@cisco.com>
> > > > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> > > > > mode information
> > > > >
> > > > > Hi
> > > > > > -----Original Message-----
> > > > > > From: Liu, Yu Y <yu.y.liu@intel.com>
> > > > > > Sent: Saturday, November 2, 2019 8:56
> > > > > > To: Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
> > > > > > <thomas@monjalon.net>
> > > > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > > > > Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > > > > <viacheslavo@mellanox.com>; Damjan Marion (damarion)
> > > > > > <damarion@cisco.com>; Liu, Yu Y <yu.y.liu@intel.com>
> > > > > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting
> > > > > > burst mode information
> > > > > >
> > > > > > Add Damjan from FD.io for awareness...
> > > > > >
> > > > > > Hi Thomas,
> > > > > >
> > > > > > Long time no see. Sorry I use outlook which is not friendly to
> > > > > > community email.
> > > > > >
> > > > > > >Anyway I will propose to replace this API in the next release.
> > > > > > Will your plan be affected by API/ABI stable plan?
> > > > > > BTW, if you propose new change in next release, it will make DPDK
> > > > > > consumer(FD.io) to change again.
> > > > > > So even if it is not affected to the API/ABI stable plan, do we
> > > > > > still have time to get a solution for everyone in DPDK 19.11 with
> > > > > > your contribution/acceleration?
> > > > > >
> > > > > > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > > > > > Please be rest assured it is not the case.
> > > > > > This request is just from one FD.io project internal bug " tx/rx
> > > > > > burst function is shown as nil" reported by Chenmin.
> > > > >
> > > > > Why just the presenting string with function name (possible with suffix)
> > is
> > > > not enough?
> > > > > I would like to see this API (strings approach) in mlx5 either,
> > > > > dropping the entire feature does not look nice, as for me.
> > > > >
> > > > > We could consider some requirements for the name suffices to
> > > > > distinguish whether function uses vector instructions and which ones if
> > any.
> > > > >
> > > > > > My understanding is DPDK behavior was taken as bug for someone in
> > > > > > FD.io project and potentially will mislead other DPDK consumer.
> > > > >
> > > > > Why does FD.io code want to know which vector extension is used by
> > burst
> > > > routines?
> > > > > Is it going to share/preserve some resources (registers, etc.)? Is it
> > robust ?
> > > > > Burst routines might not know whether vector extensions is used (they
> > > > > might call libraries, even rte_memcpy() can use vectors in implicit
> > fashion).
> > > > >
> > > >
> > > > 1.
> > > >
> > > > The original issue description is:
> > > > "VPP uses dladdr() to translate a function address to name, however,
> > some
> > > > tx/rx functions in DPDK are invisible for dladdr(), which is because they
> > are
> > > > defined as static."
> > > >
> > > > 2.
> > > >
> > > > So the RFC design is: one function, one description, like:
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> > > >
> > work.dpdk.org%2Fpatch%2F57644%2F&data=02%7C01%7Cviacheslavo
> > > >
> > %40mellanox.com%7Ca99632b4e2444ec00b1f08d760065041%7Ca652971c7
> > > >
> > d2e4d9ba6a4d149256f461b%7C0%7C0%7C637083452540980873&sdat
> > > >
> > a=4re5GOXPSwGk5BTOYLglafzgjBzRLk1gXyWKT47o8o0%3D&reserved=
> > > > 0
> > > >
> > > > +#ifdef RTE_ARCH_X86
> > > > + else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec_avx2)
> > > > + len = snprintf(buf, sz, "AVX2 Vector Scattered Rx");
> > > > + else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec)
> > > > + len = snprintf(buf, sz, "Vector Scattered Rx");
> > > > + else if (dev->rx_pkt_burst == ice_recv_pkts_vec_avx2)
> > > > + len = snprintf(buf, sz, "AVX2 Vector Rx");
> > > > + else if (dev->rx_pkt_burst == ice_recv_pkts_vec)
> > > > + len = snprintf(buf, sz, "Vector Rx"); #endif
> > > The application gets the routine names with dladdr(). OK, it happens.
> > > It is not clear for me why instead of direct replacement/extension of dladdr
> > > functionality some new names were introduced and then converted to
> > flags.
> > >
> >
> > Sorry, can you explain more ? Who 'direct replacement/extension of dladdr'
> > ?
> > VPP, or DPDK ?
> >
> > > > 3. Since the main issue is as Damjan replied in another thread:
> > > > "people are reporting lower performance caused by DPDK deciding for
> > > > variety
> > > > of reasons to switch from vector PMD to scalar one."
> > > >
> > > > And Ferruh replied also:
> > > > "As I understand this is to let applications to give informed decision
> > based
> > > > on what vectorization is used in the driver, currently this is not known
> > by
> > > > the application.
> > > >
> > > > And as previously replied, the main target of the API is to define the
> > vector
> > > > path, not all optimizations, so the number is limited."
> > > >
> > > > So we enhanced it with bit, example detail is (Yes, we defined a lit
> > more,
> > > > so we removed it in this patch):
> > >
> > > There are might be a lot of various burst functions, vectorized or not,
> > > with various sets of supported offloads. Yes, identifying the engaged burst
> > > routine is meaningful, but it is not clear for me, why the vectorizing type
> > > should have dedicated means (flags) to identify ?
> > >
> >
> > The new 'rte_eth_rx/tx_burst_mode_get' works like logging, but in fact, the
> > log
> > message is something special, like "Vector Neon/AltiVec/SSE/AVX2" and the
> > device
> > specific offloads as you said.
> >
> > This kind of string "Vector Neon/AltiVec/SSE/AVX2" can be common, we not
> > treat it
> > as 'flag', it is a normal bit like macro definition, and it will be translated into
> > string later. And we want to make PMD's string format life to be easy, don't
> > need
> > to call 'snprintf/sprintf' with the copied string format.
> >
> > So now, the log message format is: device specific (if have) + "Vector ..." (if
> > have, this is not MUST, if the PMD doesn't use vector, but at least, this is not
> > hardware specific, it is some common from arch:
> > lib/librte_eal/common/arch/arm,ppc_64,x86).
> >
> > Further, as a SDK, the API exposes these common bit data for application
> > easily access
> > if it may need, DON'T NEED TO BREAK THE ABI/API. Compared to
> > 'strstr/strcasestr',
> > 'mode->options & RTE_ETH_BURST_VECTOR' is more friendly ?
>
> Yes, it is more friendly for app. But there is quite another question: do we really
> need these flags for logging purposes ? There are no explicitly expressed
> requirements from applications for these flags.
>
> > > >
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> > > >
> > work.dpdk.org%2Fpatch%2F61196%2F&data=02%7C01%7Cviacheslavo
> > > >
> > %40mellanox.com%7Ca99632b4e2444ec00b1f08d760065041%7Ca652971c7
> > > >
> > d2e4d9ba6a4d149256f461b%7C0%7C0%7C637083452540980873&sdat
> > > >
> > a=nm80Pt0fFWqmmrJcKY6ks4qRTJ7cjGJWEG1Wv6gxfSw%3D&reserved
> > > > =0
> > > >
> > > > 4. And thanks Jerin's suggestion, I think his word can be more accurate:
> > "This
> > > > would
> > > > help to reuse some of the flags to name conversion logic across all
> > PMDs"
> > > > for the
> > > > reason we try to use bit to reduce some string format effort, it will be
> > > > handled
> > > > by the API internally "burst_mode_options_append(struct
> > > > rte_eth_burst_mode *mode)".
> > > > Now the new API will return the string finally:
> > > >
> > > > #define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 1024 struct
> > > > rte_eth_burst_mode {
> > > > uint64_t options;
> > > >
> > > > /**< Each PMD can fill specific burst mode information into this, and
> > > > * ethdev APIs will append the 'options' string format at its end.
> > > > */
> > > > char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
> > > > };
> > > >
> > > > So MLX PMD can add 'full_empw', 'mtsc_empw' etc into
> > 'alternate_options'
> > > > firstly, assign 'RTE_ETH_BURST_VECTOR | RTE_ETH_BURST_SSE' to
> > 'options'
> > > > as needed, then finally, 'alternate_options' will be "full_empw, Vector
> > SSE".
> > >
> > > For mlx5 tx_burst these flags have no meaning. All information regarding
> > routine
> > > is encoded within the name, mtsc stands for:
> > > m - multisegment
> > > t - TSO
> > > s - software tunnel parser
> > > c - check sum
> > >
> > > There are no two versions of mtsc_empw - "mtsc_empw, Vector SSE",
> > "mtsc_empw, Vector Neon".
> > > If we developed vectorized version, I would prefer "mtsc_empw_sse".
> > >
> > > To summarize:
> > > - application uses routine names, gets with dladdr(). Nice.
> > > - compatible API providing names of internal routines is proposed. Nice.
> > > - users now are able to identify the engaged burst routine. Nice.
> > > - proposed API is extended, some vector related flags were added.
> > Hmmm.... Questionable.
> > > Why vector related only? Why do we change the string format? (name ->
> > name, options)
> >
> > Again, vector is not "only", it is just 'main' characteristic "tree ./drivers/net/ |
> > grep rxtx_".
> > we can design the Rx/Tx burst function mainly by vector type, it is
> > straightforward.
>
> OK, we have some flag field proposed. Saying "why vector only" I meant
> that vectorizing is just one of optimizing technics. I do not see it as
> "main tree characteristics", sorry.
>
> What if some other vendor would like to add its own flags? For example,
> mlx5 could add at least 8 optimizing flags for tx_burst and 4 flags for rx_burst
> (besides vector related ones). Why not? Why do we decide to add vector flags only?
> Other vendors might come into play and add its own flags describing the burst routine
> features and optimizations. And then say - "hey, these parameters define our
> internal rxtx tree. It is very critical for performance, user must know about ones".
>
> >
> > Why 'name -> name' ?
> Sorry for the MS Outlook (and I'm on the way to Mutt now),
> it is not community friendly.
> Correct sentence: "name" to "name, options"
>
> > 1.) [v4,4/4] app/testpmd: show the Rx/Tx burst mode description
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%
> > 2Fpatchwork.dpdk.org%2Fpatch%2F61198%2F&data=02%7C01%7Cviac
> > heslavo%40mellanox.com%7C0ba4e73594684f944b7608d760525c97%7Ca6
> > 52971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637083779173049231&a
> > mp;sdata=2NCHJJpsAYsb07FTEmvr4EiIVudm7ZCVhemh2g1MBG0%3D&r
> > eserved=0
> > This is handled by the application itself, not so friendly, many lines of code to
> > show.
> Yes, it does not look nice, as for me. String should be simple and just provided by PMD,
> without any extra flags/options, IMHO.
> >
> >
> > 2). [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
> > information
> > if (rte_eth_tx_burst_mode_get(port_id, queue_id, &mode) == 0)
> > printf("\nBurst mode: %s", mode.alternate_options);
> >
> > This design may meet your question above if I understand correctly.
> > "It is not clear for me why instead of direct replacement/extension
> > of dladdr
> > functionality some new names were introduced and then converted to
> > flags".
> >
> >
> > Last, again, we define the bits 'RTE_ETH_BURST_XXX' for making the log
> > message
> > generation process easily if you agree vector type is common, the vector can
> > be
> Simple string returned by PMD eliminates "message process generation" at all.
> No flags/options - no generation needed at all. In my opinion, PMD just should
> return strings like "rx_burst_vector_sse", "rx_burst_vector_neon", etc.
>
> > used to improve the performance. And if new burst design can be used for
> > most
> > PMDs, use it as bit, the API helps to translate it to string. And the application
> > can use the bit to do other kind of information display.
> >
> > We define it a little more than 'simple string' for just making life easy. In fact,
> > the patch comes from "simple string", RFC v1, v2, v3, PATCH v1 v2 v3 v4.
>
> Applications live OK with dladdr(). The returned name is used for logging.
> There is NO explicit requirements from application to provide some extra options,
> besides the name (or, at least, these ones are not visible for me).
>
> Sorry, it is not clear for me, how by introducing extra flags and the extra
> "easy message generation process" we make life easier. If PMD just provides
> the simple string "rx_burst_vector_sse", everyone seeing this string in the log
> understands what and how the named rx_burst is doing, right? Do you think
> the message like "rx_burst, Vector SSE" looks better? OK, your PMD
> is free to return it.
>
> Honestly, I do not mind against flags strictly, but I do not see any new meanings
> introduced by flags. It requires extra code, it might introduce some ambiguity,
> it would be ridiculous to see something like that:
> "rx_burst_vector_neon, Vector_AVX"
> And, the last, the flag field is a potential scarce resource for vendors.
>
> With best regards, Slava
>
> > >
> > >
> > > > Intel PMD can just assign "options", then finally, 'alternate_options' will
> > be
> > > > "Vector SSE".
> > >
> > > As I see from initial patch, Intel PMD has dedicated routines with unique
> > names for
> > > each type of vectorization. Is there some burst routine with single name
> > which could
> > > operate with different vectorization types, depending on configuration?
> > >
> > > With best regards, Slava
> > >
> > > >
> > > > How about the design idea ? Again, this 'options' is not to do
> > standardization,
> > > > just want to reduce the duplicated name string things.
> > > >
> > > > > With best regards, Slava
> > > > >
> > > > > > Haiyue is working with Chenmin to address the issue and with your
> > > > > > support it will be even better.
> > > > > >
> > > > > > Your support will be highly appreciated!
> > > > > >
> > > > > > Thanks & Regards,
> > > > > > Yu Liu
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
> > > > > > Sent: Saturday, November 2, 2019 1:30 PM
> > > > > > To: Thomas Monjalon <thomas@monjalon.net>
> > > > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > > > > Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > > > > <viacheslavo@mellanox.com>
> > > > > > Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for
> > > > > > getting burst mode information
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > Sent: Saturday, November 2, 2019 06:46
> > > > > > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > > > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > > > > > Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > > > > > <viacheslavo@mellanox.com>
> > > > > > > Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting
> > > > > > > burst mode information
> > > > > > >
> > > > > > > Thank you for trying to address comments done late.
> > > > > > >
> > > > > > > 31/10/2019 18:11, Haiyue Wang:
> > > > > > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > > >
> > > > > >
> > > > > > > > +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2)
> > > > > > > > +#define RTE_ETH_BURST_NEON (1ULL << 3)
> > > > > > > > +#define RTE_ETH_BURST_SSE (1ULL << 4)
> > > > > > > > +#define RTE_ETH_BURST_AVX2 (1ULL << 5)
> > > > > > > > +#define RTE_ETH_BURST_AVX512 (1ULL << 6)
> > > > > > >
> > > > > > > Of course, I still believe that giving a special treatment to
> > > > > > > vector instructions is wrong.
> > > > > > > You did not justify why it needs to be defined in bits instead of
> > > > > > > string. I am not asking again because anyway you don't really
> > > > > > > reply. I think you are executing an order you received and I don't
> > > > > > > want to blame you more.
> > > > > > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > > > > > > No need to reply to this comment.
> > > > > > > Anyway I will propose to replace this API in the next release.
> > > > > >
> > > > > > Never mind, if this design is truly ugly, drop it all now. I also
> > > > > > prefer to do the best, that's why open source is amazing, thanks!
> > > > > > ;-)
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
2019-11-02 19:21 0% ` Damjan Marion (damarion)
2019-11-03 7:50 0% ` Slava Ovsiienko
@ 2019-11-03 20:46 0% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2019-11-03 20:46 UTC (permalink / raw)
To: dev
On 02/11/2019 19:21, Damjan Marion (damarion) wrote:
>
>
>> On 2 Nov 2019, at 09:38, Slava Ovsiienko <viacheslavo@mellanox.com> wrote:
>>
>> Hi
>>> -----Original Message-----
>>> From: Liu, Yu Y <yu.y.liu@intel.com>
>>> Sent: Saturday, November 2, 2019 8:56
>>> To: Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
>>> <thomas@monjalon.net>
>>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
>>> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
>>> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
>>> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
>>> <viacheslavo@mellanox.com>; Damjan Marion (damarion)
>>> <damarion@cisco.com>; Liu, Yu Y <yu.y.liu@intel.com>
>>> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
>>> information
>>>
>>> Add Damjan from FD.io for awareness...
>>>
>>> Hi Thomas,
>>>
>>> Long time no see. Sorry I use outlook which is not friendly to community
>>> email.
>>>
>>>> Anyway I will propose to replace this API in the next release.
>>> Will your plan be affected by API/ABI stable plan?
>>> BTW, if you propose new change in next release, it will make DPDK
>>> consumer(FD.io) to change again.
>>> So even if it is not affected to the API/ABI stable plan, do we still have time
>>> to get a solution for everyone in DPDK 19.11 with your
>>> contribution/acceleration?
>>>
>>>> I suspect a real hidden issue in Intel CPUs that you try to mitigate.
>>> Please be rest assured it is not the case.
>>> This request is just from one FD.io project internal bug " tx/rx burst function
>>> is shown as nil" reported by Chenmin.
>>
>> Why just the presenting string with function name (possible with suffix) is not enough?
>> I would like to see this API (strings approach) in mlx5 either, dropping the entire feature
>> does not look nice, as for me.
>>
>> We could consider some requirements for the name suffices to distinguish whether
>> function uses vector instructions and which ones if any.
>>
>>> My understanding is DPDK behavior was taken as bug for someone in FD.io
>>> project and potentially will mislead other DPDK consumer.
>>
>> Why does FD.io code want to know which vector extension is used by burst routines?
>> Is it going to share/preserve some resources (registers, etc.)? Is it robust ?
>> Burst routines might not know whether vector extensions is used (they might call
>> libraries, even rte_memcpy() can use vectors in implicit fashion).
>
> This is jut debug CLI print, it was added by me as a result of frustration of dealing constantly with
> operational issues where people are reporting lower performance caused by DPDK deciding
> for variety of reasons to switch from vector PMD to scalar one.
+1
I stated much the same elsewhere in this thread.
If your using DPDK in place of alternative, you are doing so for performance reasons.
If your performance drops in half becauses of configuration, you sure as hell want to understand why!
Today consuming applications get wildly different performance from DPDK based on configuration.
For me that is a huge usability issue and we can't leave the end user scratching their heads
wonder what is going on.
You program to our API and well take care of that doesn't cut it.
User in the field deal with real performance degradation and need information to solve problems.
This empowers them, and they shouldn't need to break out gdb to make it happen.
>
>>
>>> Haiyue is working with Chenmin to address the issue and with your support it
>>> will be even better.
>>>
>>> Your support will be highly appreciated!
>>>
>>> Thanks & Regards,
>>> Yu Liu
>>>
>>> -----Original Message-----
>>> From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
>>> Sent: Saturday, November 2, 2019 1:30 PM
>>> To: Thomas Monjalon <thomas@monjalon.net>
>>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
>>> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
>>> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
>>> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
>>> <viacheslavo@mellanox.com>
>>> Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting
>>> burst mode information
>>>
>>>> -----Original Message-----
>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>> Sent: Saturday, November 2, 2019 06:46
>>>> To: Wang, Haiyue <haiyue.wang@intel.com>
>>>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
>>>> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
>>>> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
>>>> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
>>>> <viacheslavo@mellanox.com>
>>>> Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst
>>>> mode information
>>>>
>>>> Thank you for trying to address comments done late.
>>>>
>>>> 31/10/2019 18:11, Haiyue Wang:
>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>>
>>>
>>>>> +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2)
>>>>> +#define RTE_ETH_BURST_NEON (1ULL << 3)
>>>>> +#define RTE_ETH_BURST_SSE (1ULL << 4)
>>>>> +#define RTE_ETH_BURST_AVX2 (1ULL << 5)
>>>>> +#define RTE_ETH_BURST_AVX512 (1ULL << 6)
>>>>
>>>> Of course, I still believe that giving a special treatment to vector
>>>> instructions is wrong.
>>>> You did not justify why it needs to be defined in bits instead of
>>>> string. I am not asking again because anyway you don't really reply. I
>>>> think you are executing an order you received and I don't want to
>>>> blame you more.
>>>> I suspect a real hidden issue in Intel CPUs that you try to mitigate.
>>>> No need to reply to this comment.
>>>> Anyway I will propose to replace this API in the next release.
>>>
>>> Never mind, if this design is truly ugly, drop it all now. I also prefer to do the
>>> best, that's why open source is amazing, thanks! ;-)
>>
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
2019-11-03 11:38 3% ` Wang, Haiyue
@ 2019-11-03 19:31 0% ` Slava Ovsiienko
2019-11-04 1:01 0% ` Wang, Haiyue
0 siblings, 1 reply; 200+ results
From: Slava Ovsiienko @ 2019-11-03 19:31 UTC (permalink / raw)
To: Wang, Haiyue, Liu, Yu Y, Thomas Monjalon
Cc: dev, arybchenko, Yigit, Ferruh, jerinjacobk, Ye, Xiaolong,
Kinsella, Ray, Sun, Chenmin, Damjan Marion (damarion)
Hi, Haiyue
> -----Original Message-----
> From: Wang, Haiyue <haiyue.wang@intel.com>
> Sent: Sunday, November 3, 2019 13:38
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Liu, Yu Y
> <yu.y.liu@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion)
> <damarion@cisco.com>
> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
> information
>
> Hi Slava,
>
> > -----Original Message-----
> > From: Slava Ovsiienko <viacheslavo@mellanox.com>
> > Sent: Sunday, November 3, 2019 16:59
> > To: Wang, Haiyue <haiyue.wang@intel.com>; Liu, Yu Y
> <yu.y.liu@intel.com>; Thomas Monjalon
> > <thomas@monjalon.net>
> > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>;
> > jerinjacobk@gmail.com; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella,
> Ray <ray.kinsella@intel.com>;
> > Sun, Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion)
> <damarion@cisco.com>
> > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> mode information
> >
> > > -----Original Message-----
> > > From: Wang, Haiyue <haiyue.wang@intel.com>
> > > Sent: Sunday, November 3, 2019 4:34
> > > To: Slava Ovsiienko <viacheslavo@mellanox.com>; Liu, Yu Y
> > > <yu.y.liu@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > > Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion)
> > > <damarion@cisco.com>
> > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> mode
> > > information
> > >
> > > Hi Thomas, Slava,
> > >
> > > Please see the inline reply in one place.
> > >
> > > > -----Original Message-----
> > > > From: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > Sent: Saturday, November 2, 2019 16:39
> > > > To: Liu, Yu Y <yu.y.liu@intel.com>; Wang, Haiyue
> > > > <haiyue.wang@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > > > Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion)
> > > > <damarion@cisco.com>
> > > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> > > > mode information
> > > >
> > > > Hi
> > > > > -----Original Message-----
> > > > > From: Liu, Yu Y <yu.y.liu@intel.com>
> > > > > Sent: Saturday, November 2, 2019 8:56
> > > > > To: Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
> > > > > <thomas@monjalon.net>
> > > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > > > Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > > > <viacheslavo@mellanox.com>; Damjan Marion (damarion)
> > > > > <damarion@cisco.com>; Liu, Yu Y <yu.y.liu@intel.com>
> > > > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting
> > > > > burst mode information
> > > > >
> > > > > Add Damjan from FD.io for awareness...
> > > > >
> > > > > Hi Thomas,
> > > > >
> > > > > Long time no see. Sorry I use outlook which is not friendly to
> > > > > community email.
> > > > >
> > > > > >Anyway I will propose to replace this API in the next release.
> > > > > Will your plan be affected by API/ABI stable plan?
> > > > > BTW, if you propose new change in next release, it will make DPDK
> > > > > consumer(FD.io) to change again.
> > > > > So even if it is not affected to the API/ABI stable plan, do we
> > > > > still have time to get a solution for everyone in DPDK 19.11 with
> > > > > your contribution/acceleration?
> > > > >
> > > > > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > > > > Please be rest assured it is not the case.
> > > > > This request is just from one FD.io project internal bug " tx/rx
> > > > > burst function is shown as nil" reported by Chenmin.
> > > >
> > > > Why just the presenting string with function name (possible with suffix)
> is
> > > not enough?
> > > > I would like to see this API (strings approach) in mlx5 either,
> > > > dropping the entire feature does not look nice, as for me.
> > > >
> > > > We could consider some requirements for the name suffices to
> > > > distinguish whether function uses vector instructions and which ones if
> any.
> > > >
> > > > > My understanding is DPDK behavior was taken as bug for someone in
> > > > > FD.io project and potentially will mislead other DPDK consumer.
> > > >
> > > > Why does FD.io code want to know which vector extension is used by
> burst
> > > routines?
> > > > Is it going to share/preserve some resources (registers, etc.)? Is it
> robust ?
> > > > Burst routines might not know whether vector extensions is used (they
> > > > might call libraries, even rte_memcpy() can use vectors in implicit
> fashion).
> > > >
> > >
> > > 1.
> > >
> > > The original issue description is:
> > > "VPP uses dladdr() to translate a function address to name, however,
> some
> > > tx/rx functions in DPDK are invisible for dladdr(), which is because they
> are
> > > defined as static."
> > >
> > > 2.
> > >
> > > So the RFC design is: one function, one description, like:
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> > >
> work.dpdk.org%2Fpatch%2F57644%2F&data=02%7C01%7Cviacheslavo
> > >
> %40mellanox.com%7Ca99632b4e2444ec00b1f08d760065041%7Ca652971c7
> > >
> d2e4d9ba6a4d149256f461b%7C0%7C0%7C637083452540980873&sdat
> > >
> a=4re5GOXPSwGk5BTOYLglafzgjBzRLk1gXyWKT47o8o0%3D&reserved=
> > > 0
> > >
> > > +#ifdef RTE_ARCH_X86
> > > + else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec_avx2)
> > > + len = snprintf(buf, sz, "AVX2 Vector Scattered Rx");
> > > + else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec)
> > > + len = snprintf(buf, sz, "Vector Scattered Rx");
> > > + else if (dev->rx_pkt_burst == ice_recv_pkts_vec_avx2)
> > > + len = snprintf(buf, sz, "AVX2 Vector Rx");
> > > + else if (dev->rx_pkt_burst == ice_recv_pkts_vec)
> > > + len = snprintf(buf, sz, "Vector Rx"); #endif
> > The application gets the routine names with dladdr(). OK, it happens.
> > It is not clear for me why instead of direct replacement/extension of dladdr
> > functionality some new names were introduced and then converted to
> flags.
> >
>
> Sorry, can you explain more ? Who 'direct replacement/extension of dladdr'
> ?
> VPP, or DPDK ?
>
> > > 3. Since the main issue is as Damjan replied in another thread:
> > > "people are reporting lower performance caused by DPDK deciding for
> > > variety
> > > of reasons to switch from vector PMD to scalar one."
> > >
> > > And Ferruh replied also:
> > > "As I understand this is to let applications to give informed decision
> based
> > > on what vectorization is used in the driver, currently this is not known
> by
> > > the application.
> > >
> > > And as previously replied, the main target of the API is to define the
> vector
> > > path, not all optimizations, so the number is limited."
> > >
> > > So we enhanced it with bit, example detail is (Yes, we defined a lit
> more,
> > > so we removed it in this patch):
> >
> > There are might be a lot of various burst functions, vectorized or not,
> > with various sets of supported offloads. Yes, identifying the engaged burst
> > routine is meaningful, but it is not clear for me, why the vectorizing type
> > should have dedicated means (flags) to identify ?
> >
>
> The new 'rte_eth_rx/tx_burst_mode_get' works like logging, but in fact, the
> log
> message is something special, like "Vector Neon/AltiVec/SSE/AVX2" and the
> device
> specific offloads as you said.
>
> This kind of string "Vector Neon/AltiVec/SSE/AVX2" can be common, we not
> treat it
> as 'flag', it is a normal bit like macro definition, and it will be translated into
> string later. And we want to make PMD's string format life to be easy, don't
> need
> to call 'snprintf/sprintf' with the copied string format.
>
> So now, the log message format is: device specific (if have) + "Vector ..." (if
> have, this is not MUST, if the PMD doesn't use vector, but at least, this is not
> hardware specific, it is some common from arch:
> lib/librte_eal/common/arch/arm,ppc_64,x86).
>
> Further, as a SDK, the API exposes these common bit data for application
> easily access
> if it may need, DON'T NEED TO BREAK THE ABI/API. Compared to
> 'strstr/strcasestr',
> 'mode->options & RTE_ETH_BURST_VECTOR' is more friendly ?
Yes, it is more friendly for app. But there is quite another question: do we really
need these flags for logging purposes ? There are no explicitly expressed
requirements from applications for these flags.
> > >
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> > >
> work.dpdk.org%2Fpatch%2F61196%2F&data=02%7C01%7Cviacheslavo
> > >
> %40mellanox.com%7Ca99632b4e2444ec00b1f08d760065041%7Ca652971c7
> > >
> d2e4d9ba6a4d149256f461b%7C0%7C0%7C637083452540980873&sdat
> > >
> a=nm80Pt0fFWqmmrJcKY6ks4qRTJ7cjGJWEG1Wv6gxfSw%3D&reserved
> > > =0
> > >
> > > 4. And thanks Jerin's suggestion, I think his word can be more accurate:
> "This
> > > would
> > > help to reuse some of the flags to name conversion logic across all
> PMDs"
> > > for the
> > > reason we try to use bit to reduce some string format effort, it will be
> > > handled
> > > by the API internally "burst_mode_options_append(struct
> > > rte_eth_burst_mode *mode)".
> > > Now the new API will return the string finally:
> > >
> > > #define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 1024 struct
> > > rte_eth_burst_mode {
> > > uint64_t options;
> > >
> > > /**< Each PMD can fill specific burst mode information into this, and
> > > * ethdev APIs will append the 'options' string format at its end.
> > > */
> > > char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
> > > };
> > >
> > > So MLX PMD can add 'full_empw', 'mtsc_empw' etc into
> 'alternate_options'
> > > firstly, assign 'RTE_ETH_BURST_VECTOR | RTE_ETH_BURST_SSE' to
> 'options'
> > > as needed, then finally, 'alternate_options' will be "full_empw, Vector
> SSE".
> >
> > For mlx5 tx_burst these flags have no meaning. All information regarding
> routine
> > is encoded within the name, mtsc stands for:
> > m - multisegment
> > t - TSO
> > s - software tunnel parser
> > c - check sum
> >
> > There are no two versions of mtsc_empw - "mtsc_empw, Vector SSE",
> "mtsc_empw, Vector Neon".
> > If we developed vectorized version, I would prefer "mtsc_empw_sse".
> >
> > To summarize:
> > - application uses routine names, gets with dladdr(). Nice.
> > - compatible API providing names of internal routines is proposed. Nice.
> > - users now are able to identify the engaged burst routine. Nice.
> > - proposed API is extended, some vector related flags were added.
> Hmmm.... Questionable.
> > Why vector related only? Why do we change the string format? (name ->
> name, options)
>
> Again, vector is not "only", it is just 'main' characteristic "tree ./drivers/net/ |
> grep rxtx_".
> we can design the Rx/Tx burst function mainly by vector type, it is
> straightforward.
OK, we have some flag field proposed. Saying "why vector only" I meant
that vectorizing is just one of optimizing technics. I do not see it as
"main tree characteristics", sorry.
What if some other vendor would like to add its own flags? For example,
mlx5 could add at least 8 optimizing flags for tx_burst and 4 flags for rx_burst
(besides vector related ones). Why not? Why do we decide to add vector flags only?
Other vendors might come into play and add its own flags describing the burst routine
features and optimizations. And then say - "hey, these parameters define our
internal rxtx tree. It is very critical for performance, user must know about ones".
>
> Why 'name -> name' ?
Sorry for the MS Outlook (and I'm on the way to Mutt now),
it is not community friendly.
Correct sentence: "name" to "name, options"
> 1.) [v4,4/4] app/testpmd: show the Rx/Tx burst mode description
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%
> 2Fpatchwork.dpdk.org%2Fpatch%2F61198%2F&data=02%7C01%7Cviac
> heslavo%40mellanox.com%7C0ba4e73594684f944b7608d760525c97%7Ca6
> 52971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637083779173049231&a
> mp;sdata=2NCHJJpsAYsb07FTEmvr4EiIVudm7ZCVhemh2g1MBG0%3D&r
> eserved=0
> This is handled by the application itself, not so friendly, many lines of code to
> show.
Yes, it does not look nice, as for me. String should be simple and just provided by PMD,
without any extra flags/options, IMHO.
>
>
> 2). [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
> information
> if (rte_eth_tx_burst_mode_get(port_id, queue_id, &mode) == 0)
> printf("\nBurst mode: %s", mode.alternate_options);
>
> This design may meet your question above if I understand correctly.
> "It is not clear for me why instead of direct replacement/extension
> of dladdr
> functionality some new names were introduced and then converted to
> flags".
>
>
> Last, again, we define the bits 'RTE_ETH_BURST_XXX' for making the log
> message
> generation process easily if you agree vector type is common, the vector can
> be
Simple string returned by PMD eliminates "message process generation" at all.
No flags/options - no generation needed at all. In my opinion, PMD just should
return strings like "rx_burst_vector_sse", "rx_burst_vector_neon", etc.
> used to improve the performance. And if new burst design can be used for
> most
> PMDs, use it as bit, the API helps to translate it to string. And the application
> can use the bit to do other kind of information display.
>
> We define it a little more than 'simple string' for just making life easy. In fact,
> the patch comes from "simple string", RFC v1, v2, v3, PATCH v1 v2 v3 v4.
Applications live OK with dladdr(). The returned name is used for logging.
There is NO explicit requirements from application to provide some extra options,
besides the name (or, at least, these ones are not visible for me).
Sorry, it is not clear for me, how by introducing extra flags and the extra
"easy message generation process" we make life easier. If PMD just provides
the simple string "rx_burst_vector_sse", everyone seeing this string in the log
understands what and how the named rx_burst is doing, right? Do you think
the message like "rx_burst, Vector SSE" looks better? OK, your PMD
is free to return it.
Honestly, I do not mind against flags strictly, but I do not see any new meanings
introduced by flags. It requires extra code, it might introduce some ambiguity,
it would be ridiculous to see something like that:
"rx_burst_vector_neon, Vector_AVX"
And, the last, the flag field is a potential scarce resource for vendors.
With best regards, Slava
> >
> >
> > > Intel PMD can just assign "options", then finally, 'alternate_options' will
> be
> > > "Vector SSE".
> >
> > As I see from initial patch, Intel PMD has dedicated routines with unique
> names for
> > each type of vectorization. Is there some burst routine with single name
> which could
> > operate with different vectorization types, depending on configuration?
> >
> > With best regards, Slava
> >
> > >
> > > How about the design idea ? Again, this 'options' is not to do
> standardization,
> > > just want to reduce the duplicated name string things.
> > >
> > > > With best regards, Slava
> > > >
> > > > > Haiyue is working with Chenmin to address the issue and with your
> > > > > support it will be even better.
> > > > >
> > > > > Your support will be highly appreciated!
> > > > >
> > > > > Thanks & Regards,
> > > > > Yu Liu
> > > > >
> > > > > -----Original Message-----
> > > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
> > > > > Sent: Saturday, November 2, 2019 1:30 PM
> > > > > To: Thomas Monjalon <thomas@monjalon.net>
> > > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > > > Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > > > <viacheslavo@mellanox.com>
> > > > > Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for
> > > > > getting burst mode information
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > Sent: Saturday, November 2, 2019 06:46
> > > > > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > > > > Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > > > > <viacheslavo@mellanox.com>
> > > > > > Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting
> > > > > > burst mode information
> > > > > >
> > > > > > Thank you for trying to address comments done late.
> > > > > >
> > > > > > 31/10/2019 18:11, Haiyue Wang:
> > > > > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > >
> > > > >
> > > > > > > +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2)
> > > > > > > +#define RTE_ETH_BURST_NEON (1ULL << 3)
> > > > > > > +#define RTE_ETH_BURST_SSE (1ULL << 4)
> > > > > > > +#define RTE_ETH_BURST_AVX2 (1ULL << 5)
> > > > > > > +#define RTE_ETH_BURST_AVX512 (1ULL << 6)
> > > > > >
> > > > > > Of course, I still believe that giving a special treatment to
> > > > > > vector instructions is wrong.
> > > > > > You did not justify why it needs to be defined in bits instead of
> > > > > > string. I am not asking again because anyway you don't really
> > > > > > reply. I think you are executing an order you received and I don't
> > > > > > want to blame you more.
> > > > > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > > > > > No need to reply to this comment.
> > > > > > Anyway I will propose to replace this API in the next release.
> > > > >
> > > > > Never mind, if this design is truly ugly, drop it all now. I also
> > > > > prefer to do the best, that's why open source is amazing, thanks!
> > > > > ;-)
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
2019-11-03 8:59 0% ` Slava Ovsiienko
@ 2019-11-03 11:38 3% ` Wang, Haiyue
2019-11-03 19:31 0% ` Slava Ovsiienko
0 siblings, 1 reply; 200+ results
From: Wang, Haiyue @ 2019-11-03 11:38 UTC (permalink / raw)
To: Slava Ovsiienko, Liu, Yu Y, Thomas Monjalon
Cc: dev, arybchenko, Yigit, Ferruh, jerinjacobk, Ye, Xiaolong,
Kinsella, Ray, Sun, Chenmin, Damjan Marion (damarion)
Hi Slava,
> -----Original Message-----
> From: Slava Ovsiienko <viacheslavo@mellanox.com>
> Sent: Sunday, November 3, 2019 16:59
> To: Wang, Haiyue <haiyue.wang@intel.com>; Liu, Yu Y <yu.y.liu@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> jerinjacobk@gmail.com; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Sun, Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion) <damarion@cisco.com>
> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
>
> > -----Original Message-----
> > From: Wang, Haiyue <haiyue.wang@intel.com>
> > Sent: Sunday, November 3, 2019 4:34
> > To: Slava Ovsiienko <viacheslavo@mellanox.com>; Liu, Yu Y
> > <yu.y.liu@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion)
> > <damarion@cisco.com>
> > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
> > information
> >
> > Hi Thomas, Slava,
> >
> > Please see the inline reply in one place.
> >
> > > -----Original Message-----
> > > From: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > Sent: Saturday, November 2, 2019 16:39
> > > To: Liu, Yu Y <yu.y.liu@intel.com>; Wang, Haiyue
> > > <haiyue.wang@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > > Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion)
> > > <damarion@cisco.com>
> > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> > > mode information
> > >
> > > Hi
> > > > -----Original Message-----
> > > > From: Liu, Yu Y <yu.y.liu@intel.com>
> > > > Sent: Saturday, November 2, 2019 8:56
> > > > To: Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
> > > > <thomas@monjalon.net>
> > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > > Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > > <viacheslavo@mellanox.com>; Damjan Marion (damarion)
> > > > <damarion@cisco.com>; Liu, Yu Y <yu.y.liu@intel.com>
> > > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting
> > > > burst mode information
> > > >
> > > > Add Damjan from FD.io for awareness...
> > > >
> > > > Hi Thomas,
> > > >
> > > > Long time no see. Sorry I use outlook which is not friendly to
> > > > community email.
> > > >
> > > > >Anyway I will propose to replace this API in the next release.
> > > > Will your plan be affected by API/ABI stable plan?
> > > > BTW, if you propose new change in next release, it will make DPDK
> > > > consumer(FD.io) to change again.
> > > > So even if it is not affected to the API/ABI stable plan, do we
> > > > still have time to get a solution for everyone in DPDK 19.11 with
> > > > your contribution/acceleration?
> > > >
> > > > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > > > Please be rest assured it is not the case.
> > > > This request is just from one FD.io project internal bug " tx/rx
> > > > burst function is shown as nil" reported by Chenmin.
> > >
> > > Why just the presenting string with function name (possible with suffix) is
> > not enough?
> > > I would like to see this API (strings approach) in mlx5 either,
> > > dropping the entire feature does not look nice, as for me.
> > >
> > > We could consider some requirements for the name suffices to
> > > distinguish whether function uses vector instructions and which ones if any.
> > >
> > > > My understanding is DPDK behavior was taken as bug for someone in
> > > > FD.io project and potentially will mislead other DPDK consumer.
> > >
> > > Why does FD.io code want to know which vector extension is used by burst
> > routines?
> > > Is it going to share/preserve some resources (registers, etc.)? Is it robust ?
> > > Burst routines might not know whether vector extensions is used (they
> > > might call libraries, even rte_memcpy() can use vectors in implicit fashion).
> > >
> >
> > 1.
> >
> > The original issue description is:
> > "VPP uses dladdr() to translate a function address to name, however, some
> > tx/rx functions in DPDK are invisible for dladdr(), which is because they are
> > defined as static."
> >
> > 2.
> >
> > So the RFC design is: one function, one description, like:
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> > work.dpdk.org%2Fpatch%2F57644%2F&data=02%7C01%7Cviacheslavo
> > %40mellanox.com%7Ca99632b4e2444ec00b1f08d760065041%7Ca652971c7
> > d2e4d9ba6a4d149256f461b%7C0%7C0%7C637083452540980873&sdat
> > a=4re5GOXPSwGk5BTOYLglafzgjBzRLk1gXyWKT47o8o0%3D&reserved=
> > 0
> >
> > +#ifdef RTE_ARCH_X86
> > + else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec_avx2)
> > + len = snprintf(buf, sz, "AVX2 Vector Scattered Rx");
> > + else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec)
> > + len = snprintf(buf, sz, "Vector Scattered Rx");
> > + else if (dev->rx_pkt_burst == ice_recv_pkts_vec_avx2)
> > + len = snprintf(buf, sz, "AVX2 Vector Rx");
> > + else if (dev->rx_pkt_burst == ice_recv_pkts_vec)
> > + len = snprintf(buf, sz, "Vector Rx"); #endif
> The application gets the routine names with dladdr(). OK, it happens.
> It is not clear for me why instead of direct replacement/extension of dladdr
> functionality some new names were introduced and then converted to flags.
>
Sorry, can you explain more ? Who 'direct replacement/extension of dladdr' ?
VPP, or DPDK ?
> > 3. Since the main issue is as Damjan replied in another thread:
> > "people are reporting lower performance caused by DPDK deciding for
> > variety
> > of reasons to switch from vector PMD to scalar one."
> >
> > And Ferruh replied also:
> > "As I understand this is to let applications to give informed decision based
> > on what vectorization is used in the driver, currently this is not known by
> > the application.
> >
> > And as previously replied, the main target of the API is to define the vector
> > path, not all optimizations, so the number is limited."
> >
> > So we enhanced it with bit, example detail is (Yes, we defined a lit more,
> > so we removed it in this patch):
>
> There are might be a lot of various burst functions, vectorized or not,
> with various sets of supported offloads. Yes, identifying the engaged burst
> routine is meaningful, but it is not clear for me, why the vectorizing type
> should have dedicated means (flags) to identify ?
>
The new 'rte_eth_rx/tx_burst_mode_get' works like logging, but in fact, the log
message is something special, like "Vector Neon/AltiVec/SSE/AVX2" and the device
specific offloads as you said.
This kind of string "Vector Neon/AltiVec/SSE/AVX2" can be common, we not treat it
as 'flag', it is a normal bit like macro definition, and it will be translated into
string later. And we want to make PMD's string format life to be easy, don't need
to call 'snprintf/sprintf' with the copied string format.
So now, the log message format is: device specific (if have) + "Vector ..." (if
have, this is not MUST, if the PMD doesn't use vector, but at least, this is not
hardware specific, it is some common from arch: lib/librte_eal/common/arch/arm,ppc_64,x86).
Further, as a SDK, the API exposes these common bit data for application easily access
if it may need, DON'T NEED TO BREAK THE ABI/API. Compared to 'strstr/strcasestr',
'mode->options & RTE_ETH_BURST_VECTOR' is more friendly ?
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> > work.dpdk.org%2Fpatch%2F61196%2F&data=02%7C01%7Cviacheslavo
> > %40mellanox.com%7Ca99632b4e2444ec00b1f08d760065041%7Ca652971c7
> > d2e4d9ba6a4d149256f461b%7C0%7C0%7C637083452540980873&sdat
> > a=nm80Pt0fFWqmmrJcKY6ks4qRTJ7cjGJWEG1Wv6gxfSw%3D&reserved
> > =0
> >
> > 4. And thanks Jerin's suggestion, I think his word can be more accurate: "This
> > would
> > help to reuse some of the flags to name conversion logic across all PMDs"
> > for the
> > reason we try to use bit to reduce some string format effort, it will be
> > handled
> > by the API internally "burst_mode_options_append(struct
> > rte_eth_burst_mode *mode)".
> > Now the new API will return the string finally:
> >
> > #define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 1024 struct
> > rte_eth_burst_mode {
> > uint64_t options;
> >
> > /**< Each PMD can fill specific burst mode information into this, and
> > * ethdev APIs will append the 'options' string format at its end.
> > */
> > char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
> > };
> >
> > So MLX PMD can add 'full_empw', 'mtsc_empw' etc into 'alternate_options'
> > firstly, assign 'RTE_ETH_BURST_VECTOR | RTE_ETH_BURST_SSE' to 'options'
> > as needed, then finally, 'alternate_options' will be "full_empw, Vector SSE".
>
> For mlx5 tx_burst these flags have no meaning. All information regarding routine
> is encoded within the name, mtsc stands for:
> m - multisegment
> t - TSO
> s - software tunnel parser
> c - check sum
>
> There are no two versions of mtsc_empw - "mtsc_empw, Vector SSE", "mtsc_empw, Vector Neon".
> If we developed vectorized version, I would prefer "mtsc_empw_sse".
>
> To summarize:
> - application uses routine names, gets with dladdr(). Nice.
> - compatible API providing names of internal routines is proposed. Nice.
> - users now are able to identify the engaged burst routine. Nice.
> - proposed API is extended, some vector related flags were added. Hmmm.... Questionable.
> Why vector related only? Why do we change the string format? (name -> name, options)
Again, vector is not "only", it is just 'main' characteristic "tree ./drivers/net/ | grep rxtx_".
we can design the Rx/Tx burst function mainly by vector type, it is straightforward.
Why 'name -> name' ?
1.) [v4,4/4] app/testpmd: show the Rx/Tx burst mode description
https://patchwork.dpdk.org/patch/61198/
This is handled by the application itself, not so friendly, many lines of code to show.
2). [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
if (rte_eth_tx_burst_mode_get(port_id, queue_id, &mode) == 0)
printf("\nBurst mode: %s", mode.alternate_options);
This design may meet your question above if I understand correctly.
"It is not clear for me why instead of direct replacement/extension of dladdr
functionality some new names were introduced and then converted to flags".
Last, again, we define the bits 'RTE_ETH_BURST_XXX' for making the log message
generation process easily if you agree vector type is common, the vector can be
used to improve the performance. And if new burst design can be used for most
PMDs, use it as bit, the API helps to translate it to string. And the application
can use the bit to do other kind of information display.
We define it a little more than 'simple string' for just making life easy. In fact,
the patch comes from "simple string", RFC v1, v2, v3, PATCH v1 v2 v3 v4.
>
>
> > Intel PMD can just assign "options", then finally, 'alternate_options' will be
> > "Vector SSE".
>
> As I see from initial patch, Intel PMD has dedicated routines with unique names for
> each type of vectorization. Is there some burst routine with single name which could
> operate with different vectorization types, depending on configuration?
>
> With best regards, Slava
>
> >
> > How about the design idea ? Again, this 'options' is not to do standardization,
> > just want to reduce the duplicated name string things.
> >
> > > With best regards, Slava
> > >
> > > > Haiyue is working with Chenmin to address the issue and with your
> > > > support it will be even better.
> > > >
> > > > Your support will be highly appreciated!
> > > >
> > > > Thanks & Regards,
> > > > Yu Liu
> > > >
> > > > -----Original Message-----
> > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
> > > > Sent: Saturday, November 2, 2019 1:30 PM
> > > > To: Thomas Monjalon <thomas@monjalon.net>
> > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > > Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > > <viacheslavo@mellanox.com>
> > > > Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for
> > > > getting burst mode information
> > > >
> > > > > -----Original Message-----
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > Sent: Saturday, November 2, 2019 06:46
> > > > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > > > Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > > > <viacheslavo@mellanox.com>
> > > > > Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting
> > > > > burst mode information
> > > > >
> > > > > Thank you for trying to address comments done late.
> > > > >
> > > > > 31/10/2019 18:11, Haiyue Wang:
> > > > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > >
> > > >
> > > > > > +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2)
> > > > > > +#define RTE_ETH_BURST_NEON (1ULL << 3)
> > > > > > +#define RTE_ETH_BURST_SSE (1ULL << 4)
> > > > > > +#define RTE_ETH_BURST_AVX2 (1ULL << 5)
> > > > > > +#define RTE_ETH_BURST_AVX512 (1ULL << 6)
> > > > >
> > > > > Of course, I still believe that giving a special treatment to
> > > > > vector instructions is wrong.
> > > > > You did not justify why it needs to be defined in bits instead of
> > > > > string. I am not asking again because anyway you don't really
> > > > > reply. I think you are executing an order you received and I don't
> > > > > want to blame you more.
> > > > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > > > > No need to reply to this comment.
> > > > > Anyway I will propose to replace this API in the next release.
> > > >
> > > > Never mind, if this design is truly ugly, drop it all now. I also
> > > > prefer to do the best, that's why open source is amazing, thanks!
> > > > ;-)
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
2019-11-03 2:34 0% ` Wang, Haiyue
2019-11-03 3:03 0% ` Wang, Haiyue
@ 2019-11-03 8:59 0% ` Slava Ovsiienko
2019-11-03 11:38 3% ` Wang, Haiyue
1 sibling, 1 reply; 200+ results
From: Slava Ovsiienko @ 2019-11-03 8:59 UTC (permalink / raw)
To: Wang, Haiyue, Liu, Yu Y, Thomas Monjalon
Cc: dev, arybchenko, Yigit, Ferruh, jerinjacobk, Ye, Xiaolong,
Kinsella, Ray, Sun, Chenmin, Damjan Marion (damarion)
> -----Original Message-----
> From: Wang, Haiyue <haiyue.wang@intel.com>
> Sent: Sunday, November 3, 2019 4:34
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Liu, Yu Y
> <yu.y.liu@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion)
> <damarion@cisco.com>
> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
> information
>
> Hi Thomas, Slava,
>
> Please see the inline reply in one place.
>
> > -----Original Message-----
> > From: Slava Ovsiienko <viacheslavo@mellanox.com>
> > Sent: Saturday, November 2, 2019 16:39
> > To: Liu, Yu Y <yu.y.liu@intel.com>; Wang, Haiyue
> > <haiyue.wang@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion)
> > <damarion@cisco.com>
> > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> > mode information
> >
> > Hi
> > > -----Original Message-----
> > > From: Liu, Yu Y <yu.y.liu@intel.com>
> > > Sent: Saturday, November 2, 2019 8:56
> > > To: Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
> > > <thomas@monjalon.net>
> > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > <viacheslavo@mellanox.com>; Damjan Marion (damarion)
> > > <damarion@cisco.com>; Liu, Yu Y <yu.y.liu@intel.com>
> > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting
> > > burst mode information
> > >
> > > Add Damjan from FD.io for awareness...
> > >
> > > Hi Thomas,
> > >
> > > Long time no see. Sorry I use outlook which is not friendly to
> > > community email.
> > >
> > > >Anyway I will propose to replace this API in the next release.
> > > Will your plan be affected by API/ABI stable plan?
> > > BTW, if you propose new change in next release, it will make DPDK
> > > consumer(FD.io) to change again.
> > > So even if it is not affected to the API/ABI stable plan, do we
> > > still have time to get a solution for everyone in DPDK 19.11 with
> > > your contribution/acceleration?
> > >
> > > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > > Please be rest assured it is not the case.
> > > This request is just from one FD.io project internal bug " tx/rx
> > > burst function is shown as nil" reported by Chenmin.
> >
> > Why just the presenting string with function name (possible with suffix) is
> not enough?
> > I would like to see this API (strings approach) in mlx5 either,
> > dropping the entire feature does not look nice, as for me.
> >
> > We could consider some requirements for the name suffices to
> > distinguish whether function uses vector instructions and which ones if any.
> >
> > > My understanding is DPDK behavior was taken as bug for someone in
> > > FD.io project and potentially will mislead other DPDK consumer.
> >
> > Why does FD.io code want to know which vector extension is used by burst
> routines?
> > Is it going to share/preserve some resources (registers, etc.)? Is it robust ?
> > Burst routines might not know whether vector extensions is used (they
> > might call libraries, even rte_memcpy() can use vectors in implicit fashion).
> >
>
> 1.
>
> The original issue description is:
> "VPP uses dladdr() to translate a function address to name, however, some
> tx/rx functions in DPDK are invisible for dladdr(), which is because they are
> defined as static."
>
> 2.
>
> So the RFC design is: one function, one description, like:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.dpdk.org%2Fpatch%2F57644%2F&data=02%7C01%7Cviacheslavo
> %40mellanox.com%7Ca99632b4e2444ec00b1f08d760065041%7Ca652971c7
> d2e4d9ba6a4d149256f461b%7C0%7C0%7C637083452540980873&sdat
> a=4re5GOXPSwGk5BTOYLglafzgjBzRLk1gXyWKT47o8o0%3D&reserved=
> 0
>
> +#ifdef RTE_ARCH_X86
> + else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec_avx2)
> + len = snprintf(buf, sz, "AVX2 Vector Scattered Rx");
> + else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec)
> + len = snprintf(buf, sz, "Vector Scattered Rx");
> + else if (dev->rx_pkt_burst == ice_recv_pkts_vec_avx2)
> + len = snprintf(buf, sz, "AVX2 Vector Rx");
> + else if (dev->rx_pkt_burst == ice_recv_pkts_vec)
> + len = snprintf(buf, sz, "Vector Rx"); #endif
The application gets the routine names with dladdr(). OK, it happens.
It is not clear for me why instead of direct replacement/extension of dladdr
functionality some new names were introduced and then converted to flags.
> 3. Since the main issue is as Damjan replied in another thread:
> "people are reporting lower performance caused by DPDK deciding for
> variety
> of reasons to switch from vector PMD to scalar one."
>
> And Ferruh replied also:
> "As I understand this is to let applications to give informed decision based
> on what vectorization is used in the driver, currently this is not known by
> the application.
>
> And as previously replied, the main target of the API is to define the vector
> path, not all optimizations, so the number is limited."
>
> So we enhanced it with bit, example detail is (Yes, we defined a lit more,
> so we removed it in this patch):
There are might be a lot of various burst functions, vectorized or not,
with various sets of supported offloads. Yes, identifying the engaged burst
routine is meaningful, but it is not clear for me, why the vectorizing type
should have dedicated means (flags) to identify ?
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.dpdk.org%2Fpatch%2F61196%2F&data=02%7C01%7Cviacheslavo
> %40mellanox.com%7Ca99632b4e2444ec00b1f08d760065041%7Ca652971c7
> d2e4d9ba6a4d149256f461b%7C0%7C0%7C637083452540980873&sdat
> a=nm80Pt0fFWqmmrJcKY6ks4qRTJ7cjGJWEG1Wv6gxfSw%3D&reserved
> =0
>
> 4. And thanks Jerin's suggestion, I think his word can be more accurate: "This
> would
> help to reuse some of the flags to name conversion logic across all PMDs"
> for the
> reason we try to use bit to reduce some string format effort, it will be
> handled
> by the API internally "burst_mode_options_append(struct
> rte_eth_burst_mode *mode)".
> Now the new API will return the string finally:
>
> #define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 1024 struct
> rte_eth_burst_mode {
> uint64_t options;
>
> /**< Each PMD can fill specific burst mode information into this, and
> * ethdev APIs will append the 'options' string format at its end.
> */
> char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
> };
>
> So MLX PMD can add 'full_empw', 'mtsc_empw' etc into 'alternate_options'
> firstly, assign 'RTE_ETH_BURST_VECTOR | RTE_ETH_BURST_SSE' to 'options'
> as needed, then finally, 'alternate_options' will be "full_empw, Vector SSE".
For mlx5 tx_burst these flags have no meaning. All information regarding routine
is encoded within the name, mtsc stands for:
m - multisegment
t - TSO
s - software tunnel parser
c - check sum
There are no two versions of mtsc_empw - "mtsc_empw, Vector SSE", "mtsc_empw, Vector Neon".
If we developed vectorized version, I would prefer "mtsc_empw_sse".
To summarize:
- application uses routine names, gets with dladdr(). Nice.
- compatible API providing names of internal routines is proposed. Nice.
- users now are able to identify the engaged burst routine. Nice.
- proposed API is extended, some vector related flags were added. Hmmm.... Questionable.
Why vector related only? Why do we change the string format? (name -> name, options)
> Intel PMD can just assign "options", then finally, 'alternate_options' will be
> "Vector SSE".
As I see from initial patch, Intel PMD has dedicated routines with unique names for
each type of vectorization. Is there some burst routine with single name which could
operate with different vectorization types, depending on configuration?
With best regards, Slava
>
> How about the design idea ? Again, this 'options' is not to do standardization,
> just want to reduce the duplicated name string things.
>
> > With best regards, Slava
> >
> > > Haiyue is working with Chenmin to address the issue and with your
> > > support it will be even better.
> > >
> > > Your support will be highly appreciated!
> > >
> > > Thanks & Regards,
> > > Yu Liu
> > >
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
> > > Sent: Saturday, November 2, 2019 1:30 PM
> > > To: Thomas Monjalon <thomas@monjalon.net>
> > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > <viacheslavo@mellanox.com>
> > > Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for
> > > getting burst mode information
> > >
> > > > -----Original Message-----
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > Sent: Saturday, November 2, 2019 06:46
> > > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > > Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > > <viacheslavo@mellanox.com>
> > > > Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting
> > > > burst mode information
> > > >
> > > > Thank you for trying to address comments done late.
> > > >
> > > > 31/10/2019 18:11, Haiyue Wang:
> > > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > >
> > >
> > > > > +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2)
> > > > > +#define RTE_ETH_BURST_NEON (1ULL << 3)
> > > > > +#define RTE_ETH_BURST_SSE (1ULL << 4)
> > > > > +#define RTE_ETH_BURST_AVX2 (1ULL << 5)
> > > > > +#define RTE_ETH_BURST_AVX512 (1ULL << 6)
> > > >
> > > > Of course, I still believe that giving a special treatment to
> > > > vector instructions is wrong.
> > > > You did not justify why it needs to be defined in bits instead of
> > > > string. I am not asking again because anyway you don't really
> > > > reply. I think you are executing an order you received and I don't
> > > > want to blame you more.
> > > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > > > No need to reply to this comment.
> > > > Anyway I will propose to replace this API in the next release.
> > >
> > > Never mind, if this design is truly ugly, drop it all now. I also
> > > prefer to do the best, that's why open source is amazing, thanks!
> > > ;-)
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
2019-11-02 19:21 0% ` Damjan Marion (damarion)
@ 2019-11-03 7:50 0% ` Slava Ovsiienko
2019-11-05 15:12 0% ` Ferruh Yigit
2019-11-03 20:46 0% ` Ray Kinsella
1 sibling, 1 reply; 200+ results
From: Slava Ovsiienko @ 2019-11-03 7:50 UTC (permalink / raw)
To: Damjan Marion (damarion)
Cc: Liu, Yu Y, Wang, Haiyue, Thomas Monjalon, dev, arybchenko, Yigit,
Ferruh, jerinjacobk, Ye, Xiaolong, Ray Kinsella, Sun, Chenmin
> -----Original Message-----
> From: Damjan Marion (damarion) <damarion@cisco.com>
> Sent: Saturday, November 2, 2019 21:21
> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> Cc: Liu, Yu Y <yu.y.liu@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> Thomas Monjalon <thomas@monjalon.net>; dev@dpdk.org;
> arybchenko@solarflare.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> jerinjacobk@gmail.com; Ye, Xiaolong <xiaolong.ye@intel.com>; Ray Kinsella
> <ray.kinsella@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>
> Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
> information
>
>
>
> > On 2 Nov 2019, at 09:38, Slava Ovsiienko <viacheslavo@mellanox.com>
> wrote:
> >
> > Hi
> >> -----Original Message-----
> >> From: Liu, Yu Y <yu.y.liu@intel.com>
> >> Sent: Saturday, November 2, 2019 8:56
> >> To: Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
> >> <thomas@monjalon.net>
> >> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> >> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> >> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> >> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> >> <viacheslavo@mellanox.com>; Damjan Marion (damarion)
> >> <damarion@cisco.com>; Liu, Yu Y <yu.y.liu@intel.com>
> >> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> >> mode information
> >>
> >> Add Damjan from FD.io for awareness...
> >>
> >> Hi Thomas,
> >>
> >> Long time no see. Sorry I use outlook which is not friendly to
> >> community email.
> >>
> >>> Anyway I will propose to replace this API in the next release.
> >> Will your plan be affected by API/ABI stable plan?
> >> BTW, if you propose new change in next release, it will make DPDK
> >> consumer(FD.io) to change again.
> >> So even if it is not affected to the API/ABI stable plan, do we still
> >> have time to get a solution for everyone in DPDK 19.11 with your
> >> contribution/acceleration?
> >>
> >>> I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> >> Please be rest assured it is not the case.
> >> This request is just from one FD.io project internal bug " tx/rx
> >> burst function is shown as nil" reported by Chenmin.
> >
> > Why just the presenting string with function name (possible with suffix) is
> not enough?
> > I would like to see this API (strings approach) in mlx5 either,
> > dropping the entire feature does not look nice, as for me.
> >
> > We could consider some requirements for the name suffices to
> > distinguish whether function uses vector instructions and which ones if any.
> >
> >> My understanding is DPDK behavior was taken as bug for someone in
> >> FD.io project and potentially will mislead other DPDK consumer.
> >
> > Why does FD.io code want to know which vector extension is used by burst
> routines?
> > Is it going to share/preserve some resources (registers, etc.)? Is it robust ?
> > Burst routines might not know whether vector extensions is used (they
> > might call libraries, even rte_memcpy() can use vectors in implicit fashion).
>
> This is jut debug CLI print, it was added by me as a result of frustration of
> dealing constantly with operational issues where people are reporting lower
> performance caused by DPDK deciding for variety of reasons to switch from
> vector PMD to scalar one.
And it seems there is no need for flags, as for me.
I think the simple string would be quite enough to identify the datapath routine.
Also, we have exact the same issue with mlx5 PMD, so the API (in simple
string version) is desirable (+1 from me).
With best regards, Slava
> >
> >> Haiyue is working with Chenmin to address the issue and with your
> >> support it will be even better.
> >>
> >> Your support will be highly appreciated!
> >>
> >> Thanks & Regards,
> >> Yu Liu
> >>
> >> -----Original Message-----
> >> From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
> >> Sent: Saturday, November 2, 2019 1:30 PM
> >> To: Thomas Monjalon <thomas@monjalon.net>
> >> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> >> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> >> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> >> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> >> <viacheslavo@mellanox.com>
> >> Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for
> >> getting burst mode information
> >>
> >>> -----Original Message-----
> >>> From: Thomas Monjalon <thomas@monjalon.net>
> >>> Sent: Saturday, November 2, 2019 06:46
> >>> To: Wang, Haiyue <haiyue.wang@intel.com>
> >>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> >>> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> >>> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> >>> Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> >>> <viacheslavo@mellanox.com>
> >>> Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting
> >>> burst mode information
> >>>
> >>> Thank you for trying to address comments done late.
> >>>
> >>> 31/10/2019 18:11, Haiyue Wang:
> >>>> --- a/lib/librte_ethdev/rte_ethdev.h
> >>>> +++ b/lib/librte_ethdev/rte_ethdev.h
> >>
> >>
> >>>> +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2)
> >>>> +#define RTE_ETH_BURST_NEON (1ULL << 3)
> >>>> +#define RTE_ETH_BURST_SSE (1ULL << 4)
> >>>> +#define RTE_ETH_BURST_AVX2 (1ULL << 5)
> >>>> +#define RTE_ETH_BURST_AVX512 (1ULL << 6)
> >>>
> >>> Of course, I still believe that giving a special treatment to vector
> >>> instructions is wrong.
> >>> You did not justify why it needs to be defined in bits instead of
> >>> string. I am not asking again because anyway you don't really reply.
> >>> I think you are executing an order you received and I don't want to
> >>> blame you more.
> >>> I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> >>> No need to reply to this comment.
> >>> Anyway I will propose to replace this API in the next release.
> >>
> >> Never mind, if this design is truly ugly, drop it all now. I also
> >> prefer to do the best, that's why open source is amazing, thanks! ;-)
> >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
2019-11-03 2:34 0% ` Wang, Haiyue
@ 2019-11-03 3:03 0% ` Wang, Haiyue
2019-11-03 8:59 0% ` Slava Ovsiienko
1 sibling, 0 replies; 200+ results
From: Wang, Haiyue @ 2019-11-03 3:03 UTC (permalink / raw)
To: 'Slava Ovsiienko', Liu, Yu Y, 'Thomas Monjalon'
Cc: 'dev@dpdk.org', 'arybchenko@solarflare.com',
Yigit, Ferruh, 'jerinjacobk@gmail.com',
Ye, Xiaolong, Kinsella, Ray, Sun, Chenmin,
'Damjan Marion (damarion)'
> -----Original Message-----
> From: Wang, Haiyue
> Sent: Sunday, November 3, 2019 10:34
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Liu, Yu Y <yu.y.liu@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> jerinjacobk@gmail.com; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Sun, Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion) <damarion@cisco.com>
> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
>
> Hi Thomas, Slava,
>
> Please see the inline reply in one place.
>
> > -----Original Message-----
> > From: Slava Ovsiienko <viacheslavo@mellanox.com>
> > Sent: Saturday, November 2, 2019 16:39
> > To: Liu, Yu Y <yu.y.liu@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
> > <thomas@monjalon.net>
> > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> > jerinjacobk@gmail.com; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > Sun, Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion) <damarion@cisco.com>
> > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
> >
> > Hi
> > > -----Original Message-----
> > > From: Liu, Yu Y <yu.y.liu@intel.com>
> > > Sent: Saturday, November 2, 2019 8:56
> > > To: Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
> > > <thomas@monjalon.net>
> > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > > Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > <viacheslavo@mellanox.com>; Damjan Marion (damarion)
> > > <damarion@cisco.com>; Liu, Yu Y <yu.y.liu@intel.com>
> > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
> > > information
> > >
> > > Add Damjan from FD.io for awareness...
> > >
> > > Hi Thomas,
> > >
> > > Long time no see. Sorry I use outlook which is not friendly to community
> > > email.
> > >
> > > >Anyway I will propose to replace this API in the next release.
> > > Will your plan be affected by API/ABI stable plan?
> > > BTW, if you propose new change in next release, it will make DPDK
> > > consumer(FD.io) to change again.
> > > So even if it is not affected to the API/ABI stable plan, do we still have time
> > > to get a solution for everyone in DPDK 19.11 with your
> > > contribution/acceleration?
> > >
> > > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > > Please be rest assured it is not the case.
> > > This request is just from one FD.io project internal bug " tx/rx burst function
> > > is shown as nil" reported by Chenmin.
> >
> > Why just the presenting string with function name (possible with suffix) is not enough?
> > I would like to see this API (strings approach) in mlx5 either, dropping the entire feature
> > does not look nice, as for me.
> >
> > We could consider some requirements for the name suffices to distinguish whether
> > function uses vector instructions and which ones if any.
> >
> > > My understanding is DPDK behavior was taken as bug for someone in FD.io
> > > project and potentially will mislead other DPDK consumer.
> >
> > Why does FD.io code want to know which vector extension is used by burst routines?
> > Is it going to share/preserve some resources (registers, etc.)? Is it robust ?
> > Burst routines might not know whether vector extensions is used (they might call
> > libraries, even rte_memcpy() can use vectors in implicit fashion).
> >
>
> 1.
>
> The original issue description is:
> "VPP uses dladdr() to translate a function address to name, however, some tx/rx functions
> in DPDK are invisible for dladdr(), which is because they are defined as static."
>
> 2.
>
> So the RFC design is: one function, one description, like:
> https://patchwork.dpdk.org/patch/57644/
>
> +#ifdef RTE_ARCH_X86
> + else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec_avx2)
> + len = snprintf(buf, sz, "AVX2 Vector Scattered Rx");
> + else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec)
> + len = snprintf(buf, sz, "Vector Scattered Rx");
> + else if (dev->rx_pkt_burst == ice_recv_pkts_vec_avx2)
> + len = snprintf(buf, sz, "AVX2 Vector Rx");
> + else if (dev->rx_pkt_burst == ice_recv_pkts_vec)
> + len = snprintf(buf, sz, "Vector Rx");
> +#endif
>
> 3. Since the main issue is as Damjan replied in another thread:
> "people are reporting lower performance caused by DPDK deciding for variety
> of reasons to switch from vector PMD to scalar one."
>
> And Ferruh replied also:
> "As I understand this is to let applications to give informed decision based
> on what vectorization is used in the driver, currently this is not known by
> the application.
>
> And as previously replied, the main target of the API is to define the vector
> path, not all optimizations, so the number is limited."
>
> So we enhanced it with bit, example detail is (Yes, we defined a lit more,
> so we removed it in this patch):
> https://patchwork.dpdk.org/patch/61196/
>
> 4. And thanks Jerin's suggestion, I think his word can be more accurate: "This would
> help to reuse some of the flags to name conversion logic across all PMDs" for the
> reason we try to use bit to reduce some string format effort, it will be handled
> by the API internally "burst_mode_options_append(struct rte_eth_burst_mode *mode)".
> Now the new API will return the string finally:
>
> #define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 1024
> struct rte_eth_burst_mode {
> uint64_t options;
>
> /**< Each PMD can fill specific burst mode information into this, and
> * ethdev APIs will append the 'options' string format at its end.
> */
> char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
> };
>
> So MLX PMD can add 'full_empw', 'mtsc_empw' etc into 'alternate_options' firstly, assign
> 'RTE_ETH_BURST_VECTOR | RTE_ETH_BURST_SSE' to 'options' as needed, then finally,
> 'alternate_options' will be "full_empw, Vector SSE".
>
> Intel PMD can just assign "options", then finally, 'alternate_options' will be "Vector SSE".
>
> How about the design idea ? Again, this 'options' is not to do standardization, just
> want to reduce the duplicated name string things.
>
Also, one more thing about 'RTE_ETH_BURST_PER_QUEUE', I added new comment to make it
be more understandable, how about this ?
/**< If the Rx/Tx queues have different burst mode description, then PMD return
* this bit, so the application can enumerate all queues burst mode description
* as needed.
*/
#define RTE_ETH_BURST_PER_QUEUE (1ULL << 63)
so that, application can know more about PMD's burst information:
rte_eth_rx_burst_mode_get(port_id, 0, &mode); /* Use queue Id #0 to get burst mode firstly*/
if (mode.options & RTE_ETH_BURST_PER_QUEUE)
loop other queues.
> > With best regards, Slava
> >
> > > Haiyue is working with Chenmin to address the issue and with your support it
> > > will be even better.
> > >
> > > Your support will be highly appreciated!
> > >
> > > Thanks & Regards,
> > > Yu Liu
> > >
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
> > > Sent: Saturday, November 2, 2019 1:30 PM
> > > To: Thomas Monjalon <thomas@monjalon.net>
> > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > > Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > <viacheslavo@mellanox.com>
> > > Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting
> > > burst mode information
> > >
> > > > -----Original Message-----
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > Sent: Saturday, November 2, 2019 06:46
> > > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > > > Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > > <viacheslavo@mellanox.com>
> > > > Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> > > > mode information
> > > >
> > > > Thank you for trying to address comments done late.
> > > >
> > > > 31/10/2019 18:11, Haiyue Wang:
> > > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > >
> > >
> > > > > +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2)
> > > > > +#define RTE_ETH_BURST_NEON (1ULL << 3)
> > > > > +#define RTE_ETH_BURST_SSE (1ULL << 4)
> > > > > +#define RTE_ETH_BURST_AVX2 (1ULL << 5)
> > > > > +#define RTE_ETH_BURST_AVX512 (1ULL << 6)
> > > >
> > > > Of course, I still believe that giving a special treatment to vector
> > > > instructions is wrong.
> > > > You did not justify why it needs to be defined in bits instead of
> > > > string. I am not asking again because anyway you don't really reply. I
> > > > think you are executing an order you received and I don't want to
> > > > blame you more.
> > > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > > > No need to reply to this comment.
> > > > Anyway I will propose to replace this API in the next release.
> > >
> > > Never mind, if this design is truly ugly, drop it all now. I also prefer to do the
> > > best, that's why open source is amazing, thanks! ;-)
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
2019-11-02 8:38 0% ` Slava Ovsiienko
2019-11-02 19:21 0% ` Damjan Marion (damarion)
@ 2019-11-03 2:34 0% ` Wang, Haiyue
2019-11-03 3:03 0% ` Wang, Haiyue
2019-11-03 8:59 0% ` Slava Ovsiienko
1 sibling, 2 replies; 200+ results
From: Wang, Haiyue @ 2019-11-03 2:34 UTC (permalink / raw)
To: Slava Ovsiienko, Liu, Yu Y, Thomas Monjalon
Cc: dev, arybchenko, Yigit, Ferruh, jerinjacobk, Ye, Xiaolong,
Kinsella, Ray, Sun, Chenmin, Damjan Marion (damarion)
Hi Thomas, Slava,
Please see the inline reply in one place.
> -----Original Message-----
> From: Slava Ovsiienko <viacheslavo@mellanox.com>
> Sent: Saturday, November 2, 2019 16:39
> To: Liu, Yu Y <yu.y.liu@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> jerinjacobk@gmail.com; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Sun, Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion) <damarion@cisco.com>
> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
>
> Hi
> > -----Original Message-----
> > From: Liu, Yu Y <yu.y.liu@intel.com>
> > Sent: Saturday, November 2, 2019 8:56
> > To: Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
> > <thomas@monjalon.net>
> > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > <viacheslavo@mellanox.com>; Damjan Marion (damarion)
> > <damarion@cisco.com>; Liu, Yu Y <yu.y.liu@intel.com>
> > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
> > information
> >
> > Add Damjan from FD.io for awareness...
> >
> > Hi Thomas,
> >
> > Long time no see. Sorry I use outlook which is not friendly to community
> > email.
> >
> > >Anyway I will propose to replace this API in the next release.
> > Will your plan be affected by API/ABI stable plan?
> > BTW, if you propose new change in next release, it will make DPDK
> > consumer(FD.io) to change again.
> > So even if it is not affected to the API/ABI stable plan, do we still have time
> > to get a solution for everyone in DPDK 19.11 with your
> > contribution/acceleration?
> >
> > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > Please be rest assured it is not the case.
> > This request is just from one FD.io project internal bug " tx/rx burst function
> > is shown as nil" reported by Chenmin.
>
> Why just the presenting string with function name (possible with suffix) is not enough?
> I would like to see this API (strings approach) in mlx5 either, dropping the entire feature
> does not look nice, as for me.
>
> We could consider some requirements for the name suffices to distinguish whether
> function uses vector instructions and which ones if any.
>
> > My understanding is DPDK behavior was taken as bug for someone in FD.io
> > project and potentially will mislead other DPDK consumer.
>
> Why does FD.io code want to know which vector extension is used by burst routines?
> Is it going to share/preserve some resources (registers, etc.)? Is it robust ?
> Burst routines might not know whether vector extensions is used (they might call
> libraries, even rte_memcpy() can use vectors in implicit fashion).
>
1.
The original issue description is:
"VPP uses dladdr() to translate a function address to name, however, some tx/rx functions
in DPDK are invisible for dladdr(), which is because they are defined as static."
2.
So the RFC design is: one function, one description, like:
https://patchwork.dpdk.org/patch/57644/
+#ifdef RTE_ARCH_X86
+ else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec_avx2)
+ len = snprintf(buf, sz, "AVX2 Vector Scattered Rx");
+ else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec)
+ len = snprintf(buf, sz, "Vector Scattered Rx");
+ else if (dev->rx_pkt_burst == ice_recv_pkts_vec_avx2)
+ len = snprintf(buf, sz, "AVX2 Vector Rx");
+ else if (dev->rx_pkt_burst == ice_recv_pkts_vec)
+ len = snprintf(buf, sz, "Vector Rx");
+#endif
3. Since the main issue is as Damjan replied in another thread:
"people are reporting lower performance caused by DPDK deciding for variety
of reasons to switch from vector PMD to scalar one."
And Ferruh replied also:
"As I understand this is to let applications to give informed decision based
on what vectorization is used in the driver, currently this is not known by
the application.
And as previously replied, the main target of the API is to define the vector
path, not all optimizations, so the number is limited."
So we enhanced it with bit, example detail is (Yes, we defined a lit more,
so we removed it in this patch):
https://patchwork.dpdk.org/patch/61196/
4. And thanks Jerin's suggestion, I think his word can be more accurate: "This would
help to reuse some of the flags to name conversion logic across all PMDs" for the
reason we try to use bit to reduce some string format effort, it will be handled
by the API internally "burst_mode_options_append(struct rte_eth_burst_mode *mode)".
Now the new API will return the string finally:
#define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 1024
struct rte_eth_burst_mode {
uint64_t options;
/**< Each PMD can fill specific burst mode information into this, and
* ethdev APIs will append the 'options' string format at its end.
*/
char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
};
So MLX PMD can add 'full_empw', 'mtsc_empw' etc into 'alternate_options' firstly, assign
'RTE_ETH_BURST_VECTOR | RTE_ETH_BURST_SSE' to 'options' as needed, then finally,
'alternate_options' will be "full_empw, Vector SSE".
Intel PMD can just assign "options", then finally, 'alternate_options' will be "Vector SSE".
How about the design idea ? Again, this 'options' is not to do standardization, just
want to reduce the duplicated name string things.
> With best regards, Slava
>
> > Haiyue is working with Chenmin to address the issue and with your support it
> > will be even better.
> >
> > Your support will be highly appreciated!
> >
> > Thanks & Regards,
> > Yu Liu
> >
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
> > Sent: Saturday, November 2, 2019 1:30 PM
> > To: Thomas Monjalon <thomas@monjalon.net>
> > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > <viacheslavo@mellanox.com>
> > Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting
> > burst mode information
> >
> > > -----Original Message-----
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > Sent: Saturday, November 2, 2019 06:46
> > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > > Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > <viacheslavo@mellanox.com>
> > > Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> > > mode information
> > >
> > > Thank you for trying to address comments done late.
> > >
> > > 31/10/2019 18:11, Haiyue Wang:
> > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> >
> >
> > > > +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2)
> > > > +#define RTE_ETH_BURST_NEON (1ULL << 3)
> > > > +#define RTE_ETH_BURST_SSE (1ULL << 4)
> > > > +#define RTE_ETH_BURST_AVX2 (1ULL << 5)
> > > > +#define RTE_ETH_BURST_AVX512 (1ULL << 6)
> > >
> > > Of course, I still believe that giving a special treatment to vector
> > > instructions is wrong.
> > > You did not justify why it needs to be defined in bits instead of
> > > string. I am not asking again because anyway you don't really reply. I
> > > think you are executing an order you received and I don't want to
> > > blame you more.
> > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > > No need to reply to this comment.
> > > Anyway I will propose to replace this API in the next release.
> >
> > Never mind, if this design is truly ugly, drop it all now. I also prefer to do the
> > best, that's why open source is amazing, thanks! ;-)
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
2019-11-02 8:38 0% ` Slava Ovsiienko
@ 2019-11-02 19:21 0% ` Damjan Marion (damarion)
2019-11-03 7:50 0% ` Slava Ovsiienko
2019-11-03 20:46 0% ` Ray Kinsella
2019-11-03 2:34 0% ` Wang, Haiyue
1 sibling, 2 replies; 200+ results
From: Damjan Marion (damarion) @ 2019-11-02 19:21 UTC (permalink / raw)
To: Slava Ovsiienko
Cc: Liu, Yu Y, Wang, Haiyue, Thomas Monjalon, dev, arybchenko, Yigit,
Ferruh, jerinjacobk, Ye, Xiaolong, Ray Kinsella, Sun, Chenmin
> On 2 Nov 2019, at 09:38, Slava Ovsiienko <viacheslavo@mellanox.com> wrote:
>
> Hi
>> -----Original Message-----
>> From: Liu, Yu Y <yu.y.liu@intel.com>
>> Sent: Saturday, November 2, 2019 8:56
>> To: Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
>> <thomas@monjalon.net>
>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
>> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
>> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
>> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
>> <viacheslavo@mellanox.com>; Damjan Marion (damarion)
>> <damarion@cisco.com>; Liu, Yu Y <yu.y.liu@intel.com>
>> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
>> information
>>
>> Add Damjan from FD.io for awareness...
>>
>> Hi Thomas,
>>
>> Long time no see. Sorry I use outlook which is not friendly to community
>> email.
>>
>>> Anyway I will propose to replace this API in the next release.
>> Will your plan be affected by API/ABI stable plan?
>> BTW, if you propose new change in next release, it will make DPDK
>> consumer(FD.io) to change again.
>> So even if it is not affected to the API/ABI stable plan, do we still have time
>> to get a solution for everyone in DPDK 19.11 with your
>> contribution/acceleration?
>>
>>> I suspect a real hidden issue in Intel CPUs that you try to mitigate.
>> Please be rest assured it is not the case.
>> This request is just from one FD.io project internal bug " tx/rx burst function
>> is shown as nil" reported by Chenmin.
>
> Why just the presenting string with function name (possible with suffix) is not enough?
> I would like to see this API (strings approach) in mlx5 either, dropping the entire feature
> does not look nice, as for me.
>
> We could consider some requirements for the name suffices to distinguish whether
> function uses vector instructions and which ones if any.
>
>> My understanding is DPDK behavior was taken as bug for someone in FD.io
>> project and potentially will mislead other DPDK consumer.
>
> Why does FD.io code want to know which vector extension is used by burst routines?
> Is it going to share/preserve some resources (registers, etc.)? Is it robust ?
> Burst routines might not know whether vector extensions is used (they might call
> libraries, even rte_memcpy() can use vectors in implicit fashion).
This is jut debug CLI print, it was added by me as a result of frustration of dealing constantly with
operational issues where people are reporting lower performance caused by DPDK deciding
for variety of reasons to switch from vector PMD to scalar one.
>
>> Haiyue is working with Chenmin to address the issue and with your support it
>> will be even better.
>>
>> Your support will be highly appreciated!
>>
>> Thanks & Regards,
>> Yu Liu
>>
>> -----Original Message-----
>> From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
>> Sent: Saturday, November 2, 2019 1:30 PM
>> To: Thomas Monjalon <thomas@monjalon.net>
>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
>> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
>> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
>> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
>> <viacheslavo@mellanox.com>
>> Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting
>> burst mode information
>>
>>> -----Original Message-----
>>> From: Thomas Monjalon <thomas@monjalon.net>
>>> Sent: Saturday, November 2, 2019 06:46
>>> To: Wang, Haiyue <haiyue.wang@intel.com>
>>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
>>> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
>>> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
>>> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
>>> <viacheslavo@mellanox.com>
>>> Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst
>>> mode information
>>>
>>> Thank you for trying to address comments done late.
>>>
>>> 31/10/2019 18:11, Haiyue Wang:
>>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>
>>
>>>> +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2)
>>>> +#define RTE_ETH_BURST_NEON (1ULL << 3)
>>>> +#define RTE_ETH_BURST_SSE (1ULL << 4)
>>>> +#define RTE_ETH_BURST_AVX2 (1ULL << 5)
>>>> +#define RTE_ETH_BURST_AVX512 (1ULL << 6)
>>>
>>> Of course, I still believe that giving a special treatment to vector
>>> instructions is wrong.
>>> You did not justify why it needs to be defined in bits instead of
>>> string. I am not asking again because anyway you don't really reply. I
>>> think you are executing an order you received and I don't want to
>>> blame you more.
>>> I suspect a real hidden issue in Intel CPUs that you try to mitigate.
>>> No need to reply to this comment.
>>> Anyway I will propose to replace this API in the next release.
>>
>> Never mind, if this design is truly ugly, drop it all now. I also prefer to do the
>> best, that's why open source is amazing, thanks! ;-)
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
2019-11-02 6:55 4% ` Liu, Yu Y
2019-11-02 8:38 0% ` Slava Ovsiienko
@ 2019-11-02 18:31 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-11-02 18:31 UTC (permalink / raw)
To: Liu, Yu Y
Cc: Wang, Haiyue, dev, arybchenko, Yigit, Ferruh, jerinjacobk, Ye,
Xiaolong, Kinsella, Ray, Sun, Chenmin, Slava Ovsiienko,
Damjan Marion (damarion)
02/11/2019 07:55, Liu, Yu Y:
> Add Damjan from FD.io for awareness...
>
> Hi Thomas,
>
> Long time no see. Sorry I use outlook which is not friendly to community email.
>
> >Anyway I will propose to replace this API in the next release.
> Will your plan be affected by API/ABI stable plan?
The API is experimental, so it can be changed later.
> BTW, if you propose new change in next release, it will make DPDK consumer(FD.io) to change again.
Yes I agree it is not nice.
> So even if it is not affected to the API/ABI stable plan, do we still have time to get a solution for everyone in DPDK 19.11 with your contribution/acceleration?
Yes we have time.
But you insist on an API without any good justification.
> > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> Please be rest assured it is not the case.
> This request is just from one FD.io project internal bug " tx/rx burst function is shown as nil" reported by Chenmin.
> My understanding is DPDK behavior was taken as bug for someone in FD.io project and potentially will mislead other DPDK consumer.
> Haiyue is working with Chenmin to address the issue and with your support it will be even better.
>
> Your support will be highly appreciated!
I already said what I consider to be good: a simple string.
Of course I may be wrong, that's why I asked questions.
But half of the questions are just ignored.
If you want to progress, please reply to the questions asked by Slava in this thread.
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
> > From: Thomas Monjalon <thomas@monjalon.net>
> >
> > Thank you for trying to address comments done late.
> >
> > 31/10/2019 18:11, Haiyue Wang:
> > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > +++ b/lib/librte_ethdev/rte_ethdev.h
>
>
> > > +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2)
> > > +#define RTE_ETH_BURST_NEON (1ULL << 3)
> > > +#define RTE_ETH_BURST_SSE (1ULL << 4)
> > > +#define RTE_ETH_BURST_AVX2 (1ULL << 5)
> > > +#define RTE_ETH_BURST_AVX512 (1ULL << 6)
> >
> > Of course, I still believe that giving a special treatment to vector
> > instructions is wrong.
> > You did not justify why it needs to be defined in bits instead of
> > string. I am not asking again because anyway you don't really reply. I
> > think you are executing an order you received and I don't want to
> > blame you more.
> > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > No need to reply to this comment.
> > Anyway I will propose to replace this API in the next release.
>
> Never mind, if this design is truly ugly, drop it all now. I also prefer to do the best, that's why open source is amazing, thanks! ;-)
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
2019-11-02 6:55 4% ` Liu, Yu Y
@ 2019-11-02 8:38 0% ` Slava Ovsiienko
2019-11-02 19:21 0% ` Damjan Marion (damarion)
2019-11-03 2:34 0% ` Wang, Haiyue
2019-11-02 18:31 0% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Slava Ovsiienko @ 2019-11-02 8:38 UTC (permalink / raw)
To: Liu, Yu Y, Wang, Haiyue, Thomas Monjalon
Cc: dev, arybchenko, Yigit, Ferruh, jerinjacobk, Ye, Xiaolong,
Kinsella, Ray, Sun, Chenmin, Damjan Marion (damarion)
Hi
> -----Original Message-----
> From: Liu, Yu Y <yu.y.liu@intel.com>
> Sent: Saturday, November 2, 2019 8:56
> To: Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> <viacheslavo@mellanox.com>; Damjan Marion (damarion)
> <damarion@cisco.com>; Liu, Yu Y <yu.y.liu@intel.com>
> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
> information
>
> Add Damjan from FD.io for awareness...
>
> Hi Thomas,
>
> Long time no see. Sorry I use outlook which is not friendly to community
> email.
>
> >Anyway I will propose to replace this API in the next release.
> Will your plan be affected by API/ABI stable plan?
> BTW, if you propose new change in next release, it will make DPDK
> consumer(FD.io) to change again.
> So even if it is not affected to the API/ABI stable plan, do we still have time
> to get a solution for everyone in DPDK 19.11 with your
> contribution/acceleration?
>
> > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> Please be rest assured it is not the case.
> This request is just from one FD.io project internal bug " tx/rx burst function
> is shown as nil" reported by Chenmin.
Why just the presenting string with function name (possible with suffix) is not enough?
I would like to see this API (strings approach) in mlx5 either, dropping the entire feature
does not look nice, as for me.
We could consider some requirements for the name suffices to distinguish whether
function uses vector instructions and which ones if any.
> My understanding is DPDK behavior was taken as bug for someone in FD.io
> project and potentially will mislead other DPDK consumer.
Why does FD.io code want to know which vector extension is used by burst routines?
Is it going to share/preserve some resources (registers, etc.)? Is it robust ?
Burst routines might not know whether vector extensions is used (they might call
libraries, even rte_memcpy() can use vectors in implicit fashion).
With best regards, Slava
> Haiyue is working with Chenmin to address the issue and with your support it
> will be even better.
>
> Your support will be highly appreciated!
>
> Thanks & Regards,
> Yu Liu
>
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
> Sent: Saturday, November 2, 2019 1:30 PM
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> <viacheslavo@mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting
> burst mode information
>
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Saturday, November 2, 2019 06:46
> > To: Wang, Haiyue <haiyue.wang@intel.com>
> > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > <viacheslavo@mellanox.com>
> > Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> > mode information
> >
> > Thank you for trying to address comments done late.
> >
> > 31/10/2019 18:11, Haiyue Wang:
> > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > +++ b/lib/librte_ethdev/rte_ethdev.h
>
>
> > > +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2)
> > > +#define RTE_ETH_BURST_NEON (1ULL << 3)
> > > +#define RTE_ETH_BURST_SSE (1ULL << 4)
> > > +#define RTE_ETH_BURST_AVX2 (1ULL << 5)
> > > +#define RTE_ETH_BURST_AVX512 (1ULL << 6)
> >
> > Of course, I still believe that giving a special treatment to vector
> > instructions is wrong.
> > You did not justify why it needs to be defined in bits instead of
> > string. I am not asking again because anyway you don't really reply. I
> > think you are executing an order you received and I don't want to
> > blame you more.
> > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > No need to reply to this comment.
> > Anyway I will propose to replace this API in the next release.
>
> Never mind, if this design is truly ugly, drop it all now. I also prefer to do the
> best, that's why open source is amazing, thanks! ;-)
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
@ 2019-11-02 6:55 4% ` Liu, Yu Y
2019-11-02 8:38 0% ` Slava Ovsiienko
2019-11-02 18:31 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Liu, Yu Y @ 2019-11-02 6:55 UTC (permalink / raw)
To: Wang, Haiyue, Thomas Monjalon
Cc: dev, arybchenko, Yigit, Ferruh, jerinjacobk, Ye, Xiaolong,
Kinsella, Ray, Sun, Chenmin, Slava Ovsiienko,
Damjan Marion (damarion),
Liu, Yu Y
Add Damjan from FD.io for awareness...
Hi Thomas,
Long time no see. Sorry I use outlook which is not friendly to community email.
>Anyway I will propose to replace this API in the next release.
Will your plan be affected by API/ABI stable plan?
BTW, if you propose new change in next release, it will make DPDK consumer(FD.io) to change again.
So even if it is not affected to the API/ABI stable plan, do we still have time to get a solution for everyone in DPDK 19.11 with your contribution/acceleration?
> I suspect a real hidden issue in Intel CPUs that you try to mitigate.
Please be rest assured it is not the case.
This request is just from one FD.io project internal bug " tx/rx burst function is shown as nil" reported by Chenmin.
My understanding is DPDK behavior was taken as bug for someone in FD.io project and potentially will mislead other DPDK consumer.
Haiyue is working with Chenmin to address the issue and with your support it will be even better.
Your support will be highly appreciated!
Thanks & Regards,
Yu Liu
-----Original Message-----
From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
Sent: Saturday, November 2, 2019 1:30 PM
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko <viacheslavo@mellanox.com>
Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Saturday, November 2, 2019 06:46
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> <viacheslavo@mellanox.com>
> Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> mode information
>
> Thank you for trying to address comments done late.
>
> 31/10/2019 18:11, Haiyue Wang:
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2)
> > +#define RTE_ETH_BURST_NEON (1ULL << 3)
> > +#define RTE_ETH_BURST_SSE (1ULL << 4)
> > +#define RTE_ETH_BURST_AVX2 (1ULL << 5)
> > +#define RTE_ETH_BURST_AVX512 (1ULL << 6)
>
> Of course, I still believe that giving a special treatment to vector
> instructions is wrong.
> You did not justify why it needs to be defined in bits instead of
> string. I am not asking again because anyway you don't really reply. I
> think you are executing an order you received and I don't want to
> blame you more.
> I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> No need to reply to this comment.
> Anyway I will propose to replace this API in the next release.
Never mind, if this design is truly ugly, drop it all now. I also prefer to do the best, that's why open source is amazing, thanks! ;-)
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v6 00/12] lib: add RIB and FIB liraries
@ 2019-11-01 15:21 2% ` Vladimir Medvedkin
0 siblings, 0 replies; 200+ results
From: Vladimir Medvedkin @ 2019-11-01 15:21 UTC (permalink / raw)
To: dev; +Cc: bruce.richardson, konstantin.ananyev, thomas, aconole
This is heavily reworked version of previous RIB library series:
https://mails.dpdk.org/archives/dev/2018-April/099492.html
Current lpm implementation while provides really good lookup
performance has number of problems.
One of them is very low speed for control plane operations
such as add or delete a route.
Another disadvantage is fixed number of bits for userdata
(24 for v4 and 21 for v6)
Also it is hard to introduce changes in existing LPM code or add new
algorithms without breaking ABI.
This patch series tries to solve this problems by:
Introduce two new libraries - RIB and FIB.
RIB that is Routing Information Base.
It implements a control plane struct containing routes in a tree and
provides fast add/del operations for routes. Also it allows to perform
fast subtree traversals (i.e. retrieve existing subroutes for a given
prefix). This structure will be used as a control plane helper structure
for FIB implementation.
Also it might be used standalone in other different places such as
bitmaps for example.
Second library is FIB that is Forwarding Information Base. It represents
dataplane related struct and algorithms for longest prefix match.
Internally it consists of two parts - RIB (control plane ops) and
implementation for the dataplane tasks.
Initial version provides two implementations for both ipv4 and ipv6:
dummy (uses RIB as a dataplane) and DIR24_8 (same as current LPM)
Due to proposed design it allows to extend FIB with new algorithms in future
(for example DXR, poptrie, etc).
From our measurements we saw 10x speedup for control plane operations
comparing with current LPM library (depending on prefix length distribution)
ToDo:
- introduce new performance measurement app.
- add documentation.
- add support into existing examples (l3fwd)
v6:
Move long-running tests into a pref test section
Vladimir Medvedkin (12):
rib: add RIB library
test/rib: add RIB library autotests
rib: add ipv6 support for RIB
test/rib: add ipv6 support for RIB autotests
fib: add FIB library
fib: add FIB ipv6 support
fib: add DIR24-8 dataplane algorithm
fib: add dataplane algorithm for ipv6
test/fib: add FIB library autotests
test/fib: add ipv6 support for FIB autotests
test/fib: add FIB library performance autotests
test/fib: add FIB library ipv6 performance autotests
app/test/Makefile | 7 +
app/test/autotest_data.py | 48 +++
app/test/meson.build | 16 +
app/test/test_fib.c | 414 ++++++++++++++++++++
app/test/test_fib6.c | 423 +++++++++++++++++++++
app/test/test_fib6_perf.c | 157 ++++++++
app/test/test_fib_perf.c | 411 ++++++++++++++++++++
app/test/test_rib.c | 351 +++++++++++++++++
app/test/test_rib6.c | 357 +++++++++++++++++
config/common_base | 11 +
doc/api/doxy-api.conf.in | 2 +
lib/Makefile | 4 +
lib/librte_fib/Makefile | 25 ++
lib/librte_fib/dir24_8.c | 737 +++++++++++++++++++++++++++++++++++
lib/librte_fib/dir24_8.h | 36 ++
lib/librte_fib/meson.build | 8 +
lib/librte_fib/rte_fib.c | 319 ++++++++++++++++
lib/librte_fib/rte_fib.h | 188 +++++++++
lib/librte_fib/rte_fib6.c | 322 ++++++++++++++++
lib/librte_fib/rte_fib6.h | 193 ++++++++++
lib/librte_fib/rte_fib_version.map | 23 ++
lib/librte_fib/trie.c | 760 +++++++++++++++++++++++++++++++++++++
lib/librte_fib/trie.h | 37 ++
lib/librte_rib/Makefile | 25 ++
lib/librte_rib/meson.build | 8 +
lib/librte_rib/rte_rib.c | 532 ++++++++++++++++++++++++++
lib/librte_rib/rte_rib.h | 277 ++++++++++++++
lib/librte_rib/rte_rib6.c | 598 +++++++++++++++++++++++++++++
lib/librte_rib/rte_rib6.h | 334 ++++++++++++++++
lib/librte_rib/rte_rib_version.map | 35 ++
lib/meson.build | 4 +-
mk/rte.app.mk | 2 +
32 files changed, 6663 insertions(+), 1 deletion(-)
create mode 100644 app/test/test_fib.c
create mode 100644 app/test/test_fib6.c
create mode 100644 app/test/test_fib6_perf.c
create mode 100644 app/test/test_fib_perf.c
create mode 100644 app/test/test_rib.c
create mode 100644 app/test/test_rib6.c
create mode 100644 lib/librte_fib/Makefile
create mode 100644 lib/librte_fib/dir24_8.c
create mode 100644 lib/librte_fib/dir24_8.h
create mode 100644 lib/librte_fib/meson.build
create mode 100644 lib/librte_fib/rte_fib.c
create mode 100644 lib/librte_fib/rte_fib.h
create mode 100644 lib/librte_fib/rte_fib6.c
create mode 100644 lib/librte_fib/rte_fib6.h
create mode 100644 lib/librte_fib/rte_fib_version.map
create mode 100644 lib/librte_fib/trie.c
create mode 100644 lib/librte_fib/trie.h
create mode 100644 lib/librte_rib/Makefile
create mode 100644 lib/librte_rib/meson.build
create mode 100644 lib/librte_rib/rte_rib.c
create mode 100644 lib/librte_rib/rte_rib.h
create mode 100644 lib/librte_rib/rte_rib6.c
create mode 100644 lib/librte_rib/rte_rib6.h
create mode 100644 lib/librte_rib/rte_rib_version.map
--
2.7.4
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [RFC PATCH 1/9] security: introduce CPU Crypto action type and API
2019-10-30 14:23 0% ` Ananyev, Konstantin
@ 2019-11-01 13:53 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2019-11-01 13:53 UTC (permalink / raw)
To: Ananyev, Konstantin, 'dev@dpdk.org',
De Lara Guarch, Pablo, 'Thomas Monjalon',
Zhang, Roy Fan, Doherty, Declan
Cc: 'Anoob Joseph', Hemant Agrawal
Hi Konstantin,
>
>
> Hi Akhil,
>
> > > > > > Added my comments inline with your draft.
> > > > > > [snip]..
> > > > > >
> > > > > > >
> > > > > > > Ok, then my suggestion:
> > > > > > > Let's at least write down all points about crypto-dev approach where
> we
> > > > > > > disagree and then probably try to resolve them one by one....
> > > > > > > If we fail to make an agreement/progress in next week or so,
> > > > > > > (and no more reviews from the community)
> > > > > > > will have bring that subject to TB meeting to decide.
> > > > > > > Sounds fair to you?
> > > > > > Agreed
> > > > > > >
> > > > > > > List is below.
> > > > > > > Please add/correct me, if I missed something.
> > > > > > >
> > > > > > > Konstantin
> > > > > >
> > > > > > Before going into comparison, we should define the requirement as
> well.
> > > > >
> > > > > Good point.
> > > > >
> > > > > > What I understood from the patchset,
> > > > > > "You need a synchronous API to perform crypto operations on raw data
> > > using
> > > > > SW PMDs"
> > > > > > So,
> > > > > > - no crypto-ops,
> > > > > > - no separate enq-deq, only single process API for data path
> > > > > > - Do not need any value addition to the session parameters.
> > > > > > (You would need some parameters from the crypto-op which
> > > > > > Are constant per session and since you wont use crypto-op,
> > > > > > You need some place to store that)
> > > > >
> > > > > Yes, this is correct, I think.
> > > > >
> > > > > >
> > > > > > Now as per your mail, the comparison
> > > > > > 1. extra input parameters to create/init rte_(cpu)_sym_session.
> > > > > >
> > > > > > Will leverage existing 6B gap inside rte_crypto_*_xform between 'algo'
> > > and
> > > > > 'key' fields.
> > > > > > New fields will be optional and would be used by PMD only when cpu-
> > > crypto
> > > > > session is requested.
> > > > > > For lksd-crypto session PMD is free to ignore these fields.
> > > > > > No ABI breakage is required.
> > > > > >
> > > > > > [Akhil] Agreed, no issues.
> > > > > >
> > > > > > 2. cpu-crypto create/init.
> > > > > > a) Our suggestion - introduce new API for that:
> > > > > > - rte_crypto_cpu_sym_init() that would init completely opaque
> > > > > rte_crypto_cpu_sym_session.
> > > > > > - struct rte_crypto_cpu_sym_session_ops {(*process)(...); (*clear);
> > > > > /*whatever else we'll need *'};
> > > > > > - rte_crypto_cpu_sym_get_ops(const struct rte_crypto_sym_xform
> > > > > *xforms)
> > > > > > that would return const struct rte_crypto_cpu_sym_session_ops
> > > *based
> > > > > on input xforms.
> > > > > > Advantages:
> > > > > > 1) totally opaque data structure (no ABI breakages in future),
> PMD
> > > > > writer is totally free
> > > > > > with it format and contents.
> > > > > >
> > > > > > [Akhil] It will have breakage at some point till we don't hit the union
> size.
> > > > >
> > > > > Not sure, what union you are talking about?
> > > >
> > > > Union of xforms in rte_security_session_conf
> > >
> > > Hmm, how does it relates here?
> > > I thought we discussing pure rte_cryptodev_sym_session, no?
> > >
> > > >
> > > > >
> > > > > > Rather I don't suspect there will be more parameters added.
> > > > > > Or do we really care about the ABI breakage when the argument is
> about
> > > > > > the correct place to add a piece of code or do we really agree to add
> code
> > > > > > anywhere just to avoid that breakage.
> > > > >
> > > > > I am talking about maintaining it in future.
> > > > > if your struct is not seen externally, no chances to introduce ABI
> breakage.
> > > > >
> > > > > >
> > > > > > 2) each session entity is self-contained, user doesn't need to
> bring along
> > > > > dev_id etc.
> > > > > > dev_id is needed only at init stage, after that user will use
> session ops
> > > > > to perform
> > > > > > all operations on that session (process(), clear(), etc.).
> > > > > >
> > > > > > [Akhil] There is nothing called as session ops in current DPDK.
> > > > >
> > > > > True, but it doesn't mean we can't/shouldn't have it.
> > > >
> > > > We can have it if it is not adding complexity for the user. Creating 2
> different
> > > code
> > > > Paths for user is not desirable for the stack developers.
> > > >
> > > > >
> > > > > > What you are proposing
> > > > > > is a new concept which doesn't have any extra benefit, rather it is
> adding
> > > > > complexity
> > > > > > to have two different code paths for session create.
> > > > > >
> > > > > >
> > > > > > 3) User can decide does he wants to store ops[] pointer on a per
> session
> > > > > basis,
> > > > > > or on a per group of same sessions, or...
> > > > > >
> > > > > > [Akhil] Will the user really care which process API should be called from
> the
> > > > > PMD.
> > > > > > Rather it should be driver's responsibility to store that in the session
> private
> > > > > data
> > > > > > which would be opaque to the user. As per my suggestion same process
> > > > > function can
> > > > > > be added to multiple sessions or a single session can be managed inside
> the
> > > > > PMD.
> > > > >
> > > > > In that case we either need to have a function per session (stored
> internally),
> > > > > or make decision (branches) at run-time.
> > > > > But as I said in other mail - I am ok to add small shim structure here:
> > > > > either rte_crypto_cpu_sym_session { void *ses; struct
> > > > > rte_crypto_cpu_sym_session_ops ops; }
> > > > > or rte_crypto_cpu_sym_session { void *ses; struct
> > > > > rte_crypto_cpu_sym_session_ops *ops; }
> > > > > And merge rte_crypto_cpu_sym_init() and rte_crypto_cpu_sym_get_ops()
> > > into
> > > > > one (init).
> > > >
> > > > Again that will be a separate API call from the user perspective which is not
> > > good.
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > 4) No mandatory mempools for private sessions. User can
> allocate
> > > > > memory for cpu-crypto
> > > > > > session whenever he likes.
> > > > > >
> > > > > > [Akhil] you mean session private data?
> > > > >
> > > > > Yes.
> > > > >
> > > > > > You would need that memory anyways, user will be
> > > > > > allocating that already. You do not need to manage that.
> > > > >
> > > > > What I am saying - right now user has no choice but to allocate it via
> > > mempool.
> > > > > Which is probably not the best options for all cases.
> > > > >
> > > > > >
> > > > > > Disadvantages:
> > > > > > 5) Extra changes in control path
> > > > > > 6) User has to store session_ops pointer explicitly.
> > > > > >
> > > > > > [Akhil] More disadvantages:
> > > > > > - All supporting PMDs will need to maintain TWO types of session for
> the
> > > > > > same crypto processing. Suppose a fix or a new feature(or algo) is
> added,
> > > PMD
> > > > > owner
> > > > > > will need to add code in both the session create APIs. Hence more
> > > > > maintenance and
> > > > > > error prone.
> > > > >
> > > > > I think majority of code for both paths will be common, plus even we'll
> reuse
> > > > > current sym_session_init() -
> > > > > changes in PMD session_init() code will be unavoidable.
> > > > > But yes, it will be new entry in devops, that PMD will have to support.
> > > > > Ok to add it as 7) to the list.
> > > > >
> > > > > > - Stacks which will be using these new APIs also need to maintain two
> > > > > > code path for the same processing while doing session initialization
> > > > > > for sync and async
> > > > >
> > > > > That's the same as #5 above, I think.
> > > > >
> > > > > >
> > > > > >
> > > > > > b) Your suggestion - reuse existing rte_cryptodev_sym_session_init()
> and
> > > > > existing rte_cryptodev_sym_session
> > > > > > structure.
> > > > > > Advantages:
> > > > > > 1) allows to reuse same struct and init/create/clear() functions.
> > > > > > Probably less changes in control path.
> > > > > > Disadvantages:
> > > > > > 2) rte_cryptodev_sym_session. sess_data[] is indexed by
> driver_id,
> > > > > which means that
> > > > > > we can't use the same rte_cryptodev_sym_session to hold
> private
> > > > > sessions pointers
> > > > > > for both sync and async mode for the same device.
> > > > > > So the only option we have - make PMD devops-
> > > > > >sym_session_configure()
> > > > > > always create a session that can work in both cpu and lksd
> modes.
> > > > > > For some implementations that would probably mean that
> under the
> > > > > hood PMD would create
> > > > > > 2 different session structs (sync/async) and then use one or
> another
> > > > > depending on from what API been called.
> > > > > > Seems doable, but ...:
> > > > > > - will contradict with statement from 1:
> > > > > > " New fields will be optional and would be used by PMD only
> when
> > > > > cpu-crypto session is requested."
> > > > > > Now it becomes mandatory for all apps to specify cpu-
> crypto
> > > > > related parameters too,
> > > > > > even if they don't plan to use that mode - i.e. behavior
> change,
> > > > > existing app change.
> > > > > > - might cause extra space overhead.
> > > > > >
> > > > > > [Akhil] It will not contradict with #1, you will only have few checks in
> the
> > > > > session init PMD
> > > > > > Which support this mode, find appropriate values and set the
> appropriate
> > > > > process() in it.
> > > > > > User should be able to call, legacy enq-deq as well as the new process()
> > > > > without any issue.
> > > > > > User would be at runtime will be able to change the datapath.
> > > > > > So this is not a disadvantage, it would be additional flexibility for the
> user.
> > > > >
> > > > > Ok, but that's what I am saying - if PMD would *always* have to create a
> > > > > session that can handle
> > > > > both modes (sync/async), then user would *always* have to provide
> > > parameters
> > > > > for both modes too.
> > > > > Otherwise if let say user didn't setup sync specific parameters at all, what
> > > PMD
> > > > > should do?
> > > > > - return with error?
> > > > > - init session that can be used with async path only?
> > > > > My current assumption is #1.
> > > > > If #2, then how user will be able to distinguish is that session valid for
> both
> > > > > modes, or only for one?
> > > >
> > > > I would say a 3rd option, do nothing if sync params are not set.
> > > > Probably have a debug print in the PMD(which support sync mode) to
> specify
> > > that
> > > > session is not configured properly for sync mode.
> > >
> > > So, just print warning and proceed with init session that can be used with
> async
> > > path only?
> > > Then it sounds the same as #2 above.
> > > Which actually means that sync mode parameters for sym_session_init()
> > > becomes optional.
> > > Then we need an API to provide to the user information what modes
> > > (sync+async/async only) is supported by that session for given dev_id.
> > > And user would have to query/retain this information at control-path,
> > > and store it somewhere in user-space together with session pointer and
> dev_ids
> > > to use later at data-path (same as we do now for session type).
> > > That definitely requires changes in control-path to start using it.
> > > Plus the fact that this value can differ for different dev_ids for the same
> session -
> > > doesn't make things easier here.
> >
> > API wont be required to specify that. Feature flag will be sufficient, not a big
> change
> > From the application perspective.
> >
> > Here is some pseudo code just to elaborate my understanding. This will need
> some
> >
> > From application,
> > If(dev_info->feature_flags & RTE_CRYPTODEV_FF_SYNC) {
> > /* set additional params in crypto xform */
> > }
> >
> > Now in the driver,
> > pmd_sym_session_configure(dev,xform,sess,mempool) {
> > ...
> > If(dev_info->feature_flags & RTE_CRYPTODEV_FF_SYNC
> > && xform->/*sync params are set*/) {
> > /*Assign process function pointer in sess->priv_data*/
> > } /* It may return error if FF_SYNC is set and params are not correct.
>
> Then all apps will always *have to* setup sync parameters in xform.
> What you suggest is *mandatory* sync mode: user always has to setup sync
> mode params if PMD does support it (no matter does he plan to use sync mode
> or not).
> Which means behavior change in existing apps.
We are adding new params in xform, and user may not fill those params and defaults
To 0 for all the params. Or we can pack a flag in xform when all sync params are set.
It can be dealt with when we do the code.
I don't say, user will always have to set the params when sync mode is supported.
It will be a warning from the PMD and user may ignore it if he doesn't want to use sync mode.
>
> > It would be upto the driver whether it support both SYNC and
> ASYNC.*/
> > }
> >
> > Now the new sync API
> >
> > pmd_process(...) {
> > If(dev_info->feature_flags & RTE_CRYPTODEV_FF_SYNC
> > && sess_priv->process != NULL)
> > sess_priv->process(...);
> > else
> > ASSERT("sync mode not configured properly or not supported");
> > }
> >
> > In the data path, there is no extra processing happening.
> > Even in case of your suggestion, you should have these type of error checks,
> > You cannot blindly trust on the application that the pointers are correct.
> >
> > >
> > > > Internally the PMD will not store the process() API in the session priv data
> > > > And while calling the first packet, devops->process will give an assert that
> > > session
> > > > Is not configured for sync mode. The session validation would be done in
> any
> > > case
> > > > your suggestion or mine. So no extra overhead at runtime.
> > >
> > > I believe that after session_init() user should get either an error or
> > > valid session handler that he can use at runtime.
> > > Pushing session validation to runtime doesn't seem like a good idea.
> > >
> > It may get a warning from the PMD, that FF_SYNC is set but params are not
> > Correct/available. See above.
>
> I think warning is not enough.
> There should be a clear way (API) for developer to realize is the created session
> can be used by sync API data-path or not.
Warning is a clear notification to the user, that SYNC mode can be supported by the device
But user does not want to use that.
Moreover, when first packet is sent, sync API will throw error. So what is the issue.
>
> >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > 3) not possible to store device (not driver) specific data within
> the
> > > > > session, but I think it is not really needed right now.
> > > > > > So probably minor compared to 2.b.2.
> > > > > >
> > > > > > [Akhil] So lets omit this for current discussion. And I hope we can find
> some
> > > > > way to deal with it.
> > > > >
> > > > > I don't think there is an easy way to fix that with existing API.
> > > > >
> > > > > >
> > > > > >
> > > > > > Actually #3 follows from #2, but decided to have them separated.
> > > > > >
> > > > > > 3. process() parameters/behavior
> > > > > > a) Our suggestion: user stores ptr to session ops (or to (*process)
> itself)
> > > and
> > > > > just does:
> > > > > > session_ops->process(sess, ...);
> > > > > > Advantages:
> > > > > > 1) fastest possible execution path
> > > > > > 2) no need to carry on dev_id for data-path
> > > > > >
> > > > > > [Akhil] I don't see any overhead of carrying dev id, at least it would be
> > > inline
> > > > > with the
> > > > > > current DPDK methodology.
> > > > >
> > > > > If we'll add process() into rte_cryptodev itself (same as we have
> > > > > enqueue_burst/dequeue_burst),
> > > > > then it will be an ABI breakage.
> > > > > Also there are discussions to get rid of that approach completely:
> > > > >
> > >
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails.dpd
> > > k.org%2Farchives%2Fdev%2F2019-
> > >
> September%2F144674.html&data=02%7C01%7Cakhil.goyal%40nxp.com%7
> > >
> C1859dc1d29cd45a51e9908d7571784bb%7C686ea1d3bc2b4c6fa92cd99c5c301
> > >
> 635%7C0%7C0%7C637073630835415165&sdata=Bz9jgisyVzRJNt1BijtvSlurh
> > > JU1vXBbynNwlMDjaco%3D&reserved=0
> > > > > So I am not sure this is a recommended way these days.
> > > >
> > > > We can either have it in rte_cryptodev or in rte_cryptodev_ops whichever
> > > > is good for you.
> > > >
> > > > Whether it is ABI breakage or not, as per your requirements, this is the
> correct
> > > > approach. Do you agree with this or not?
> > >
> > > I think it is possible approach, but not the best one:
> > > it looks quite flakey to me (see all these uncertainty with sym_session_init
> > > above),
> > > plus introduces extra overhead at data-path.
> >
> > Uncertainties can be handled appropriately using a feature flag
> >
> > >
> > > >
> > > > Now handling the API/ABI breakage is a separate story. In 19.11 release we
> > > > Are not much concerned about the ABI breakages, this was discussed in
> > > > community. So adding a new dev_ops wouldn't have been an issue.
> > > > Now since we are so close to RC1 deadline, we should come up with some
> > > > other solution for next release. May be having a pmd API in 20.02 and
> > > > converting it into formal one in 20.11
> > > >
> > > >
> > > > >
> > > > > > What you are suggesting is a new way to get the things done without
> much
> > > > > benefit.
> > > > >
> > > > > Would help with ABI stability plus better performance, isn't it enough?
> > > > >
> > > > > > Also I don't see any performance difference as crypto workload is
> heavier
> > > than
> > > > > > Code cycles, so that wont matter.
> > > > >
> > > > > It depends.
> > > > > Suppose function call costs you ~30 cycles.
> > > > > If you have burst of big packets (let say crypto for each will take ~2K
> cycles)
> > > that
> > > > > belong
> > > > > to the same session, then yes you wouldn't notice these extra 30 cycles
> at all.
> > > > > If you have burst of small packets (let say crypto for each will take ~300
> > > cycles)
> > > > > each
> > > > > belongs to different session, then it will cost you ~10% extra.
> > > >
> > > > Let us do some profiling on openssl with both the approaches and find out
> the
> > > > difference.
> > > >
> > > > >
> > > > > > So IMO, there is no advantage in your suggestion as well.
> > > > > >
> > > > > >
> > > > > > Disadvantages:
> > > > > > 3) user has to carry on session_ops pointer explicitly
> > > > > > b) Your suggestion: add (*cpu_process) inside rte_cryptodev_ops
> and
> > > then:
> > > > > > rte_crypto_cpu_sym_process(uint8_t dev_id,
> > > rte_cryptodev_sym_session
> > > > > *sess, /*data parameters*/) {...
> > > > > > rte_cryptodevs[dev_id].dev_ops->cpu_process(ses, ...);
> > > > > > /*and then inside PMD specifc process: */
> > > > > > pmd_private_session = sess-
> > > >sess_data[this_pmd_driver_id].data;
> > > > > > /* and then most likely either */
> > > > > > pmd_private_session->process(pmd_private_session, ...);
> > > > > > /* or jump based on session/input data */
> > > > > > Advantages:
> > > > > > 1) don't see any...
> > > > > > Disadvantages:
> > > > > > 2) User has to carry on dev_id inside data-path
> > > > > > 3) Extra level of indirection (plus data dependency) - both for
> data and
> > > > > instructions.
> > > > > > Possible slowdown compared to a) (not measured).
> > > > > >
> > > > > > Having said all this, if the disagreements cannot be resolved, you can
> go
> > > for a
> > > > > pmd API specific
> > > > > > to your PMDs,
> > > > >
> > > > > I don't think it is good idea.
> > > > > PMD specific API is sort of deprecated path, also there is no clean way to
> use
> > > it
> > > > > within the libraries.
> > > >
> > > > I know that this is a deprecated path, we can use it until we are not
> allowed
> > > > to break ABI/API
> > > >
> > > > >
> > > > > > because as per my understanding the solution doesn't look scalable to
> > > other
> > > > > PMDs.
> > > > > > Your approach is aligned only to Intel , will not benefit others like
> openssl
> > > > > which is used by all
> > > > > > vendors.
> > > > >
> > > > > I feel quite opposite, from my perspective majority of SW backed PMDs
> will
> > > > > benefit from it.
> > > > > And I don't see anything Intel specific in my proposals above.
> > > > > About openssl PMD: I am not an expert here, but looking at the code, I
> think
> > > it
> > > > > will fit really well.
> > > > > Look yourself at its internal functions:
> > > > > process_openssl_auth_op/process_openssl_crypto_op,
> > > > > I think they doing exactly the same - they use sync API underneath, and
> they
> > > are
> > > > > session based
> > > > > (AFAIK you don't need any device/queue data, everything that needed for
> > > > > crypto/auth is stored inside session).
> > > > >
> > > > By vendor specific, I mean,
> > > > - no PMD would like to have 2 different variants of session Init APIs for
> doing
> > > the same stuff.
> > > > - stacks will become vendor specific while using 2 separate session create
> APIs.
> > > No stack would
> > > > Like to support 2 variants of session create- one for HW PMDs and one for
> SW
> > > PMDs.
> > >
> > > I think what you refer on has nothing to do with 'vendor specific'.
> > > I would name it 'extra overhead for PMD and stack writers'.
> > > Yes, for sure there is extra overhead (as always with new API) -
> > > for both producer (PMD writer) and consumer (stack writer):
> > > New function(s) to support, probably more tests to create/run, etc.
> > > Though this API is optional - if PMD/stack maintainer doesn't see
> > > value in it, they are free not to support it.
> > > From other side, re-using rte_cryptodev_sym_session_init()
> > > wouldn't help anyway - both data-path and control-path would differ
> > > from async mode anyway.
> > > BTW, right now to support different HW flavors
> > > we do have 4 different control and data-paths for both
> > > ipsec-secgw and librte_ipsec:
> > > lkds-none/lksd-proto/inline-crypto/inline-proto.
> > > And that is considered to be ok.
> >
> > No that is not ok. We cannot add new paths for every other case.
>
> What I am saying: if let-say lookaside-proto/inline-crypto/inline-proto
> deserves its own case in rte_security/rte_crypto API,
> I don't understand why cpu-crypto doesn't.
Because cpu-crypto is done by a crypto device and for that we have lookaside none.
SW PMDs are registered as crypto device and we should leverage crypto framework.
I would suggest in future may be 20.11, we can have a security wrapper over cryptodev API
For lookaside none use case. So that we will have a single API set for all cases.
>
> > Those 4 are controlled using 2 set of APIs.
>
> Yes there are 2 API sets (rte_cryptodev/rte_security),
> but in fact if you look at ipsec-secgw and librte_ipsec we have 4 different code
> paths.
> For both create_session() and ipsec_enqueue() we have a big switch() with 4
> different cases.
> Nearly the same for librte_ipsec - we have different prepare/process
> function pointers for each security type.
>
> > We should try our best to
> > Have minimum overhead to the application writer. This pain was also
> discussed
> > In the one of DPDK conference as well.
> > DPDK is not a standalone entity, there are stacks running over it always.
> > We should not add API for every other use case when we have an alternative
> > Approach with the existing API set.
> >
> > Now introducing another one would add to that pain and a lot of work for
> > Both producer and consumer.
>
> If I would see a clean approach to implement desired functionality
> without introducing new API - I would definitely support it.
> The problem is that from my perspective,
> what you suggesting with existing API will bring more drawbacks then positives.
From my perspective I see more benefits than the negatives.
- less changes in driver/app
- no major performance gap
- easier migration for the stack from one SOC to other.
The main argument from my side is that:
You need synchronous processing for SW PMDs which is data path.
Why do you need a special session control path to do that. You should have some extra
Params packed in the same control API.
> BTW, our first approach (via rte_security) does reuse existing API,
> so if adding new API is the main concern - let's reconsider that path.
>
That will be there only if we have security wrapper on cryptodev session create
For lookaside none use case. But the issue would still remain the same.
No special session create for supporting sync mode.
> > It would be interesting to see how much performance difference will be there
> in the
> > Two approaches. As per my understanding it wont be much as compared to
> the
> > Extra work that you will be inducing.
> >
> > -Akhil
> >
> > > Honestly, I don't understand why SW backed implementations
> > > can't have their own path that would suite them most.
> > > Konstantin
> > >
> > >
> > >
> > >
> > >
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 0/5] Some fixes for hinic PMD driver
@ 2019-11-01 13:36 3% Xiaoyun wang
2019-11-07 9:29 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Xiaoyun wang @ 2019-11-01 13:36 UTC (permalink / raw)
To: dev
Cc: ferruh.yigit, zhouguoyang, wulike1, luoxianjun, shahar.belkar,
tanya.brokhman, xuanziyang2, Xiaoyun wang
This patch fixes code style check issue, offload info calculating problem
for TSO offload. Replace mbuf alloc function with initialized, remove
Flow Director feature from doc files and add Flow API feature to
hinic.ini, Remove Free Tx mbuf on demand from hinic.ini.
--
v4->v5:
- Fix code style check issue
- Fix offload info calculating problem for TSO
- Replace mbuf alloc function with initialized
- Remove Flow Director feature from doc files
- Remove Free Tx mbuf on demand from hinic.ini
v3->v4:
- Fix receive performance code review comments
- Fix 32-bit build errs for mbox logs
- Modify skb description as mbuf
v2->v3:
- Split hinic.ini and hinic.rst to related feature patches
- Add min_mtu & max_mtu initialization for hinic_dev_infos_get
- Fix fdir config patch with net/hinic/base
- Split link patch into link and fw version getting 2 patches
- Update pmd doc files to new next version
- Add comments for cover letter patch
- Add rxq & txq info getting interfaces
- Fix load intrinsics for receiving packets
v1->v2:
- Fix RSS bugs for vxlan packets inner type
- Add comments for new added func interface
- Fix code review comments from patch v1
- Fix code style problems
- Remove ceq interfaces and definitions that not used
- Fix aeq init bugs, firstly alloc aeq resource, then set aeq ctrl len
- Fix bar map bugs for VF Page size larger than PF
- Modify link state set, add enable or disable fiber in tx direction
- Fix mbox and mgmt channel sync lock mechanism to reduce CPU usage
- Fix FDIR bugs for VRRP packets
- Fit ABI changes from dpdk lib
v1:
- Support SR-IOV function
- Support FLOW API for packet filter
- Support allmulticast mode
- Support MTU set
- Support unicast and multicast MAC set
- Support setting link down and up
- Support get firmware version
- Support inner L3 checksum offload
- Support LRO offload
- Add hinic PMD doc files
Xiaoyun wang (5):
net/hinic/base: fix code style check issue
net/hinic: fix offload info calculating problem for TSO
net/hinic: optimize mbuf alloc function with initialized
net/hinic: remove Flow Director feature from doc files
net/hinic: remove Free Tx mbuf on demand from hinic.ini
doc/guides/nics/features/hinic.ini | 3 +--
doc/guides/nics/hinic.rst | 2 +-
doc/guides/rel_notes/release_19_11.rst | 2 +-
drivers/net/hinic/base/hinic_pmd_mbox.c | 7 +++----
drivers/net/hinic/hinic_pmd_rx.c | 7 ++++---
drivers/net/hinic/hinic_pmd_tx.c | 3 ++-
6 files changed, 12 insertions(+), 12 deletions(-)
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [EXT] [PATCH v5 1/3] security: add anti replay window size
2019-10-31 13:15 5% ` [dpdk-dev] [PATCH v5 " Hemant Agrawal
2019-10-31 13:15 5% ` [dpdk-dev] [PATCH v5 2/3] ipsec: remove redundant replay_win_sz Hemant Agrawal
@ 2019-11-01 6:16 0% ` Anoob Joseph
2019-11-06 6:54 5% ` [dpdk-dev] [PATCH v6 " Hemant Agrawal
2 siblings, 0 replies; 200+ results
From: Anoob Joseph @ 2019-11-01 6:16 UTC (permalink / raw)
To: Hemant Agrawal, dev, akhil.goyal; +Cc: konstantin.ananyev
Hi Hemant,
Please see inline.
> -----Original Message-----
> From: Hemant Agrawal <hemant.agrawal@nxp.com>
> Sent: Thursday, October 31, 2019 6:45 PM
> To: dev@dpdk.org; akhil.goyal@nxp.com
> Cc: konstantin.ananyev@intel.com; Anoob Joseph <anoobj@marvell.com>;
> Hemant Agrawal <hemant.agrawal@nxp.com>
> Subject: [EXT] [PATCH v5 1/3] security: add anti replay window size
>
> External Email
>
> ----------------------------------------------------------------------
> At present the ipsec xfrom is missing the important step to configure the anti
> replay window size.
> The newly added field will also help in to enable or disable the anti replay
> checking, if available in offload by means of non-zero or zero value.
>
> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> doc/guides/rel_notes/release_19_11.rst | 6 +++++-
> lib/librte_security/Makefile | 2 +-
> lib/librte_security/meson.build | 2 +-
> lib/librte_security/rte_security.h | 8 ++++++++
> 4 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_19_11.rst
> b/doc/guides/rel_notes/release_19_11.rst
> index ae8e7b2f0..0508ec545 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -365,6 +365,10 @@ ABI Changes
> align the Ethernet header on receive and all known encapsulations
> preserve the alignment of the header.
>
> +* security: A new field ''replay_win_sz'' has been added to the
> +structure
> + ``rte_security_ipsec_xform``, which specify the Anti replay window
> +size
> + to enable sequence replay attack handling.
> +
>
> Shared Library Versions
> -----------------------
> @@ -437,7 +441,7 @@ The libraries prepended with a plus sign were
> incremented in this version.
> librte_reorder.so.1
> librte_ring.so.2
> + librte_sched.so.4
> - librte_security.so.2
> + + librte_security.so.3
> librte_stack.so.1
> librte_table.so.3
> librte_timer.so.1
> diff --git a/lib/librte_security/Makefile b/lib/librte_security/Makefile index
> 6708effdb..6a268ee2a 100644
> --- a/lib/librte_security/Makefile
> +++ b/lib/librte_security/Makefile
> @@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk LIB = librte_security.a
>
> # library version
> -LIBABIVER := 2
> +LIBABIVER := 3
>
> # build flags
> CFLAGS += -O3
> diff --git a/lib/librte_security/meson.build b/lib/librte_security/meson.build
> index a5130d2f6..6fed01273 100644
> --- a/lib/librte_security/meson.build
> +++ b/lib/librte_security/meson.build
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2017-2019 Intel
> Corporation
>
> -version = 2
> +version = 3
> sources = files('rte_security.c')
> headers = files('rte_security.h', 'rte_security_driver.h') deps += ['mempool',
> 'cryptodev'] diff --git a/lib/librte_security/rte_security.h
> b/lib/librte_security/rte_security.h
> index aaafdfcd7..216e5370f 100644
> --- a/lib/librte_security/rte_security.h
> +++ b/lib/librte_security/rte_security.h
> @@ -212,6 +212,10 @@ struct rte_security_ipsec_xform {
> /**< Tunnel parameters, NULL for transport mode */
> uint64_t esn_soft_limit;
> /**< ESN for which the overflow event need to be raised */
> + uint32_t replay_win_sz;
> + /**< Anti replay window size to enable sequence replay attack handling.
> + * replay checking is disabled if the window size is 0.
> + */
> };
>
> /**
> @@ -563,6 +567,10 @@ struct rte_security_capability {
> /**< IPsec SA direction */
> struct rte_security_ipsec_sa_options options;
> /**< IPsec SA supported options */
> + uint32_t replay_win_sz_max;
> + /**< IPsec Anti Replay Window Size. A '0' value
> + * indicates that Anti Replay Window is not supported.
[Anoob] Minor comment. Should it be "Anti Replay is not supported."?
> + */
> } ipsec;
> /**< IPsec capability */
> struct {
> --
> 2.17.1
Acked-by: Anoob Joseph <anoobj@marvell.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: remove deprecated port count function
2019-10-28 13:03 0% ` Neil Horman
@ 2019-10-31 18:52 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-10-31 18:52 UTC (permalink / raw)
To: Neil Horman, Thomas Monjalon
Cc: John McNamara, Marko Kovacevic, Andrew Rybchenko, dev
On 10/28/2019 1:03 PM, Neil Horman wrote:
> On Mon, Oct 28, 2019 at 11:49:34AM +0100, Thomas Monjalon wrote:
>> The function rte_eth_dev_count() was marked as deprecated in DPDK 18.05
>> in commit d9a42a69febf ("ethdev: deprecate port count function").
>> It was planned to be removed after 19.11 LTS release,
>> but given we must not break ABI between 19.11 and 20.11,
>> it is removed now.
>>
>> Note the ABI version is not dumped in this commit
>> because other changes already did.
>>
>> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
>
Applied to dpdk-next-net/master, thanks.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] DPDK Release Status Meeting 31/10/2019
@ 2019-10-31 18:43 4% Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-10-31 18:43 UTC (permalink / raw)
To: dpdk-dev; +Cc: Thomas Monjalon
Minutes 31 October 2019
-----------------------
Agenda:
* Release Dates
* Subtrees
Participants:
* Arm
* Debian/Microsoft
* Intel
* Marvell
* Mellanox
* NXP
* Red Hat
Release Dates
-------------
* v19.11 dates:
* RC1 is released on Sunday 27 October
* https://mails.dpdk.org/archives/announce/2019-October/000284.html
* RC2 Friday 8 November
* RC3 Friday 15 November
* Release Friday 22 November
* Proposed dates for 20.02 release on the mail list, please comment
https://mails.dpdk.org/archives/dev/2019-September/143311.html
These dates may affected from the 19.11 delays, please review again.
Subtrees
--------
* main
* mempool changes are important and under discussion
https://patches.dpdk.org/project/dpdk/list/?series=7161
* More review comment required on new vfio_pf kernel module
https://patches.dpdk.org/patch/58810/
* fib & rib library is waiting for new version
https://patches.dpdk.org/project/dpdk/list/?series=6380
* ring library changes may be postponed to next release
https://patches.dpdk.org/project/dpdk/list/?series=6949
* ABI/API patches, and tooling reviews are going on, more review welcome
* ABI policy: https://patches.dpdk.org/project/dpdk/list/?series=7080
* tooling
https://patches.dpdk.org/project/dpdk/list/?series=7035
https://patches.dpdk.org/project/dpdk/list/?series=7004
* WFE under review
https://patches.dpdk.org/project/dpdk/list/?series=7088
* next-net
* There are more ethdev patches that will be included in rc2
* next-net-crypto
* Some PMD changes will be in rc2
* security library changes will be merged without needing a deprecation notice
* ipsec-secgw changes are planned for rc2
* next-net-eventdev
* Planning to have a pull request next week
* l2fwd-event app & some crypto adapters can go in rc2
* next-net-virtio
* There will be some fixes for rc2
* Regression reported by Intel validation team
* next-net-intel
* ipn3ke PMD merged for rc2
* LTS
* v18.11.3 is released
https://mails.dpdk.org/archives/announce/2019-October/000283.html
DPDK Release Status Meetings
============================
The DPDK Release Status Meeting is intended for DPDK Committers to discuss
the status of the master tree and sub-trees, and for project managers to
track progress or milestone dates.
The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just
send an email to "John McNamara <john.mcnamara@intel.com>" for the invite.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 1/2] ethdev: expose basic xstats for driver use
@ 2019-10-31 16:40 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-10-31 16:40 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: dev
On Thu, 26 Sep 2019 15:46:52 +0300
Andrew Rybchenko <arybchenko@solarflare.com> wrote:
> On 9/19/19 4:17 PM, Stephen Hemminger wrote:
> > Avoid duplication by having generic basic xstats available
> > for use by drivers. A later patch uses this for failsafe
> > driver.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > Acked-by: Gaetan Rivet <gaetan.rivet@6wind.com>
>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>
> > diff --git a/lib/librte_ethdev/rte_ethdev_driver.h b/lib/librte_ethdev/rte_ethdev_driver.h
> > index 936ff8c98651..489889a72203 100644
> > --- a/lib/librte_ethdev/rte_ethdev_driver.h
> > +++ b/lib/librte_ethdev/rte_ethdev_driver.h
> > @@ -208,6 +208,71 @@ rte_eth_linkstatus_get(const struct rte_eth_dev *dev,
> > #endif
> > }
> >
> > +/**
> > + * @internal
> > + * Get basic stats part of xstats for an ethernet device.
> > + *
> > + * @param dev
> > + * Pointer to struct rte_eth_dev.
> > + */
> > +__rte_experimental
>
> Does it make sense to mark internal API as experimental?
> I thought that @internal is not a part of API/ABI.
Checkpatch picks on it
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
2019-10-31 15:29 0% ` Ferruh Yigit
@ 2019-10-31 15:54 0% ` Wang, Haiyue
0 siblings, 0 replies; 200+ results
From: Wang, Haiyue @ 2019-10-31 15:54 UTC (permalink / raw)
To: Yigit, Ferruh, Jerin Jacob
Cc: Thomas Monjalon, dpdk-dev, Ye, Xiaolong, Kinsella, Ray,
Iremonger, Bernard, Sun, Chenmin, Andrew Rybchenko,
Slava Ovsiienko, Stephen Hemminger, David Marchand, Jerin Jacob
> -----Original Message-----
> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> Sent: Thursday, October 31, 2019 23:30
> To: Wang, Haiyue <haiyue.wang@intel.com>; Jerin Jacob <jerinjacobk@gmail.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; dpdk-dev <dev@dpdk.org>; Ye, Xiaolong
> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Iremonger, Bernard
> <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
>
> On 10/31/2019 3:07 PM, Wang, Haiyue wrote:
> >> -----Original Message-----
> >> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> >> Sent: Thursday, October 31, 2019 22:58
> >> To: Wang, Haiyue <haiyue.wang@intel.com>; Jerin Jacob <jerinjacobk@gmail.com>
> >> Cc: Thomas Monjalon <thomas@monjalon.net>; dpdk-dev <dev@dpdk.org>; Ye, Xiaolong
> >> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Iremonger, Bernard
> >> <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew Rybchenko
> >> <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> >> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> >> <jerinj@marvell.com>
> >> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> >>
> >> On 10/31/2019 11:16 AM, Wang, Haiyue wrote:
> >>>> -----Original Message-----
> >>>> From: Jerin Jacob <jerinjacobk@gmail.com>
> >>>> Sent: Thursday, October 31, 2019 18:46
> >>>> To: Wang, Haiyue <haiyue.wang@intel.com>
> >>>> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>; dpdk-dev
> >>>> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> >>>> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> >>>> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> >> Hemminger
> >>>> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> >>>> <jerinj@marvell.com>
> >>>> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> >>>>
> >>>>>> 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
> >>>>>> parameter and convert the 'options' to string and combine into single string as
> >>>>>> a helper function to the applications.
> >>>>>>
> >>>>>
> >>>>> Change:
> >>>>> const char *
> >>>>> rte_eth_burst_mode_option_name(uint64_t option)
> >>>>>
> >>>>> to:
> >>>>> int
> >>>>> rte_eth_burst_mode_option_name(struct rte_eth_burst_mode *mode, char *str) ?
> >>>>
> >>>>
> >>>> Since we are not ready to _remove_ flags in public API and rc2 time is
> >>>> ticking, probably the following the change
> >>>> would be enough. IMO, This API can be used only for logging purpose, I
> >>>> don't want to spend too
> >>>> many cycles on this discussion. I am leaving the decision to ethdev
> >>>> maintainers to accommodate
> >>>> the specifics of adding a string-based alternate options scheme.
> >>>>
> >>>
> >>> Thanks, Jerin.
> >>>
> >>>>
> >>>> [master][dpdk.org] $ git diff
> >>>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> >>>> index c36c1b631..2f9d2c0a7 100644
> >>>> --- a/lib/librte_ethdev/rte_ethdev.h
> >>>> +++ b/lib/librte_ethdev/rte_ethdev.h
> >>>> @@ -1272,8 +1272,11 @@ enum rte_eth_burst_mode_option {
> >>>> * Ethernet device RX/TX queue packet burst mode information structure.
> >>>> * Used to retrieve information about packet burst mode setting.
> >>>> */
> >>>> +#define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 128
> >>
> >> Should we make it bigger to prevent ABI break just because of this later? Like
> >> 512 or bigger?
> >>
> >
> > Use 1024 ?
> >
> >>>> +
> >>>> struct rte_eth_burst_mode {
> >>>> uint64_t options;
> >>>> + char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
> >>>> };
> >>>
> >>> +1
> >>>
> >>
> >> +1
> >>
> >> It is not as flexible as getting the size from the PMD but much simpler, both
> >> for the user and PMD.
> >>
> >> And what about dropping the 'rte_eth_burst_mode_option_name()', if
> >> 'rte_eth_tx_burst_mode_get()' converts the 'options' to text
> >> ('alternate_options') as Jerin suggested, we can drop it.
> >>
> >> So only difference from what Jerin suggested will be keeping 'uint64_t options'
> >> public for known/limited standardized options, which is currently only for
> >> vectorization information.
> >
> > Since 'struct rte_eth_burst_mode' will be public, how about keep current design for
> > rte_eth_rx/tx_burst_mode_get() ?
>
> What do you mean keep current design, not having a string field in "struct
> rte_eth_burst_mode"?
>
> >
> > But change 'const char *rte_eth_burst_mode_option_name(uint64_t option)' to
> > 'int rte_eth_burst_mode_name(struct rte_eth_burst_mode *mode, char *name)' ?
> > When 'name' is NULL, return the buffer size will be used. If non-NULL, format
> > all the options. This will reduce the twice PMDs calls:
> > dev->dev_ops->rx/tx_burst_mode_get
> > And leave the filled *mode for application.
> >
>
> we need "dev_ops->rx/tx_burst_mode_get" to get information from PMDs, except
> from 'uint64_t options' the provided information already as string, if the
> ethdev APIs for these devops converts 'uint64_t options' to string and append to
> 'alternate_options', application will already have all the string, so won't need
> this 'rte_eth_burst_mode_option_name()' API anymore.
Got it now. Thanks!
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
2019-10-31 15:07 0% ` Wang, Haiyue
@ 2019-10-31 15:29 0% ` Ferruh Yigit
2019-10-31 15:54 0% ` Wang, Haiyue
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-10-31 15:29 UTC (permalink / raw)
To: Wang, Haiyue, Jerin Jacob
Cc: Thomas Monjalon, dpdk-dev, Ye, Xiaolong, Kinsella, Ray,
Iremonger, Bernard, Sun, Chenmin, Andrew Rybchenko,
Slava Ovsiienko, Stephen Hemminger, David Marchand, Jerin Jacob
On 10/31/2019 3:07 PM, Wang, Haiyue wrote:
>> -----Original Message-----
>> From: Yigit, Ferruh <ferruh.yigit@intel.com>
>> Sent: Thursday, October 31, 2019 22:58
>> To: Wang, Haiyue <haiyue.wang@intel.com>; Jerin Jacob <jerinjacobk@gmail.com>
>> Cc: Thomas Monjalon <thomas@monjalon.net>; dpdk-dev <dev@dpdk.org>; Ye, Xiaolong
>> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Iremonger, Bernard
>> <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew Rybchenko
>> <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
>> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
>> <jerinj@marvell.com>
>> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
>>
>> On 10/31/2019 11:16 AM, Wang, Haiyue wrote:
>>>> -----Original Message-----
>>>> From: Jerin Jacob <jerinjacobk@gmail.com>
>>>> Sent: Thursday, October 31, 2019 18:46
>>>> To: Wang, Haiyue <haiyue.wang@intel.com>
>>>> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>; dpdk-dev
>>>> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
>>>> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
>>>> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
>> Hemminger
>>>> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
>>>> <jerinj@marvell.com>
>>>> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
>>>>
>>>>>> 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
>>>>>> parameter and convert the 'options' to string and combine into single string as
>>>>>> a helper function to the applications.
>>>>>>
>>>>>
>>>>> Change:
>>>>> const char *
>>>>> rte_eth_burst_mode_option_name(uint64_t option)
>>>>>
>>>>> to:
>>>>> int
>>>>> rte_eth_burst_mode_option_name(struct rte_eth_burst_mode *mode, char *str) ?
>>>>
>>>>
>>>> Since we are not ready to _remove_ flags in public API and rc2 time is
>>>> ticking, probably the following the change
>>>> would be enough. IMO, This API can be used only for logging purpose, I
>>>> don't want to spend too
>>>> many cycles on this discussion. I am leaving the decision to ethdev
>>>> maintainers to accommodate
>>>> the specifics of adding a string-based alternate options scheme.
>>>>
>>>
>>> Thanks, Jerin.
>>>
>>>>
>>>> [master][dpdk.org] $ git diff
>>>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
>>>> index c36c1b631..2f9d2c0a7 100644
>>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>>> @@ -1272,8 +1272,11 @@ enum rte_eth_burst_mode_option {
>>>> * Ethernet device RX/TX queue packet burst mode information structure.
>>>> * Used to retrieve information about packet burst mode setting.
>>>> */
>>>> +#define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 128
>>
>> Should we make it bigger to prevent ABI break just because of this later? Like
>> 512 or bigger?
>>
>
> Use 1024 ?
>
>>>> +
>>>> struct rte_eth_burst_mode {
>>>> uint64_t options;
>>>> + char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
>>>> };
>>>
>>> +1
>>>
>>
>> +1
>>
>> It is not as flexible as getting the size from the PMD but much simpler, both
>> for the user and PMD.
>>
>> And what about dropping the 'rte_eth_burst_mode_option_name()', if
>> 'rte_eth_tx_burst_mode_get()' converts the 'options' to text
>> ('alternate_options') as Jerin suggested, we can drop it.
>>
>> So only difference from what Jerin suggested will be keeping 'uint64_t options'
>> public for known/limited standardized options, which is currently only for
>> vectorization information.
>
> Since 'struct rte_eth_burst_mode' will be public, how about keep current design for
> rte_eth_rx/tx_burst_mode_get() ?
What do you mean keep current design, not having a string field in "struct
rte_eth_burst_mode"?
>
> But change 'const char *rte_eth_burst_mode_option_name(uint64_t option)' to
> 'int rte_eth_burst_mode_name(struct rte_eth_burst_mode *mode, char *name)' ?
> When 'name' is NULL, return the buffer size will be used. If non-NULL, format
> all the options. This will reduce the twice PMDs calls:
> dev->dev_ops->rx/tx_burst_mode_get
> And leave the filled *mode for application.
>
we need "dev_ops->rx/tx_burst_mode_get" to get information from PMDs, except
from 'uint64_t options' the provided information already as string, if the
ethdev APIs for these devops converts 'uint64_t options' to string and append to
'alternate_options', application will already have all the string, so won't need
this 'rte_eth_burst_mode_option_name()' API anymore.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
2019-10-31 14:58 3% ` Ferruh Yigit
@ 2019-10-31 15:07 0% ` Wang, Haiyue
2019-10-31 15:29 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Wang, Haiyue @ 2019-10-31 15:07 UTC (permalink / raw)
To: Yigit, Ferruh, Jerin Jacob
Cc: Thomas Monjalon, dpdk-dev, Ye, Xiaolong, Kinsella, Ray,
Iremonger, Bernard, Sun, Chenmin, Andrew Rybchenko,
Slava Ovsiienko, Stephen Hemminger, David Marchand, Jerin Jacob
> -----Original Message-----
> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> Sent: Thursday, October 31, 2019 22:58
> To: Wang, Haiyue <haiyue.wang@intel.com>; Jerin Jacob <jerinjacobk@gmail.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; dpdk-dev <dev@dpdk.org>; Ye, Xiaolong
> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Iremonger, Bernard
> <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
>
> On 10/31/2019 11:16 AM, Wang, Haiyue wrote:
> >> -----Original Message-----
> >> From: Jerin Jacob <jerinjacobk@gmail.com>
> >> Sent: Thursday, October 31, 2019 18:46
> >> To: Wang, Haiyue <haiyue.wang@intel.com>
> >> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>; dpdk-dev
> >> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> >> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> >> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> Hemminger
> >> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> >> <jerinj@marvell.com>
> >> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> >>
> >>>> 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
> >>>> parameter and convert the 'options' to string and combine into single string as
> >>>> a helper function to the applications.
> >>>>
> >>>
> >>> Change:
> >>> const char *
> >>> rte_eth_burst_mode_option_name(uint64_t option)
> >>>
> >>> to:
> >>> int
> >>> rte_eth_burst_mode_option_name(struct rte_eth_burst_mode *mode, char *str) ?
> >>
> >>
> >> Since we are not ready to _remove_ flags in public API and rc2 time is
> >> ticking, probably the following the change
> >> would be enough. IMO, This API can be used only for logging purpose, I
> >> don't want to spend too
> >> many cycles on this discussion. I am leaving the decision to ethdev
> >> maintainers to accommodate
> >> the specifics of adding a string-based alternate options scheme.
> >>
> >
> > Thanks, Jerin.
> >
> >>
> >> [master][dpdk.org] $ git diff
> >> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> >> index c36c1b631..2f9d2c0a7 100644
> >> --- a/lib/librte_ethdev/rte_ethdev.h
> >> +++ b/lib/librte_ethdev/rte_ethdev.h
> >> @@ -1272,8 +1272,11 @@ enum rte_eth_burst_mode_option {
> >> * Ethernet device RX/TX queue packet burst mode information structure.
> >> * Used to retrieve information about packet burst mode setting.
> >> */
> >> +#define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 128
>
> Should we make it bigger to prevent ABI break just because of this later? Like
> 512 or bigger?
>
Use 1024 ?
> >> +
> >> struct rte_eth_burst_mode {
> >> uint64_t options;
> >> + char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
> >> };
> >
> > +1
> >
>
> +1
>
> It is not as flexible as getting the size from the PMD but much simpler, both
> for the user and PMD.
>
> And what about dropping the 'rte_eth_burst_mode_option_name()', if
> 'rte_eth_tx_burst_mode_get()' converts the 'options' to text
> ('alternate_options') as Jerin suggested, we can drop it.
>
> So only difference from what Jerin suggested will be keeping 'uint64_t options'
> public for known/limited standardized options, which is currently only for
> vectorization information.
Since 'struct rte_eth_burst_mode' will be public, how about keep current design for
rte_eth_rx/tx_burst_mode_get() ?
But change 'const char *rte_eth_burst_mode_option_name(uint64_t option)' to
'int rte_eth_burst_mode_name(struct rte_eth_burst_mode *mode, char *name)' ?
When 'name' is NULL, return the buffer size will be used. If non-NULL, format
all the options. This will reduce the twice PMDs calls:
dev->dev_ops->rx/tx_burst_mode_get
And leave the filled *mode for application.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 4/4] doc: add maintainer for abi policy
@ 2019-10-31 15:07 4% ` Mcnamara, John
0 siblings, 0 replies; 200+ results
From: Mcnamara, John @ 2019-10-31 15:07 UTC (permalink / raw)
To: Ray Kinsella, dev
Cc: thomas, stephen, Richardson, Bruce, Yigit, Ferruh, Ananyev,
Konstantin, jerinj, olivier.matz, nhorman, maxime.coquelin,
Kovacevic, Marko, hemant.agrawal, ktraynor, aconole
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Friday, October 25, 2019 5:29 PM
> To: dev@dpdk.org
> Cc: mdr@ashroe.eu; thomas@monjalon.net; stephen@networkplumber.org;
> Richardson, Bruce <bruce.richardson@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; jerinj@marvell.com;
> olivier.matz@6wind.com; nhorman@tuxdriver.com;
> maxime.coquelin@redhat.com; Mcnamara, John <john.mcnamara@intel.com>;
> Kovacevic, Marko <marko.kovacevic@intel.com>; hemant.agrawal@nxp.com;
> ktraynor@redhat.com; aconole@redhat.com
> Subject: [PATCH v7 4/4] doc: add maintainer for abi policy
>
> Add an entry to the maintainer file for the abi policy.
>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 3/4] doc: updates to versioning guide for abi versions
@ 2019-10-31 15:07 4% ` Mcnamara, John
0 siblings, 0 replies; 200+ results
From: Mcnamara, John @ 2019-10-31 15:07 UTC (permalink / raw)
To: Ray Kinsella, dev
Cc: thomas, stephen, Richardson, Bruce, Yigit, Ferruh, Ananyev,
Konstantin, jerinj, olivier.matz, nhorman, maxime.coquelin,
Kovacevic, Marko, hemant.agrawal, ktraynor, aconole
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Friday, October 25, 2019 5:29 PM
> To: dev@dpdk.org
> Cc: mdr@ashroe.eu; thomas@monjalon.net; stephen@networkplumber.org;
> Richardson, Bruce <bruce.richardson@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; jerinj@marvell.com;
> olivier.matz@6wind.com; nhorman@tuxdriver.com;
> maxime.coquelin@redhat.com; Mcnamara, John <john.mcnamara@intel.com>;
> Kovacevic, Marko <marko.kovacevic@intel.com>; hemant.agrawal@nxp.com;
> ktraynor@redhat.com; aconole@redhat.com
> Subject: [PATCH v7 3/4] doc: updates to versioning guide for abi versions
>
> Updates to the ABI versioning guide, to account for the changes to the
> DPDK ABI/API policy. Fixes for references to abi versioning and policy
> guides.
>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 2/4] doc: changes to abi policy introducing major abi versions
@ 2019-10-31 15:06 9% ` Mcnamara, John
2019-11-05 15:11 5% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Mcnamara, John @ 2019-10-31 15:06 UTC (permalink / raw)
To: Ray Kinsella, dev
Cc: thomas, stephen, Richardson, Bruce, Yigit, Ferruh, Ananyev,
Konstantin, jerinj, olivier.matz, nhorman, maxime.coquelin,
Kovacevic, Marko, hemant.agrawal, ktraynor, aconole
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Friday, October 25, 2019 5:29 PM
> To: dev@dpdk.org
> Cc: mdr@ashroe.eu; thomas@monjalon.net; stephen@networkplumber.org;
> Richardson, Bruce <bruce.richardson@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; jerinj@marvell.com;
> olivier.matz@6wind.com; nhorman@tuxdriver.com;
> maxime.coquelin@redhat.com; Mcnamara, John <john.mcnamara@intel.com>;
> Kovacevic, Marko <marko.kovacevic@intel.com>; hemant.agrawal@nxp.com;
> ktraynor@redhat.com; aconole@redhat.com
> Subject: [PATCH v7 2/4] doc: changes to abi policy introducing major abi
> versions
>
> This policy change introduces major ABI versions, these are
> declared every year, typically aligned with the LTS release
> and are supported by subsequent releases in the following year.
> This change is intended to improve ABI stabilty for those projects
> consuming DPDK.
>
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
> ---
> doc/guides/contributing/abi_policy.rst | 321 ++++--
> .../contributing/img/abi_stability_policy.svg | 1059
There are build warnings after this patch. I know they are fixed in patch 3 but there shouldn't be any build warnings in each patch of the patchset.
$ make doc-guides-html
sphinx processing guides-html...
/work/dpdk_docs/doc/guides/contributing/abi_policy.rst:18:
WARNING: undefined label: what_is_soname (if the link has no caption the label must precede a section header)
/work/dpdk_docs/doc/guides/contributing/abi_policy.rst:22:
WARNING: undefined label: abi_versioning (if the link has no caption the label must precede a section header)
/work/dpdk_docs/doc/guides/contributing/abi_policy.rst:63:
WARNING: undefined label: what_is_soname (if the link has no caption the label must precede a section header)
/work/dpdk_docs/doc/guides/contributing/abi_policy.rst:73:
WARNING: undefined label: major_abi_versions (if the link has no caption the label must precede a section header)
/work/dpdk_docs/doc/guides/contributing/abi_policy.rst:145:
WARNING: undefined label: abi_versioning (if the link has no caption the label must precede a section header)
/work/dpdk_docs/doc/guides/contributing/abi_policy.rst:221:
WARNING: undefined label: abi_versioning (if the link has no caption the label must precede a section header)
/work/dpdk_docs/doc/guides/contributing/abi_policy.rst:318:
WARNING: undefined label: abi_versioning (if the link has no caption the label must precede a section header)
/work/dpdk_docs/doc/guides/contributing/patches.rst:159:
WARNING: unknown document: /contributing/versioning
/work/dpdk_docs/doc/guides/contributing/stable.rst:56:
WARNING: undefined label: abi_policy (if the link has no caption the label must precede a section header)
/work/dpdk_docs/doc/guides/rel_notes/deprecation.rst:7:
WARNING: unknown document: /contributing/versioning
The syntax of the following image caption is wrong:
.. _figure_what_is_an_abi:
.. figure:: img/what_is_an_abi.*
*Figure 1. Illustration of DPDK API and ABI .*
It should be indented and shouldn't have a figure number (that is added automatically) or bolding. Like this:
.. _figure_what_is_an_abi:
.. figure:: img/what_is_an_abi.*
Illustration of DPDK API and ABI.
See the following for details:
http://doc.dpdk.org/guides/contributing/documentation.html#images
The is a stray backtick here:
+changes must follow the `same process :ref:`described above <abi_changes>` as non-breaking
It should be:
+changes must follow the same process :ref:`described above <abi_changes>` as non-breaking
John
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v7 1/4] doc: separate versioning.rst into version and policy
@ 2019-10-31 15:02 0% ` Mcnamara, John
2019-11-05 15:11 0% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Mcnamara, John @ 2019-10-31 15:02 UTC (permalink / raw)
To: Ray Kinsella, dev
Cc: thomas, stephen, Richardson, Bruce, Yigit, Ferruh, Ananyev,
Konstantin, jerinj, olivier.matz, nhorman, maxime.coquelin,
Kovacevic, Marko, hemant.agrawal, ktraynor, aconole
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Friday, October 25, 2019 5:29 PM
> To: dev@dpdk.org
> Cc: mdr@ashroe.eu; thomas@monjalon.net; stephen@networkplumber.org;
> Richardson, Bruce <bruce.richardson@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; jerinj@marvell.com;
> olivier.matz@6wind.com; nhorman@tuxdriver.com;
> maxime.coquelin@redhat.com; Mcnamara, John <john.mcnamara@intel.com>;
> Kovacevic, Marko <marko.kovacevic@intel.com>; hemant.agrawal@nxp.com;
> ktraynor@redhat.com; aconole@redhat.com
> Subject: [PATCH v7 1/4] doc: separate versioning.rst into version and
> policy
>
> Separate versioning.rst into abi versioning and abi policy guidance, in
> preparation for adding more detail to the abi policy.
>
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
> ---
> doc/guides/contributing/abi_policy.rst | 167 ++++++++
> doc/guides/contributing/abi_versioning.rst | 427 +++++++++++++++++++++
> doc/guides/contributing/index.rst | 3 +-
> doc/guides/contributing/versioning.rst | 591 -----------------------
I think the it would be better to "git mv" versioning.rst to abi_versioning.rst first to maintain the history and then extract out the policy part.
Also, there is a build warning after this patch:
$ make doc-guides-html
sphinx processing guides-html...
/work/dpdk_docs/doc/guides/contributing/patches.rst:159:
WARNING: unknown document: /contributing/versioning
/work/dpdk_docs/doc/guides/rel_notes/deprecation.rst:7:
WARNING: unknown document: /contributing/versioning
John
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
@ 2019-10-31 14:58 3% ` Ferruh Yigit
2019-10-31 15:07 0% ` Wang, Haiyue
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-10-31 14:58 UTC (permalink / raw)
To: Wang, Haiyue, Jerin Jacob
Cc: Thomas Monjalon, dpdk-dev, Ye, Xiaolong, Kinsella, Ray,
Iremonger, Bernard, Sun, Chenmin, Andrew Rybchenko,
Slava Ovsiienko, Stephen Hemminger, David Marchand, Jerin Jacob
On 10/31/2019 11:16 AM, Wang, Haiyue wrote:
>> -----Original Message-----
>> From: Jerin Jacob <jerinjacobk@gmail.com>
>> Sent: Thursday, October 31, 2019 18:46
>> To: Wang, Haiyue <haiyue.wang@intel.com>
>> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>; dpdk-dev
>> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
>> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
>> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
>> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
>> <jerinj@marvell.com>
>> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
>>
>>>> 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
>>>> parameter and convert the 'options' to string and combine into single string as
>>>> a helper function to the applications.
>>>>
>>>
>>> Change:
>>> const char *
>>> rte_eth_burst_mode_option_name(uint64_t option)
>>>
>>> to:
>>> int
>>> rte_eth_burst_mode_option_name(struct rte_eth_burst_mode *mode, char *str) ?
>>
>>
>> Since we are not ready to _remove_ flags in public API and rc2 time is
>> ticking, probably the following the change
>> would be enough. IMO, This API can be used only for logging purpose, I
>> don't want to spend too
>> many cycles on this discussion. I am leaving the decision to ethdev
>> maintainers to accommodate
>> the specifics of adding a string-based alternate options scheme.
>>
>
> Thanks, Jerin.
>
>>
>> [master][dpdk.org] $ git diff
>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
>> index c36c1b631..2f9d2c0a7 100644
>> --- a/lib/librte_ethdev/rte_ethdev.h
>> +++ b/lib/librte_ethdev/rte_ethdev.h
>> @@ -1272,8 +1272,11 @@ enum rte_eth_burst_mode_option {
>> * Ethernet device RX/TX queue packet burst mode information structure.
>> * Used to retrieve information about packet burst mode setting.
>> */
>> +#define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 128
Should we make it bigger to prevent ABI break just because of this later? Like
512 or bigger?
>> +
>> struct rte_eth_burst_mode {
>> uint64_t options;
>> + char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
>> };
>
> +1
>
+1
It is not as flexible as getting the size from the PMD but much simpler, both
for the user and PMD.
And what about dropping the 'rte_eth_burst_mode_option_name()', if
'rte_eth_tx_burst_mode_get()' converts the 'options' to text
('alternate_options') as Jerin suggested, we can drop it.
So only difference from what Jerin suggested will be keeping 'uint64_t options'
public for known/limited standardized options, which is currently only for
vectorization information.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 2/3] ipsec: remove redundant replay_win_sz
2019-10-31 13:15 5% ` [dpdk-dev] [PATCH v5 " Hemant Agrawal
@ 2019-10-31 13:15 5% ` Hemant Agrawal
2019-11-05 22:01 0% ` Akhil Goyal
2019-11-01 6:16 0% ` [dpdk-dev] [EXT] [PATCH v5 1/3] security: add anti replay window size Anoob Joseph
2019-11-06 6:54 5% ` [dpdk-dev] [PATCH v6 " Hemant Agrawal
2 siblings, 1 reply; 200+ results
From: Hemant Agrawal @ 2019-10-31 13:15 UTC (permalink / raw)
To: dev, akhil.goyal; +Cc: konstantin.ananyev, anoobj, Hemant Agrawal
The rte_security lib has introduced replay_win_sz,
so it can be removed from the rte_ipsec lib.
Also, the relaved tests,app are also update to reflect
the usages.
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
app/test/test_ipsec.c | 2 +-
doc/guides/rel_notes/release_19_11.rst | 7 +++++--
examples/ipsec-secgw/ipsec.c | 1 +
examples/ipsec-secgw/sa.c | 2 +-
lib/librte_ipsec/Makefile | 2 +-
lib/librte_ipsec/meson.build | 1 +
lib/librte_ipsec/rte_ipsec_sa.h | 6 ------
lib/librte_ipsec/sa.c | 4 ++--
8 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
index 4007eff19..7dc83fee7 100644
--- a/app/test/test_ipsec.c
+++ b/app/test/test_ipsec.c
@@ -689,11 +689,11 @@ fill_ipsec_param(uint32_t replay_win_sz, uint64_t flags)
prm->userdata = 1;
prm->flags = flags;
- prm->replay_win_sz = replay_win_sz;
/* setup ipsec xform */
prm->ipsec_xform = ut_params->ipsec_xform;
prm->ipsec_xform.salt = (uint32_t)rte_rand();
+ prm->ipsec_xform.replay_win_sz = replay_win_sz;
/* setup tunnel related fields */
prm->tun.hdr_len = sizeof(ipv4_outer);
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index 0508ec545..ca414edb5 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -365,10 +365,13 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
-* security: A new field ''replay_win_sz'' has been added to the structure
+* security: The field ''replay_win_sz'' has been moved from ipsec library
+ based ''rte_ipsec_sa_prm'' structure to security library based structure
``rte_security_ipsec_xform``, which specify the Anti replay window size
to enable sequence replay attack handling.
+* ipsec: The field ''replay_win_sz'' has been removed from the structure
+ ''rte_ipsec_sa_prm'' as it has been added to the security library.
Shared Library Versions
-----------------------
@@ -411,7 +414,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_gso.so.1
librte_hash.so.2
librte_ip_frag.so.1
- librte_ipsec.so.1
+ + librte_ipsec.so.2
librte_jobstats.so.1
librte_kni.so.2
librte_kvargs.so.1
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 51fb22e8a..159e81f99 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -49,6 +49,7 @@ set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
/* TODO support for Transport */
}
ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
+ ipsec->replay_win_sz = app_sa_prm.window_size;
}
int
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 14ee94731..3d687c459 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -1055,7 +1055,7 @@ fill_ipsec_app_sa_prm(struct rte_ipsec_sa_prm *prm,
prm->flags = app_prm->flags;
prm->ipsec_xform.options.esn = app_prm->enable_esn;
- prm->replay_win_sz = app_prm->window_size;
+ prm->ipsec_xform.replay_win_sz = app_prm->window_size;
}
static int
diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile
index 81fb99980..161ea9e3d 100644
--- a/lib/librte_ipsec/Makefile
+++ b/lib/librte_ipsec/Makefile
@@ -14,7 +14,7 @@ LDLIBS += -lrte_cryptodev -lrte_security -lrte_hash
EXPORT_MAP := rte_ipsec_version.map
-LIBABIVER := 1
+LIBABIVER := 2
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) += esp_inb.c
diff --git a/lib/librte_ipsec/meson.build b/lib/librte_ipsec/meson.build
index 70358526b..e8604dadd 100644
--- a/lib/librte_ipsec/meson.build
+++ b/lib/librte_ipsec/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2018 Intel Corporation
+version = 2
allow_experimental_apis = true
sources = files('esp_inb.c', 'esp_outb.c', 'sa.c', 'ses.c', 'ipsec_sad.c')
diff --git a/lib/librte_ipsec/rte_ipsec_sa.h b/lib/librte_ipsec/rte_ipsec_sa.h
index 47ce169d2..1cfde5874 100644
--- a/lib/librte_ipsec/rte_ipsec_sa.h
+++ b/lib/librte_ipsec/rte_ipsec_sa.h
@@ -47,12 +47,6 @@ struct rte_ipsec_sa_prm {
uint8_t proto; /**< next header protocol */
} trs; /**< transport mode related parameters */
};
-
- /**
- * window size to enable sequence replay attack handling.
- * replay checking is disabled if the window size is 0.
- */
- uint32_t replay_win_sz;
};
/**
diff --git a/lib/librte_ipsec/sa.c b/lib/librte_ipsec/sa.c
index 23d394b46..6f1d92c3c 100644
--- a/lib/librte_ipsec/sa.c
+++ b/lib/librte_ipsec/sa.c
@@ -439,7 +439,7 @@ rte_ipsec_sa_size(const struct rte_ipsec_sa_prm *prm)
return rc;
/* determine required size */
- wsz = prm->replay_win_sz;
+ wsz = prm->ipsec_xform.replay_win_sz;
return ipsec_sa_size(type, &wsz, &nb);
}
@@ -461,7 +461,7 @@ rte_ipsec_sa_init(struct rte_ipsec_sa *sa, const struct rte_ipsec_sa_prm *prm,
return rc;
/* determine required size */
- wsz = prm->replay_win_sz;
+ wsz = prm->ipsec_xform.replay_win_sz;
sz = ipsec_sa_size(type, &wsz, &nb);
if (sz < 0)
return sz;
--
2.17.1
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v5 1/3] security: add anti replay window size
2019-10-31 4:54 5% ` [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size Hemant Agrawal
` (2 preceding siblings ...)
2019-10-31 10:20 0% ` Ananyev, Konstantin
@ 2019-10-31 13:15 5% ` Hemant Agrawal
2019-10-31 13:15 5% ` [dpdk-dev] [PATCH v5 2/3] ipsec: remove redundant replay_win_sz Hemant Agrawal
` (2 more replies)
3 siblings, 3 replies; 200+ results
From: Hemant Agrawal @ 2019-10-31 13:15 UTC (permalink / raw)
To: dev, akhil.goyal; +Cc: konstantin.ananyev, anoobj, Hemant Agrawal
At present the ipsec xfrom is missing the important step
to configure the anti replay window size.
The newly added field will also help in to enable or disable
the anti replay checking, if available in offload by means
of non-zero or zero value.
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
doc/guides/rel_notes/release_19_11.rst | 6 +++++-
lib/librte_security/Makefile | 2 +-
lib/librte_security/meson.build | 2 +-
lib/librte_security/rte_security.h | 8 ++++++++
4 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index ae8e7b2f0..0508ec545 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -365,6 +365,10 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
+* security: A new field ''replay_win_sz'' has been added to the structure
+ ``rte_security_ipsec_xform``, which specify the Anti replay window size
+ to enable sequence replay attack handling.
+
Shared Library Versions
-----------------------
@@ -437,7 +441,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_reorder.so.1
librte_ring.so.2
+ librte_sched.so.4
- librte_security.so.2
+ + librte_security.so.3
librte_stack.so.1
librte_table.so.3
librte_timer.so.1
diff --git a/lib/librte_security/Makefile b/lib/librte_security/Makefile
index 6708effdb..6a268ee2a 100644
--- a/lib/librte_security/Makefile
+++ b/lib/librte_security/Makefile
@@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_security.a
# library version
-LIBABIVER := 2
+LIBABIVER := 3
# build flags
CFLAGS += -O3
diff --git a/lib/librte_security/meson.build b/lib/librte_security/meson.build
index a5130d2f6..6fed01273 100644
--- a/lib/librte_security/meson.build
+++ b/lib/librte_security/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017-2019 Intel Corporation
-version = 2
+version = 3
sources = files('rte_security.c')
headers = files('rte_security.h', 'rte_security_driver.h')
deps += ['mempool', 'cryptodev']
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index aaafdfcd7..216e5370f 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -212,6 +212,10 @@ struct rte_security_ipsec_xform {
/**< Tunnel parameters, NULL for transport mode */
uint64_t esn_soft_limit;
/**< ESN for which the overflow event need to be raised */
+ uint32_t replay_win_sz;
+ /**< Anti replay window size to enable sequence replay attack handling.
+ * replay checking is disabled if the window size is 0.
+ */
};
/**
@@ -563,6 +567,10 @@ struct rte_security_capability {
/**< IPsec SA direction */
struct rte_security_ipsec_sa_options options;
/**< IPsec SA supported options */
+ uint32_t replay_win_sz_max;
+ /**< IPsec Anti Replay Window Size. A '0' value
+ * indicates that Anti Replay Window is not supported.
+ */
} ipsec;
/**< IPsec capability */
struct {
--
2.17.1
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size
2019-10-31 4:54 5% ` [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size Hemant Agrawal
2019-10-31 4:54 5% ` [dpdk-dev] [PATCH v4 2/3] ipsec: remove redundant replay_win_sz Hemant Agrawal
2019-10-31 6:29 0% ` [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size Anoob Joseph
@ 2019-10-31 10:20 0% ` Ananyev, Konstantin
2019-10-31 13:15 5% ` [dpdk-dev] [PATCH v5 " Hemant Agrawal
3 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2019-10-31 10:20 UTC (permalink / raw)
To: Hemant Agrawal, dev, akhil.goyal
> At present the ipsec xfrom is missing the important step
> to configure the anti replay window size.
> The newly added field will also help in to enable or disable
> the anti replay checking, if available in offload by means
> of non-zero or zero value.
>
> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> ---
> doc/guides/rel_notes/release_19_11.rst | 6 +++++-
> lib/librte_security/Makefile | 2 +-
> lib/librte_security/meson.build | 2 +-
> lib/librte_security/rte_security.h | 4 ++++
> 4 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
> index ae8e7b2f0..0508ec545 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -365,6 +365,10 @@ ABI Changes
> align the Ethernet header on receive and all known encapsulations
> preserve the alignment of the header.
>
> +* security: A new field ''replay_win_sz'' has been added to the structure
> + ``rte_security_ipsec_xform``, which specify the Anti replay window size
> + to enable sequence replay attack handling.
> +
>
> Shared Library Versions
> -----------------------
> @@ -437,7 +441,7 @@ The libraries prepended with a plus sign were incremented in this version.
> librte_reorder.so.1
> librte_ring.so.2
> + librte_sched.so.4
> - librte_security.so.2
> + + librte_security.so.3
> librte_stack.so.1
> librte_table.so.3
> librte_timer.so.1
> diff --git a/lib/librte_security/Makefile b/lib/librte_security/Makefile
> index 6708effdb..6a268ee2a 100644
> --- a/lib/librte_security/Makefile
> +++ b/lib/librte_security/Makefile
> @@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
> LIB = librte_security.a
>
> # library version
> -LIBABIVER := 2
> +LIBABIVER := 3
>
> # build flags
> CFLAGS += -O3
> diff --git a/lib/librte_security/meson.build b/lib/librte_security/meson.build
> index a5130d2f6..6fed01273 100644
> --- a/lib/librte_security/meson.build
> +++ b/lib/librte_security/meson.build
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2017-2019 Intel Corporation
>
> -version = 2
> +version = 3
> sources = files('rte_security.c')
> headers = files('rte_security.h', 'rte_security_driver.h')
> deps += ['mempool', 'cryptodev']
> diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
> index aaafdfcd7..195ad5645 100644
> --- a/lib/librte_security/rte_security.h
> +++ b/lib/librte_security/rte_security.h
> @@ -212,6 +212,10 @@ struct rte_security_ipsec_xform {
> /**< Tunnel parameters, NULL for transport mode */
> uint64_t esn_soft_limit;
> /**< ESN for which the overflow event need to be raised */
> + uint32_t replay_win_sz;
> + /**< Anti replay window size to enable sequence replay attack handling.
> + * replay checking is disabled if the window size is 0.
> + */
> };
>
> /**
> --
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> 2.17.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size
2019-10-31 6:29 0% ` [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size Anoob Joseph
@ 2019-10-31 7:30 0% ` Hemant Agrawal
0 siblings, 0 replies; 200+ results
From: Hemant Agrawal @ 2019-10-31 7:30 UTC (permalink / raw)
To: Anoob Joseph, dev, Akhil Goyal; +Cc: konstantin.ananyev
Hi Anoop,
> -----Original Message-----
> Hi Hemant,
>
> How would the PMD specify whether anit-replay is supported or not? Do you
> have plans to introduce it as a capability? Or do you expect the session
> creation to fail if the feature is not supported by underlying PMD and the anti
> replay window size is set.
[Hemant] We can add it as part of capability set.
I believe following should help:
uint32_t max_replay_win_sz;
Sending it as 0 will indicate the app that replay_win is not support.
>
> Thanks,
> Anoob
>
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Hemant Agrawal
> > Sent: Thursday, October 31, 2019 10:25 AM
> > To: dev@dpdk.org; akhil.goyal@nxp.com
> > Cc: konstantin.ananyev@intel.com; Hemant Agrawal
> > <hemant.agrawal@nxp.com>
> > Subject: [dpdk-dev] [PATCH v4 1/3] security: add anti replay window
> > size
> >
> > At present the ipsec xfrom is missing the important step to configure
> > the anti replay window size.
> > The newly added field will also help in to enable or disable the anti
> > replay checking, if available in offload by means of non-zero or zero value.
> >
> > Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> > ---
> > doc/guides/rel_notes/release_19_11.rst | 6 +++++-
> > lib/librte_security/Makefile | 2 +-
> > lib/librte_security/meson.build | 2 +-
> > lib/librte_security/rte_security.h | 4 ++++
> > 4 files changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/release_19_11.rst
> > b/doc/guides/rel_notes/release_19_11.rst
> > index ae8e7b2f0..0508ec545 100644
> > --- a/doc/guides/rel_notes/release_19_11.rst
> > +++ b/doc/guides/rel_notes/release_19_11.rst
> > @@ -365,6 +365,10 @@ ABI Changes
> > align the Ethernet header on receive and all known encapsulations
> > preserve the alignment of the header.
> >
> > +* security: A new field ''replay_win_sz'' has been added to the
> > +structure
> > + ``rte_security_ipsec_xform``, which specify the Anti replay window
> > +size
> > + to enable sequence replay attack handling.
> > +
> >
> > Shared Library Versions
> > -----------------------
> > @@ -437,7 +441,7 @@ The libraries prepended with a plus sign were
> > incremented in this version.
> > librte_reorder.so.1
> > librte_ring.so.2
> > + librte_sched.so.4
> > - librte_security.so.2
> > + + librte_security.so.3
> > librte_stack.so.1
> > librte_table.so.3
> > librte_timer.so.1
> > diff --git a/lib/librte_security/Makefile
> > b/lib/librte_security/Makefile index 6708effdb..6a268ee2a 100644
> > --- a/lib/librte_security/Makefile
> > +++ b/lib/librte_security/Makefile
> > @@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk LIB =
> > librte_security.a
> >
> > # library version
> > -LIBABIVER := 2
> > +LIBABIVER := 3
> >
> > # build flags
> > CFLAGS += -O3
> > diff --git a/lib/librte_security/meson.build
> > b/lib/librte_security/meson.build index a5130d2f6..6fed01273 100644
> > --- a/lib/librte_security/meson.build
> > +++ b/lib/librte_security/meson.build
> > @@ -1,7 +1,7 @@
> > # SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2017-2019
> > Intel Corporation
> >
> > -version = 2
> > +version = 3
> > sources = files('rte_security.c')
> > headers = files('rte_security.h', 'rte_security_driver.h') deps +=
> > ['mempool', 'cryptodev'] diff --git
> > a/lib/librte_security/rte_security.h
> > b/lib/librte_security/rte_security.h
> > index aaafdfcd7..195ad5645 100644
> > --- a/lib/librte_security/rte_security.h
> > +++ b/lib/librte_security/rte_security.h
> > @@ -212,6 +212,10 @@ struct rte_security_ipsec_xform {
> > /**< Tunnel parameters, NULL for transport mode */
> > uint64_t esn_soft_limit;
> > /**< ESN for which the overflow event need to be raised */
> > + uint32_t replay_win_sz;
> > + /**< Anti replay window size to enable sequence replay attack
> handling.
> > + * replay checking is disabled if the window size is 0.
> > + */
> > };
> >
> > /**
> > --
> > 2.17.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size
2019-10-31 4:54 5% ` [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size Hemant Agrawal
2019-10-31 4:54 5% ` [dpdk-dev] [PATCH v4 2/3] ipsec: remove redundant replay_win_sz Hemant Agrawal
@ 2019-10-31 6:29 0% ` Anoob Joseph
2019-10-31 7:30 0% ` Hemant Agrawal
2019-10-31 10:20 0% ` Ananyev, Konstantin
2019-10-31 13:15 5% ` [dpdk-dev] [PATCH v5 " Hemant Agrawal
3 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2019-10-31 6:29 UTC (permalink / raw)
To: Hemant Agrawal, dev, akhil.goyal; +Cc: konstantin.ananyev
Hi Hemant,
How would the PMD specify whether anit-replay is supported or not? Do you have plans to introduce it as a capability? Or do you expect the session creation to fail if the feature is not supported by underlying PMD and the anti replay window size is set.
Thanks,
Anoob
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Hemant Agrawal
> Sent: Thursday, October 31, 2019 10:25 AM
> To: dev@dpdk.org; akhil.goyal@nxp.com
> Cc: konstantin.ananyev@intel.com; Hemant Agrawal
> <hemant.agrawal@nxp.com>
> Subject: [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size
>
> At present the ipsec xfrom is missing the important step to configure the anti
> replay window size.
> The newly added field will also help in to enable or disable the anti replay
> checking, if available in offload by means of non-zero or zero value.
>
> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> ---
> doc/guides/rel_notes/release_19_11.rst | 6 +++++-
> lib/librte_security/Makefile | 2 +-
> lib/librte_security/meson.build | 2 +-
> lib/librte_security/rte_security.h | 4 ++++
> 4 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_19_11.rst
> b/doc/guides/rel_notes/release_19_11.rst
> index ae8e7b2f0..0508ec545 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -365,6 +365,10 @@ ABI Changes
> align the Ethernet header on receive and all known encapsulations
> preserve the alignment of the header.
>
> +* security: A new field ''replay_win_sz'' has been added to the
> +structure
> + ``rte_security_ipsec_xform``, which specify the Anti replay window
> +size
> + to enable sequence replay attack handling.
> +
>
> Shared Library Versions
> -----------------------
> @@ -437,7 +441,7 @@ The libraries prepended with a plus sign were
> incremented in this version.
> librte_reorder.so.1
> librte_ring.so.2
> + librte_sched.so.4
> - librte_security.so.2
> + + librte_security.so.3
> librte_stack.so.1
> librte_table.so.3
> librte_timer.so.1
> diff --git a/lib/librte_security/Makefile b/lib/librte_security/Makefile index
> 6708effdb..6a268ee2a 100644
> --- a/lib/librte_security/Makefile
> +++ b/lib/librte_security/Makefile
> @@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk LIB = librte_security.a
>
> # library version
> -LIBABIVER := 2
> +LIBABIVER := 3
>
> # build flags
> CFLAGS += -O3
> diff --git a/lib/librte_security/meson.build b/lib/librte_security/meson.build
> index a5130d2f6..6fed01273 100644
> --- a/lib/librte_security/meson.build
> +++ b/lib/librte_security/meson.build
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2017-2019 Intel
> Corporation
>
> -version = 2
> +version = 3
> sources = files('rte_security.c')
> headers = files('rte_security.h', 'rte_security_driver.h') deps += ['mempool',
> 'cryptodev'] diff --git a/lib/librte_security/rte_security.h
> b/lib/librte_security/rte_security.h
> index aaafdfcd7..195ad5645 100644
> --- a/lib/librte_security/rte_security.h
> +++ b/lib/librte_security/rte_security.h
> @@ -212,6 +212,10 @@ struct rte_security_ipsec_xform {
> /**< Tunnel parameters, NULL for transport mode */
> uint64_t esn_soft_limit;
> /**< ESN for which the overflow event need to be raised */
> + uint32_t replay_win_sz;
> + /**< Anti replay window size to enable sequence replay attack handling.
> + * replay checking is disabled if the window size is 0.
> + */
> };
>
> /**
> --
> 2.17.1
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v4 2/3] ipsec: remove redundant replay_win_sz
2019-10-31 4:54 5% ` [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size Hemant Agrawal
@ 2019-10-31 4:54 5% ` Hemant Agrawal
2019-10-31 6:29 0% ` [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size Anoob Joseph
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Hemant Agrawal @ 2019-10-31 4:54 UTC (permalink / raw)
To: dev, akhil.goyal; +Cc: konstantin.ananyev, Hemant Agrawal
The rte_security lib has introduced replay_win_sz,
so it can be removed from the rte_ipsec lib.
Also, the relaved tests,app are also update to reflect
the usages.
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
---
app/test/test_ipsec.c | 2 +-
doc/guides/rel_notes/release_19_11.rst | 7 +++++--
examples/ipsec-secgw/ipsec.c | 1 +
examples/ipsec-secgw/sa.c | 2 +-
lib/librte_ipsec/Makefile | 2 +-
lib/librte_ipsec/meson.build | 1 +
lib/librte_ipsec/rte_ipsec_sa.h | 6 ------
lib/librte_ipsec/sa.c | 4 ++--
8 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
index 4007eff19..7dc83fee7 100644
--- a/app/test/test_ipsec.c
+++ b/app/test/test_ipsec.c
@@ -689,11 +689,11 @@ fill_ipsec_param(uint32_t replay_win_sz, uint64_t flags)
prm->userdata = 1;
prm->flags = flags;
- prm->replay_win_sz = replay_win_sz;
/* setup ipsec xform */
prm->ipsec_xform = ut_params->ipsec_xform;
prm->ipsec_xform.salt = (uint32_t)rte_rand();
+ prm->ipsec_xform.replay_win_sz = replay_win_sz;
/* setup tunnel related fields */
prm->tun.hdr_len = sizeof(ipv4_outer);
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index 0508ec545..ca414edb5 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -365,10 +365,13 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
-* security: A new field ''replay_win_sz'' has been added to the structure
+* security: The field ''replay_win_sz'' has been moved from ipsec library
+ based ''rte_ipsec_sa_prm'' structure to security library based structure
``rte_security_ipsec_xform``, which specify the Anti replay window size
to enable sequence replay attack handling.
+* ipsec: The field ''replay_win_sz'' has been removed from the structure
+ ''rte_ipsec_sa_prm'' as it has been added to the security library.
Shared Library Versions
-----------------------
@@ -411,7 +414,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_gso.so.1
librte_hash.so.2
librte_ip_frag.so.1
- librte_ipsec.so.1
+ + librte_ipsec.so.2
librte_jobstats.so.1
librte_kni.so.2
librte_kvargs.so.1
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 51fb22e8a..159e81f99 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -49,6 +49,7 @@ set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
/* TODO support for Transport */
}
ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
+ ipsec->replay_win_sz = app_sa_prm.window_size;
}
int
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 14ee94731..3d687c459 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -1055,7 +1055,7 @@ fill_ipsec_app_sa_prm(struct rte_ipsec_sa_prm *prm,
prm->flags = app_prm->flags;
prm->ipsec_xform.options.esn = app_prm->enable_esn;
- prm->replay_win_sz = app_prm->window_size;
+ prm->ipsec_xform.replay_win_sz = app_prm->window_size;
}
static int
diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile
index 81fb99980..161ea9e3d 100644
--- a/lib/librte_ipsec/Makefile
+++ b/lib/librte_ipsec/Makefile
@@ -14,7 +14,7 @@ LDLIBS += -lrte_cryptodev -lrte_security -lrte_hash
EXPORT_MAP := rte_ipsec_version.map
-LIBABIVER := 1
+LIBABIVER := 2
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) += esp_inb.c
diff --git a/lib/librte_ipsec/meson.build b/lib/librte_ipsec/meson.build
index 70358526b..e8604dadd 100644
--- a/lib/librte_ipsec/meson.build
+++ b/lib/librte_ipsec/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2018 Intel Corporation
+version = 2
allow_experimental_apis = true
sources = files('esp_inb.c', 'esp_outb.c', 'sa.c', 'ses.c', 'ipsec_sad.c')
diff --git a/lib/librte_ipsec/rte_ipsec_sa.h b/lib/librte_ipsec/rte_ipsec_sa.h
index 47ce169d2..1cfde5874 100644
--- a/lib/librte_ipsec/rte_ipsec_sa.h
+++ b/lib/librte_ipsec/rte_ipsec_sa.h
@@ -47,12 +47,6 @@ struct rte_ipsec_sa_prm {
uint8_t proto; /**< next header protocol */
} trs; /**< transport mode related parameters */
};
-
- /**
- * window size to enable sequence replay attack handling.
- * replay checking is disabled if the window size is 0.
- */
- uint32_t replay_win_sz;
};
/**
diff --git a/lib/librte_ipsec/sa.c b/lib/librte_ipsec/sa.c
index 23d394b46..6f1d92c3c 100644
--- a/lib/librte_ipsec/sa.c
+++ b/lib/librte_ipsec/sa.c
@@ -439,7 +439,7 @@ rte_ipsec_sa_size(const struct rte_ipsec_sa_prm *prm)
return rc;
/* determine required size */
- wsz = prm->replay_win_sz;
+ wsz = prm->ipsec_xform.replay_win_sz;
return ipsec_sa_size(type, &wsz, &nb);
}
@@ -461,7 +461,7 @@ rte_ipsec_sa_init(struct rte_ipsec_sa *sa, const struct rte_ipsec_sa_prm *prm,
return rc;
/* determine required size */
- wsz = prm->replay_win_sz;
+ wsz = prm->ipsec_xform.replay_win_sz;
sz = ipsec_sa_size(type, &wsz, &nb);
if (sz < 0)
return sz;
--
2.17.1
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size
2019-10-30 8:57 5% ` [dpdk-dev] [PATCH v3 2/2] ipsec: remove redundant replay_win_sz Hemant Agrawal
@ 2019-10-31 4:54 5% ` Hemant Agrawal
2019-10-31 4:54 5% ` [dpdk-dev] [PATCH v4 2/3] ipsec: remove redundant replay_win_sz Hemant Agrawal
` (3 more replies)
1 sibling, 4 replies; 200+ results
From: Hemant Agrawal @ 2019-10-31 4:54 UTC (permalink / raw)
To: dev, akhil.goyal; +Cc: konstantin.ananyev, Hemant Agrawal
At present the ipsec xfrom is missing the important step
to configure the anti replay window size.
The newly added field will also help in to enable or disable
the anti replay checking, if available in offload by means
of non-zero or zero value.
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
---
doc/guides/rel_notes/release_19_11.rst | 6 +++++-
lib/librte_security/Makefile | 2 +-
lib/librte_security/meson.build | 2 +-
lib/librte_security/rte_security.h | 4 ++++
4 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index ae8e7b2f0..0508ec545 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -365,6 +365,10 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
+* security: A new field ''replay_win_sz'' has been added to the structure
+ ``rte_security_ipsec_xform``, which specify the Anti replay window size
+ to enable sequence replay attack handling.
+
Shared Library Versions
-----------------------
@@ -437,7 +441,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_reorder.so.1
librte_ring.so.2
+ librte_sched.so.4
- librte_security.so.2
+ + librte_security.so.3
librte_stack.so.1
librte_table.so.3
librte_timer.so.1
diff --git a/lib/librte_security/Makefile b/lib/librte_security/Makefile
index 6708effdb..6a268ee2a 100644
--- a/lib/librte_security/Makefile
+++ b/lib/librte_security/Makefile
@@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_security.a
# library version
-LIBABIVER := 2
+LIBABIVER := 3
# build flags
CFLAGS += -O3
diff --git a/lib/librte_security/meson.build b/lib/librte_security/meson.build
index a5130d2f6..6fed01273 100644
--- a/lib/librte_security/meson.build
+++ b/lib/librte_security/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017-2019 Intel Corporation
-version = 2
+version = 3
sources = files('rte_security.c')
headers = files('rte_security.h', 'rte_security_driver.h')
deps += ['mempool', 'cryptodev']
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index aaafdfcd7..195ad5645 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -212,6 +212,10 @@ struct rte_security_ipsec_xform {
/**< Tunnel parameters, NULL for transport mode */
uint64_t esn_soft_limit;
/**< ESN for which the overflow event need to be raised */
+ uint32_t replay_win_sz;
+ /**< Anti replay window size to enable sequence replay attack handling.
+ * replay checking is disabled if the window size is 0.
+ */
};
/**
--
2.17.1
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from host
2019-10-29 18:50 3% ` [dpdk-dev] [PATCH v2 0/3] " Thomas Monjalon
2019-10-30 4:08 0% ` Jerin Jacob
@ 2019-10-30 15:07 0% ` Ilya Maximets
1 sibling, 0 replies; 200+ results
From: Ilya Maximets @ 2019-10-30 15:07 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Shahaf Shuler, Jerin Jacob, Andrew Rybchenko, Ferruh Yigit,
Stephen Hemminger
On 29.10.2019 19:50, Thomas Monjalon wrote:
> In a virtual environment, the network controller may have to configure
> some SR-IOV VF parameters for security reasons.
>
> When the PF (host port) is driven by DPDK (OVS-DPDK case),
> we face two different cases:
> - driver is bifurcated (Mellanox case),
> so the VF can be configured via the kernel.
> - driver is on top of UIO or VFIO, so DPDK API is required,
> and PMD-specific APIs were used.
So, what is wrong with setting VF mac via the representor port as
it done now? From our previous discussion, I thought that we concluded
that is enough to have current API, i.e. just call set_default_mac()
for a representor port and this will lead to setting mac for VF.
This is how it's implemented in Linux kernel and this is how it's
implemented in current DPDK drivers that supports setting mac for
the representor.
The only use case for this new API is to be able to control mac of
the representor itself, which doesn't make much sense. At least there
are only hypothetical use cases. And once again, Linux kernel doesn't
support this behavior.
> This new generic API will avoid vendors fragmentation.
I don't see the fragmentation. Right now you can set VF mac from DPDK
by calling set_default_mac() for representor. This API exists for all
vendors. Not implemented for Intel, but new API is not implemented too.
The this is that this new API will produce conceptual fragmentation
between DPDK and the Linux kernel, because to do the same thing you'll
have to use different ways. I mean, to change mac of VF in kernel you
need to set mac to the representor, but in DPDK changing setting mac to
representor will lead to changing the mac of the representor itself,
not the VF. This will be really confusing for users.
>
> Some PMD-specific API could migrate to this generic model.
> As an example, the default MAC address configuration is demonstrated
> for a VF mapped to mlx5 representor port.
>
> As it breaks the ABI, I propose to merge this API in DPDK 19.11-rc2.
>
> I am sorry I had not send a patch since proposing a RFC in August.
> (I gave priority to the summit and the -rc1 release)
>
>
> Thomas Monjalon (3):
> ethdev: identify SR-IOV VF from host
> ethdev: set VF MAC address from host
> net/mlx5: set VF MAC address from host
>
> drivers/net/mlx5/mlx5.c | 6 +++
> drivers/net/mlx5/mlx5.h | 1 +
> drivers/net/mlx5/mlx5_mac.c | 19 ++++++++
> lib/librte_ethdev/rte_ethdev.c | 55 +++++++++++++++++++++---
> lib/librte_ethdev/rte_ethdev.h | 38 ++++++++++++++++
> lib/librte_ethdev/rte_ethdev_core.h | 1 +
> lib/librte_ethdev/rte_ethdev_version.map | 1 +
> 7 files changed, 114 insertions(+), 7 deletions(-)
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH 1/9] security: introduce CPU Crypto action type and API
@ 2019-10-30 14:23 0% ` Ananyev, Konstantin
2019-11-01 13:53 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2019-10-30 14:23 UTC (permalink / raw)
To: Akhil Goyal, 'dev@dpdk.org',
De Lara Guarch, Pablo, 'Thomas Monjalon',
Zhang, Roy Fan, Doherty, Declan
Cc: 'Anoob Joseph', Hemant Agrawal
Hi Akhil,
> > > > > Added my comments inline with your draft.
> > > > > [snip]..
> > > > >
> > > > > >
> > > > > > Ok, then my suggestion:
> > > > > > Let's at least write down all points about crypto-dev approach where we
> > > > > > disagree and then probably try to resolve them one by one....
> > > > > > If we fail to make an agreement/progress in next week or so,
> > > > > > (and no more reviews from the community)
> > > > > > will have bring that subject to TB meeting to decide.
> > > > > > Sounds fair to you?
> > > > > Agreed
> > > > > >
> > > > > > List is below.
> > > > > > Please add/correct me, if I missed something.
> > > > > >
> > > > > > Konstantin
> > > > >
> > > > > Before going into comparison, we should define the requirement as well.
> > > >
> > > > Good point.
> > > >
> > > > > What I understood from the patchset,
> > > > > "You need a synchronous API to perform crypto operations on raw data
> > using
> > > > SW PMDs"
> > > > > So,
> > > > > - no crypto-ops,
> > > > > - no separate enq-deq, only single process API for data path
> > > > > - Do not need any value addition to the session parameters.
> > > > > (You would need some parameters from the crypto-op which
> > > > > Are constant per session and since you wont use crypto-op,
> > > > > You need some place to store that)
> > > >
> > > > Yes, this is correct, I think.
> > > >
> > > > >
> > > > > Now as per your mail, the comparison
> > > > > 1. extra input parameters to create/init rte_(cpu)_sym_session.
> > > > >
> > > > > Will leverage existing 6B gap inside rte_crypto_*_xform between 'algo'
> > and
> > > > 'key' fields.
> > > > > New fields will be optional and would be used by PMD only when cpu-
> > crypto
> > > > session is requested.
> > > > > For lksd-crypto session PMD is free to ignore these fields.
> > > > > No ABI breakage is required.
> > > > >
> > > > > [Akhil] Agreed, no issues.
> > > > >
> > > > > 2. cpu-crypto create/init.
> > > > > a) Our suggestion - introduce new API for that:
> > > > > - rte_crypto_cpu_sym_init() that would init completely opaque
> > > > rte_crypto_cpu_sym_session.
> > > > > - struct rte_crypto_cpu_sym_session_ops {(*process)(...); (*clear);
> > > > /*whatever else we'll need *'};
> > > > > - rte_crypto_cpu_sym_get_ops(const struct rte_crypto_sym_xform
> > > > *xforms)
> > > > > that would return const struct rte_crypto_cpu_sym_session_ops
> > *based
> > > > on input xforms.
> > > > > Advantages:
> > > > > 1) totally opaque data structure (no ABI breakages in future), PMD
> > > > writer is totally free
> > > > > with it format and contents.
> > > > >
> > > > > [Akhil] It will have breakage at some point till we don't hit the union size.
> > > >
> > > > Not sure, what union you are talking about?
> > >
> > > Union of xforms in rte_security_session_conf
> >
> > Hmm, how does it relates here?
> > I thought we discussing pure rte_cryptodev_sym_session, no?
> >
> > >
> > > >
> > > > > Rather I don't suspect there will be more parameters added.
> > > > > Or do we really care about the ABI breakage when the argument is about
> > > > > the correct place to add a piece of code or do we really agree to add code
> > > > > anywhere just to avoid that breakage.
> > > >
> > > > I am talking about maintaining it in future.
> > > > if your struct is not seen externally, no chances to introduce ABI breakage.
> > > >
> > > > >
> > > > > 2) each session entity is self-contained, user doesn't need to bring along
> > > > dev_id etc.
> > > > > dev_id is needed only at init stage, after that user will use session ops
> > > > to perform
> > > > > all operations on that session (process(), clear(), etc.).
> > > > >
> > > > > [Akhil] There is nothing called as session ops in current DPDK.
> > > >
> > > > True, but it doesn't mean we can't/shouldn't have it.
> > >
> > > We can have it if it is not adding complexity for the user. Creating 2 different
> > code
> > > Paths for user is not desirable for the stack developers.
> > >
> > > >
> > > > > What you are proposing
> > > > > is a new concept which doesn't have any extra benefit, rather it is adding
> > > > complexity
> > > > > to have two different code paths for session create.
> > > > >
> > > > >
> > > > > 3) User can decide does he wants to store ops[] pointer on a per session
> > > > basis,
> > > > > or on a per group of same sessions, or...
> > > > >
> > > > > [Akhil] Will the user really care which process API should be called from the
> > > > PMD.
> > > > > Rather it should be driver's responsibility to store that in the session private
> > > > data
> > > > > which would be opaque to the user. As per my suggestion same process
> > > > function can
> > > > > be added to multiple sessions or a single session can be managed inside the
> > > > PMD.
> > > >
> > > > In that case we either need to have a function per session (stored internally),
> > > > or make decision (branches) at run-time.
> > > > But as I said in other mail - I am ok to add small shim structure here:
> > > > either rte_crypto_cpu_sym_session { void *ses; struct
> > > > rte_crypto_cpu_sym_session_ops ops; }
> > > > or rte_crypto_cpu_sym_session { void *ses; struct
> > > > rte_crypto_cpu_sym_session_ops *ops; }
> > > > And merge rte_crypto_cpu_sym_init() and rte_crypto_cpu_sym_get_ops()
> > into
> > > > one (init).
> > >
> > > Again that will be a separate API call from the user perspective which is not
> > good.
> > >
> > > >
> > > > >
> > > > >
> > > > > 4) No mandatory mempools for private sessions. User can allocate
> > > > memory for cpu-crypto
> > > > > session whenever he likes.
> > > > >
> > > > > [Akhil] you mean session private data?
> > > >
> > > > Yes.
> > > >
> > > > > You would need that memory anyways, user will be
> > > > > allocating that already. You do not need to manage that.
> > > >
> > > > What I am saying - right now user has no choice but to allocate it via
> > mempool.
> > > > Which is probably not the best options for all cases.
> > > >
> > > > >
> > > > > Disadvantages:
> > > > > 5) Extra changes in control path
> > > > > 6) User has to store session_ops pointer explicitly.
> > > > >
> > > > > [Akhil] More disadvantages:
> > > > > - All supporting PMDs will need to maintain TWO types of session for the
> > > > > same crypto processing. Suppose a fix or a new feature(or algo) is added,
> > PMD
> > > > owner
> > > > > will need to add code in both the session create APIs. Hence more
> > > > maintenance and
> > > > > error prone.
> > > >
> > > > I think majority of code for both paths will be common, plus even we'll reuse
> > > > current sym_session_init() -
> > > > changes in PMD session_init() code will be unavoidable.
> > > > But yes, it will be new entry in devops, that PMD will have to support.
> > > > Ok to add it as 7) to the list.
> > > >
> > > > > - Stacks which will be using these new APIs also need to maintain two
> > > > > code path for the same processing while doing session initialization
> > > > > for sync and async
> > > >
> > > > That's the same as #5 above, I think.
> > > >
> > > > >
> > > > >
> > > > > b) Your suggestion - reuse existing rte_cryptodev_sym_session_init() and
> > > > existing rte_cryptodev_sym_session
> > > > > structure.
> > > > > Advantages:
> > > > > 1) allows to reuse same struct and init/create/clear() functions.
> > > > > Probably less changes in control path.
> > > > > Disadvantages:
> > > > > 2) rte_cryptodev_sym_session. sess_data[] is indexed by driver_id,
> > > > which means that
> > > > > we can't use the same rte_cryptodev_sym_session to hold private
> > > > sessions pointers
> > > > > for both sync and async mode for the same device.
> > > > > So the only option we have - make PMD devops-
> > > > >sym_session_configure()
> > > > > always create a session that can work in both cpu and lksd modes.
> > > > > For some implementations that would probably mean that under the
> > > > hood PMD would create
> > > > > 2 different session structs (sync/async) and then use one or another
> > > > depending on from what API been called.
> > > > > Seems doable, but ...:
> > > > > - will contradict with statement from 1:
> > > > > " New fields will be optional and would be used by PMD only when
> > > > cpu-crypto session is requested."
> > > > > Now it becomes mandatory for all apps to specify cpu-crypto
> > > > related parameters too,
> > > > > even if they don't plan to use that mode - i.e. behavior change,
> > > > existing app change.
> > > > > - might cause extra space overhead.
> > > > >
> > > > > [Akhil] It will not contradict with #1, you will only have few checks in the
> > > > session init PMD
> > > > > Which support this mode, find appropriate values and set the appropriate
> > > > process() in it.
> > > > > User should be able to call, legacy enq-deq as well as the new process()
> > > > without any issue.
> > > > > User would be at runtime will be able to change the datapath.
> > > > > So this is not a disadvantage, it would be additional flexibility for the user.
> > > >
> > > > Ok, but that's what I am saying - if PMD would *always* have to create a
> > > > session that can handle
> > > > both modes (sync/async), then user would *always* have to provide
> > parameters
> > > > for both modes too.
> > > > Otherwise if let say user didn't setup sync specific parameters at all, what
> > PMD
> > > > should do?
> > > > - return with error?
> > > > - init session that can be used with async path only?
> > > > My current assumption is #1.
> > > > If #2, then how user will be able to distinguish is that session valid for both
> > > > modes, or only for one?
> > >
> > > I would say a 3rd option, do nothing if sync params are not set.
> > > Probably have a debug print in the PMD(which support sync mode) to specify
> > that
> > > session is not configured properly for sync mode.
> >
> > So, just print warning and proceed with init session that can be used with async
> > path only?
> > Then it sounds the same as #2 above.
> > Which actually means that sync mode parameters for sym_session_init()
> > becomes optional.
> > Then we need an API to provide to the user information what modes
> > (sync+async/async only) is supported by that session for given dev_id.
> > And user would have to query/retain this information at control-path,
> > and store it somewhere in user-space together with session pointer and dev_ids
> > to use later at data-path (same as we do now for session type).
> > That definitely requires changes in control-path to start using it.
> > Plus the fact that this value can differ for different dev_ids for the same session -
> > doesn't make things easier here.
>
> API wont be required to specify that. Feature flag will be sufficient, not a big change
> From the application perspective.
>
> Here is some pseudo code just to elaborate my understanding. This will need some
>
> From application,
> If(dev_info->feature_flags & RTE_CRYPTODEV_FF_SYNC) {
> /* set additional params in crypto xform */
> }
>
> Now in the driver,
> pmd_sym_session_configure(dev,xform,sess,mempool) {
> ...
> If(dev_info->feature_flags & RTE_CRYPTODEV_FF_SYNC
> && xform->/*sync params are set*/) {
> /*Assign process function pointer in sess->priv_data*/
> } /* It may return error if FF_SYNC is set and params are not correct.
Then all apps will always *have to* setup sync parameters in xform.
What you suggest is *mandatory* sync mode: user always has to setup sync
mode params if PMD does support it (no matter does he plan to use sync mode or not).
Which means behavior change in existing apps.
> It would be upto the driver whether it support both SYNC and ASYNC.*/
> }
>
> Now the new sync API
>
> pmd_process(...) {
> If(dev_info->feature_flags & RTE_CRYPTODEV_FF_SYNC
> && sess_priv->process != NULL)
> sess_priv->process(...);
> else
> ASSERT("sync mode not configured properly or not supported");
> }
>
> In the data path, there is no extra processing happening.
> Even in case of your suggestion, you should have these type of error checks,
> You cannot blindly trust on the application that the pointers are correct.
>
> >
> > > Internally the PMD will not store the process() API in the session priv data
> > > And while calling the first packet, devops->process will give an assert that
> > session
> > > Is not configured for sync mode. The session validation would be done in any
> > case
> > > your suggestion or mine. So no extra overhead at runtime.
> >
> > I believe that after session_init() user should get either an error or
> > valid session handler that he can use at runtime.
> > Pushing session validation to runtime doesn't seem like a good idea.
> >
> It may get a warning from the PMD, that FF_SYNC is set but params are not
> Correct/available. See above.
I think warning is not enough.
There should be a clear way (API) for developer to realize is the created session
can be used by sync API data-path or not.
>
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > 3) not possible to store device (not driver) specific data within the
> > > > session, but I think it is not really needed right now.
> > > > > So probably minor compared to 2.b.2.
> > > > >
> > > > > [Akhil] So lets omit this for current discussion. And I hope we can find some
> > > > way to deal with it.
> > > >
> > > > I don't think there is an easy way to fix that with existing API.
> > > >
> > > > >
> > > > >
> > > > > Actually #3 follows from #2, but decided to have them separated.
> > > > >
> > > > > 3. process() parameters/behavior
> > > > > a) Our suggestion: user stores ptr to session ops (or to (*process) itself)
> > and
> > > > just does:
> > > > > session_ops->process(sess, ...);
> > > > > Advantages:
> > > > > 1) fastest possible execution path
> > > > > 2) no need to carry on dev_id for data-path
> > > > >
> > > > > [Akhil] I don't see any overhead of carrying dev id, at least it would be
> > inline
> > > > with the
> > > > > current DPDK methodology.
> > > >
> > > > If we'll add process() into rte_cryptodev itself (same as we have
> > > > enqueue_burst/dequeue_burst),
> > > > then it will be an ABI breakage.
> > > > Also there are discussions to get rid of that approach completely:
> > > >
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails.dpd
> > k.org%2Farchives%2Fdev%2F2019-
> > September%2F144674.html&data=02%7C01%7Cakhil.goyal%40nxp.com%7
> > C1859dc1d29cd45a51e9908d7571784bb%7C686ea1d3bc2b4c6fa92cd99c5c301
> > 635%7C0%7C0%7C637073630835415165&sdata=Bz9jgisyVzRJNt1BijtvSlurh
> > JU1vXBbynNwlMDjaco%3D&reserved=0
> > > > So I am not sure this is a recommended way these days.
> > >
> > > We can either have it in rte_cryptodev or in rte_cryptodev_ops whichever
> > > is good for you.
> > >
> > > Whether it is ABI breakage or not, as per your requirements, this is the correct
> > > approach. Do you agree with this or not?
> >
> > I think it is possible approach, but not the best one:
> > it looks quite flakey to me (see all these uncertainty with sym_session_init
> > above),
> > plus introduces extra overhead at data-path.
>
> Uncertainties can be handled appropriately using a feature flag
>
> >
> > >
> > > Now handling the API/ABI breakage is a separate story. In 19.11 release we
> > > Are not much concerned about the ABI breakages, this was discussed in
> > > community. So adding a new dev_ops wouldn't have been an issue.
> > > Now since we are so close to RC1 deadline, we should come up with some
> > > other solution for next release. May be having a pmd API in 20.02 and
> > > converting it into formal one in 20.11
> > >
> > >
> > > >
> > > > > What you are suggesting is a new way to get the things done without much
> > > > benefit.
> > > >
> > > > Would help with ABI stability plus better performance, isn't it enough?
> > > >
> > > > > Also I don't see any performance difference as crypto workload is heavier
> > than
> > > > > Code cycles, so that wont matter.
> > > >
> > > > It depends.
> > > > Suppose function call costs you ~30 cycles.
> > > > If you have burst of big packets (let say crypto for each will take ~2K cycles)
> > that
> > > > belong
> > > > to the same session, then yes you wouldn't notice these extra 30 cycles at all.
> > > > If you have burst of small packets (let say crypto for each will take ~300
> > cycles)
> > > > each
> > > > belongs to different session, then it will cost you ~10% extra.
> > >
> > > Let us do some profiling on openssl with both the approaches and find out the
> > > difference.
> > >
> > > >
> > > > > So IMO, there is no advantage in your suggestion as well.
> > > > >
> > > > >
> > > > > Disadvantages:
> > > > > 3) user has to carry on session_ops pointer explicitly
> > > > > b) Your suggestion: add (*cpu_process) inside rte_cryptodev_ops and
> > then:
> > > > > rte_crypto_cpu_sym_process(uint8_t dev_id,
> > rte_cryptodev_sym_session
> > > > *sess, /*data parameters*/) {...
> > > > > rte_cryptodevs[dev_id].dev_ops->cpu_process(ses, ...);
> > > > > /*and then inside PMD specifc process: */
> > > > > pmd_private_session = sess-
> > >sess_data[this_pmd_driver_id].data;
> > > > > /* and then most likely either */
> > > > > pmd_private_session->process(pmd_private_session, ...);
> > > > > /* or jump based on session/input data */
> > > > > Advantages:
> > > > > 1) don't see any...
> > > > > Disadvantages:
> > > > > 2) User has to carry on dev_id inside data-path
> > > > > 3) Extra level of indirection (plus data dependency) - both for data and
> > > > instructions.
> > > > > Possible slowdown compared to a) (not measured).
> > > > >
> > > > > Having said all this, if the disagreements cannot be resolved, you can go
> > for a
> > > > pmd API specific
> > > > > to your PMDs,
> > > >
> > > > I don't think it is good idea.
> > > > PMD specific API is sort of deprecated path, also there is no clean way to use
> > it
> > > > within the libraries.
> > >
> > > I know that this is a deprecated path, we can use it until we are not allowed
> > > to break ABI/API
> > >
> > > >
> > > > > because as per my understanding the solution doesn't look scalable to
> > other
> > > > PMDs.
> > > > > Your approach is aligned only to Intel , will not benefit others like openssl
> > > > which is used by all
> > > > > vendors.
> > > >
> > > > I feel quite opposite, from my perspective majority of SW backed PMDs will
> > > > benefit from it.
> > > > And I don't see anything Intel specific in my proposals above.
> > > > About openssl PMD: I am not an expert here, but looking at the code, I think
> > it
> > > > will fit really well.
> > > > Look yourself at its internal functions:
> > > > process_openssl_auth_op/process_openssl_crypto_op,
> > > > I think they doing exactly the same - they use sync API underneath, and they
> > are
> > > > session based
> > > > (AFAIK you don't need any device/queue data, everything that needed for
> > > > crypto/auth is stored inside session).
> > > >
> > > By vendor specific, I mean,
> > > - no PMD would like to have 2 different variants of session Init APIs for doing
> > the same stuff.
> > > - stacks will become vendor specific while using 2 separate session create APIs.
> > No stack would
> > > Like to support 2 variants of session create- one for HW PMDs and one for SW
> > PMDs.
> >
> > I think what you refer on has nothing to do with 'vendor specific'.
> > I would name it 'extra overhead for PMD and stack writers'.
> > Yes, for sure there is extra overhead (as always with new API) -
> > for both producer (PMD writer) and consumer (stack writer):
> > New function(s) to support, probably more tests to create/run, etc.
> > Though this API is optional - if PMD/stack maintainer doesn't see
> > value in it, they are free not to support it.
> > From other side, re-using rte_cryptodev_sym_session_init()
> > wouldn't help anyway - both data-path and control-path would differ
> > from async mode anyway.
> > BTW, right now to support different HW flavors
> > we do have 4 different control and data-paths for both
> > ipsec-secgw and librte_ipsec:
> > lkds-none/lksd-proto/inline-crypto/inline-proto.
> > And that is considered to be ok.
>
> No that is not ok. We cannot add new paths for every other case.
What I am saying: if let-say lookaside-proto/inline-crypto/inline-proto
deserves its own case in rte_security/rte_crypto API,
I don't understand why cpu-crypto doesn't.
> Those 4 are controlled using 2 set of APIs.
Yes there are 2 API sets (rte_cryptodev/rte_security),
but in fact if you look at ipsec-secgw and librte_ipsec we have 4 different code paths.
For both create_session() and ipsec_enqueue() we have a big switch() with 4 different cases.
Nearly the same for librte_ipsec - we have different prepare/process
function pointers for each security type.
> We should try our best to
> Have minimum overhead to the application writer. This pain was also discussed
> In the one of DPDK conference as well.
> DPDK is not a standalone entity, there are stacks running over it always.
> We should not add API for every other use case when we have an alternative
> Approach with the existing API set.
>
> Now introducing another one would add to that pain and a lot of work for
> Both producer and consumer.
If I would see a clean approach to implement desired functionality
without introducing new API - I would definitely support it.
The problem is that from my perspective,
what you suggesting with existing API will bring more drawbacks then positives.
BTW, our first approach (via rte_security) does reuse existing API,
so if adding new API is the main concern - let's reconsider that path.
> It would be interesting to see how much performance difference will be there in the
> Two approaches. As per my understanding it wont be much as compared to the
> Extra work that you will be inducing.
>
> -Akhil
>
> > Honestly, I don't understand why SW backed implementations
> > can't have their own path that would suite them most.
> > Konstantin
> >
> >
> >
> >
> >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 2/2] ipsec: remove redundant replay_win_sz
2019-10-30 8:57 5% ` [dpdk-dev] [PATCH v3 2/2] ipsec: remove redundant replay_win_sz Hemant Agrawal
@ 2019-10-30 13:08 0% ` Ananyev, Konstantin
0 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2019-10-30 13:08 UTC (permalink / raw)
To: Hemant Agrawal, dev, akhil.goyal
Hi Hemant,
> The rte_security lib has introduced replay_win_sz,
> so it can be removed from the rte_ipsec lib.
>
> Also, the relaved tests,app are also update to reflect
> the usages.
>
> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> ---
> v3: fix the compilation issue
>
> app/test/test_ipsec.c | 2 +-
> doc/guides/rel_notes/release_19_11.rst | 10 ++++++++--
> examples/ipsec-secgw/ipsec.c | 1 +
> examples/ipsec-secgw/sa.c | 2 +-
> lib/librte_ipsec/Makefile | 2 +-
> lib/librte_ipsec/meson.build | 1 +
> lib/librte_ipsec/rte_ipsec_sa.h | 6 ------
> lib/librte_ipsec/sa.c | 4 ++--
> 8 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
> index 4007eff19..9e3dabd93 100644
> --- a/app/test/test_ipsec.c
> +++ b/app/test/test_ipsec.c
> @@ -689,7 +689,7 @@ fill_ipsec_param(uint32_t replay_win_sz, uint64_t flags)
>
> prm->userdata = 1;
> prm->flags = flags;
> - prm->replay_win_sz = replay_win_sz;
> + prm->ipsec_xform.replay_win_sz = replay_win_sz;
We need to do it later - as on the next line (see below),
we'll overwrite whole ipsec_xform.
>
> /* setup ipsec xform */
> prm->ipsec_xform = ut_params->ipsec_xform;
diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
index 9e3dabd93..7dc83fee7 100644
--- a/app/test/test_ipsec.c
+++ b/app/test/test_ipsec.c
@@ -689,11 +689,11 @@ fill_ipsec_param(uint32_t replay_win_sz, uint64_t flags)
prm->userdata = 1;
prm->flags = flags;
- prm->ipsec_xform.replay_win_sz = replay_win_sz;
/* setup ipsec xform */
prm->ipsec_xform = ut_params->ipsec_xform;
prm->ipsec_xform.salt = (uint32_t)rte_rand();
+ prm->ipsec_xform.replay_win_sz = replay_win_sz;
/* setup tunnel related fields */
prm->tun.hdr_len = sizeof(ipv4_outer);
> diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
> index ae8e7b2f0..aa16c8422 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -365,6 +365,12 @@ ABI Changes
> align the Ethernet header on receive and all known encapsulations
> preserve the alignment of the header.
>
> +* security: A new field ''replay_win_sz'' has been added to the structure
> + ``rte_security_ipsec_xform``, which specify the Anti replay window size
> + to enable sequence replay attack handling.
> +
> +* ipsec: The field ''replay_win_sz'' has been removed from the structure
> + ''rte_ipsec_sa_prm'' as it has been added to the security library.
>
> Shared Library Versions
> -----------------------
> @@ -407,7 +413,7 @@ The libraries prepended with a plus sign were incremented in this version.
> librte_gso.so.1
> librte_hash.so.2
> librte_ip_frag.so.1
> - librte_ipsec.so.1
> + + librte_ipsec.so.2
> librte_jobstats.so.1
> librte_kni.so.2
> librte_kvargs.so.1
> @@ -437,7 +443,7 @@ The libraries prepended with a plus sign were incremented in this version.
> librte_reorder.so.1
> librte_ring.so.2
> + librte_sched.so.4
> - librte_security.so.2
> + + librte_security.so.3
> librte_stack.so.1
> librte_table.so.3
> librte_timer.so.1
> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> index 51fb22e8a..159e81f99 100644
> --- a/examples/ipsec-secgw/ipsec.c
> +++ b/examples/ipsec-secgw/ipsec.c
> @@ -49,6 +49,7 @@ set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
> /* TODO support for Transport */
> }
> ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
> + ipsec->replay_win_sz = app_sa_prm.window_size;
> }
>
> int
> diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
> index 14ee94731..3d687c459 100644
> --- a/examples/ipsec-secgw/sa.c
> +++ b/examples/ipsec-secgw/sa.c
> @@ -1055,7 +1055,7 @@ fill_ipsec_app_sa_prm(struct rte_ipsec_sa_prm *prm,
>
> prm->flags = app_prm->flags;
> prm->ipsec_xform.options.esn = app_prm->enable_esn;
> - prm->replay_win_sz = app_prm->window_size;
> + prm->ipsec_xform.replay_win_sz = app_prm->window_size;
> }
>
> static int
> diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile
> index 81fb99980..161ea9e3d 100644
> --- a/lib/librte_ipsec/Makefile
> +++ b/lib/librte_ipsec/Makefile
> @@ -14,7 +14,7 @@ LDLIBS += -lrte_cryptodev -lrte_security -lrte_hash
>
> EXPORT_MAP := rte_ipsec_version.map
>
> -LIBABIVER := 1
> +LIBABIVER := 2
>
> # all source are stored in SRCS-y
> SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) += esp_inb.c
> diff --git a/lib/librte_ipsec/meson.build b/lib/librte_ipsec/meson.build
> index 70358526b..e8604dadd 100644
> --- a/lib/librte_ipsec/meson.build
> +++ b/lib/librte_ipsec/meson.build
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2018 Intel Corporation
>
> +version = 2
> allow_experimental_apis = true
>
> sources = files('esp_inb.c', 'esp_outb.c', 'sa.c', 'ses.c', 'ipsec_sad.c')
> diff --git a/lib/librte_ipsec/rte_ipsec_sa.h b/lib/librte_ipsec/rte_ipsec_sa.h
> index 47ce169d2..1cfde5874 100644
> --- a/lib/librte_ipsec/rte_ipsec_sa.h
> +++ b/lib/librte_ipsec/rte_ipsec_sa.h
> @@ -47,12 +47,6 @@ struct rte_ipsec_sa_prm {
> uint8_t proto; /**< next header protocol */
> } trs; /**< transport mode related parameters */
> };
> -
> - /**
> - * window size to enable sequence replay attack handling.
> - * replay checking is disabled if the window size is 0.
> - */
> - uint32_t replay_win_sz;
> };
>
> /**
> diff --git a/lib/librte_ipsec/sa.c b/lib/librte_ipsec/sa.c
> index 23d394b46..6f1d92c3c 100644
> --- a/lib/librte_ipsec/sa.c
> +++ b/lib/librte_ipsec/sa.c
> @@ -439,7 +439,7 @@ rte_ipsec_sa_size(const struct rte_ipsec_sa_prm *prm)
> return rc;
>
> /* determine required size */
> - wsz = prm->replay_win_sz;
> + wsz = prm->ipsec_xform.replay_win_sz;
> return ipsec_sa_size(type, &wsz, &nb);
> }
>
> @@ -461,7 +461,7 @@ rte_ipsec_sa_init(struct rte_ipsec_sa *sa, const struct rte_ipsec_sa_prm *prm,
> return rc;
>
> /* determine required size */
> - wsz = prm->replay_win_sz;
> + wsz = prm->ipsec_xform.replay_win_sz;
> sz = ipsec_sa_size(type, &wsz, &nb);
> if (sz < 0)
> return sz;
> --
> 2.17.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
2019-10-30 9:20 0% ` Andrew Rybchenko
@ 2019-10-30 10:05 0% ` Slava Ovsiienko
0 siblings, 0 replies; 200+ results
From: Slava Ovsiienko @ 2019-10-30 10:05 UTC (permalink / raw)
To: Andrew Rybchenko, Thomas Monjalon, olivier.matz
Cc: dev, Matan Azrad, Ori Kam, Yongseok Koh
> -----Original Message-----
> From: Andrew Rybchenko <arybchenko@solarflare.com>
> Sent: Wednesday, October 30, 2019 11:20
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Thomas Monjalon
> <thomas@monjalon.net>; olivier.matz@6wind.com
> Cc: dev@dpdk.org; Matan Azrad <matan@mellanox.com>; Ori Kam
> <orika@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
>
> On 10/30/19 11:59 AM, Slava Ovsiienko wrote:
> >> -----Original Message-----
> >> From: Andrew Rybchenko <arybchenko@solarflare.com>
> >> Sent: Wednesday, October 30, 2019 9:35
> >> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Thomas Monjalon
> >> <thomas@monjalon.net>; olivier.matz@6wind.com
> >> Cc: dev@dpdk.org; Matan Azrad <matan@mellanox.com>; Ori Kam
> >> <orika@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
> >> Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
> >>
> >> @Olivier, please, take a look at the end of the mail.
> >>
> >> On 10/29/19 8:19 PM, Slava Ovsiienko wrote:
> >>> Hi, Andrew
> >>>
> >>> Thank you for the review.
> >>>
> >>>> -----Original Message-----
> >>>> From: Andrew Rybchenko <arybchenko@solarflare.com>
> >>>> Sent: Tuesday, October 29, 2019 18:22
> >>>> To: Slava Ovsiienko <viacheslavo@mellanox.com>; dev@dpdk.org
> >>>> Cc: Thomas Monjalon <thomas@monjalon.net>; Matan Azrad
> >>>> <matan@mellanox.com>; olivier.matz@6wind.com; Ori Kam
> >>>> <orika@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
> >>>> Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
> >>>>
> >>>> On 10/27/19 9:40 PM, Viacheslav Ovsiienko wrote:
> >>>>> Currently, metadata can be set on egress path via mbuf tx_metadata
> >>>>> field with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_META
> >>>> matches metadata.
> >>>>> This patch extends the metadata feature usability.
> >>>>>
> >>>>> 1) RTE_FLOW_ACTION_TYPE_SET_META
> >>>>>
> >>>>> When supporting multiple tables, Tx metadata can also be set by a
> >>>>> rule and matched by another rule. This new action allows metadata
> >>>>> to be set as a result of flow match.
> >>>>>
> >>>>> 2) Metadata on ingress
> >>>>>
> >>>>> There's also need to support metadata on ingress. Metadata can be
> >>>>> set by SET_META action and matched by META item like Tx. The final
> >>>>> value set by the action will be delivered to application via
> >>>>> metadata dynamic field of mbuf which can be accessed by
> >>>> RTE_FLOW_DYNF_METADATA().
> >>>>> PKT_RX_DYNF_METADATA flag will be set along with the data.
> >>>>>
> >>>>> The mbuf dynamic field must be registered by calling
> >>>>> rte_flow_dynf_metadata_register() prior to use SET_META action.
> >>>>>
> >>>>> The availability of dynamic mbuf metadata field can be checked
> >>>>> with
> >>>>> rte_flow_dynf_metadata_avail() routine.
> >>>>>
> >>>>> For loopback/hairpin packet, metadata set on Rx/Tx may or may not
> >>>>> be propagated to the other path depending on hardware capability.
> >>>>>
> >>>>> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> >>>>> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
> >>>> Above explanations lack information about "meta" vs "mark" which
> >>>> may be set on Rx as well and delivered in other mbuf field.
> >>>> It should be explained by one more field is required and rules defined.
> >>> There is some story about metadata features.
> >>> Initially, there were proposed two metadata related actions:
> >>>
> >>> - RTE_FLOW_ACTION_TYPE_FLAG
> >>> - RTE_FLOW_ACTION_TYPE_MARK
> >>>
> >>> These actions set the special flag in the packet metadata, MARK
> >>> action stores some specified value in the metadata storage, and, on
> >>> the packet receiving PMD puts the flag and value to the mbuf and
> >>> applications can see the packet was threated inside flow engine
> >>> according to the appropriate RTE flow(s). MARK and FLAG are like
> >>> some kind of gateway to transfer some per-packet information from
> >>> the flow
> >> engine to the application via receiving datapath.
> >>> From the datapath point of view, the MARK and FLAG are related to
> >>> the
> >> receiving side only.
> >>> It would useful to have the same gateway on the transmitting side
> >>> and there was the feature of type RTE_FLOW_ITEM_TYPE_META was
> >> proposed.
> >>> The application can fill the field in mbuf and this value will be
> >>> transferred to
> >> some field in the packet metadata inside the flow engine.
> >>> It did not matter whether these metadata fields are shared because
> >>> of MARK and META items belonged to different domains (receiving and
> >> transmitting) and could be vendor-specific.
> >>> So far, so good, DPDK proposes some entities to control metadata
> >>> inside the flow engine and gateways to exchange these values on a
> >>> per-
> >> packet basis via datapaths.
> >>> As we can see, the MARK and META means are not symmetric, there is
> >>> absent action which would allow us to set META value on the
> >>> transmitting
> >> path. So, the action of type:
> >>> - RTE_FLOW_ACTION_TYPE_SET_META is proposed.
> >>>
> >>> The next, applications raise the new requirements for packet metadata.
> >>> The flow engines are getting more complex, internal switches are
> >>> introduced, multiple ports might be supported within the same flow
> >>> engine namespace. From the DPDK points of view, it means the packets
> >>> might be sent on one eth_dev port and received on the other one, and
> >>> the
> >> packet path inside the flow engine entirely belongs to the same
> >> hardware device. The simplest example is SR-IOV with PF, VFs and the
> representors.
> >>> And there is a brilliant opportunity to provide some out-of-band
> >>> channel to
> >> transfer some extra data
> >>> from one port to another one, besides the packet data itself.
> >>>
> >>>
> >>>> Above explanations lack information about "meta" vs "mark" which
> >>>> may be set on Rx as well and delivered in other mbuf field.
> >>>> It should be explained by one more field is required and rules defined.
> >>>> Otherwise we can endup in half PMDs supporting mark only, half PMDs
> >>>> supporting meta only and applications in an interesting situation
> >>>> to make a choice which one to use.
> >>> There is no "mark" vs "meta". MARK and META means are kept for
> >>> compatibility issues and legacy part works exactly as before. The
> >>> trials (with flow_validate) is supposed to check whether PMD
> >>> supports MARK or META feature on appropriate domain. It depends on
> >>> PMD implementation, configuration and underlaying HW/FW/kernel
> >>> capabilities
> >> and should be resolved in runtime.
> >>
> >> The trials a way, but very tricky way. My imagination draws me
> >> pictures how an application code could look like in attempt to use
> >> either mark or meta for Rx only and these pictures are not nice.
> > Agree, trials is not the best way.
> > For now there is no application trying to choose mark or meta, because
> > these ones belonged to other domains, and extension is newly introduced.
> > So, the applications using mark will continue use mark, the same is
> regarding meta.
> > The new application definitely will ask for both mark and of them, we
> > have the requirements from customers - "give us as many through bits as
> you can".
> > This new application just may refuse to work if metadata features are
> > not detected, because relays on it strongly.
> > BTW, trials are not so complex: rte_flow_validate(mark),
> > rte_flow_validate_metadata() and that's it.
>
> In assumption that pattern is supported and fate action used together with
> mark is supported as well. Not that easy, but OK.
>
> >> May be it will look acceptable when mark becomes a dynamic since
> >> usage of either one or another dynamic field is definitely easier
> >> than usage of either fixed or dynamic field.
> > At least in PMD datapath it does not look very ugly.
> >> May be dynamic field for mark at fixed offset should be introduced in
> >> the release or the nearest future? It will allow to preserve ABI up
> >> to 20.11 and provide future proof API.
> >> The trick is to register dynamic meta field at fixed offset at start
> >> of a day to be sure that it is guaranteed to succeed.
> >> It sounds like it is a transition mechanism from fixed to dynamic fields.
> >>
> >> [snip]
> >>
> >>>>> diff --git a/lib/librte_ethdev/rte_flow.h
> >>>>> b/lib/librte_ethdev/rte_flow.h index 4fee105..b821557 100644
> >>>>> --- a/lib/librte_ethdev/rte_flow.h
> >>>>> +++ b/lib/librte_ethdev/rte_flow.h
> >>>>> @@ -28,6 +28,8 @@
> >>>>> #include <rte_byteorder.h>
> >>>>> #include <rte_esp.h>
> >>>>> #include <rte_higig.h>
> >>>>> +#include <rte_mbuf.h>
> >>>>> +#include <rte_mbuf_dyn.h>
> >>>>>
> >>>>> #ifdef __cplusplus
> >>>>> extern "C" {
> >>>>> @@ -418,7 +420,8 @@ enum rte_flow_item_type {
> >>>>> /**
> >>>>> * [META]
> >>>>> *
> >>>>> - * Matches a metadata value specified in mbuf metadata field.
> >>>>> + * Matches a metadata value.
> >>>>> + *
> >>>>> * See struct rte_flow_item_meta.
> >>>>> */
> >>>>> RTE_FLOW_ITEM_TYPE_META,
> >>>>> @@ -1263,9 +1266,17 @@ struct
> rte_flow_item_icmp6_nd_opt_tla_eth
> >> {
> >>>>> #endif
> >>>>>
> >>>>> /**
> >>>>> - * RTE_FLOW_ITEM_TYPE_META.
> >>>>> + * @warning
> >>>>> + * @b EXPERIMENTAL: this structure may change without prior
> >>>>> + notice
> >>>> Is it allowed to make experimental back?
> >>> I think we should remove EXPERIMENTAL here. We do not introduce
> new
> >>> feature, but just extend the apply area.
> >> Agreed.
> >>
> >>>>> *
> >>>>> - * Matches a specified metadata value.
> >>>>> + * RTE_FLOW_ITEM_TYPE_META
> >>>>> + *
> >>>>> + * Matches a specified metadata value. On egress, metadata can be
> >>>>> + set either by
> >>>>> + * mbuf tx_metadata field with PKT_TX_METADATA flag or
> >>>>> + * RTE_FLOW_ACTION_TYPE_SET_META. On ingress,
> >>>>> + RTE_FLOW_ACTION_TYPE_SET_META sets
> >>>>> + * metadata for a packet and the metadata will be reported via
> >>>>> + mbuf metadata
> >>>>> + * dynamic field with PKT_RX_DYNF_METADATA flag. The dynamic
> >> mbuf
> >>>>> + field must be
> >>>>> + * registered in advance by rte_flow_dynf_metadata_register().
> >>>>> */
> >>>>> struct rte_flow_item_meta {
> >>>>> rte_be32_t data;
> >>>> [snip]
> >>>>
> >>>>> @@ -2429,6 +2447,55 @@ struct rte_flow_action_set_mac {
> >>>>> uint8_t mac_addr[RTE_ETHER_ADDR_LEN];
> >>>>> };
> >>>>>
> >>>>> +/**
> >>>>> + * @warning
> >>>>> + * @b EXPERIMENTAL: this structure may change without prior
> >>>>> +notice
> >>>>> + *
> >>>>> + * RTE_FLOW_ACTION_TYPE_SET_META
> >>>>> + *
> >>>>> + * Set metadata. Metadata set by mbuf tx_metadata field with
> >>>>> + * PKT_TX_METADATA flag on egress will be overridden by this
> action.
> >>>>> +On
> >>>>> + * ingress, the metadata will be carried by mbuf metadata dynamic
> >>>>> +field
> >>>>> + * with PKT_RX_DYNF_METADATA flag if set. The dynamic mbuf field
> >>>>> +must be
> >>>>> + * registered in advance by rte_flow_dynf_metadata_register().
> >>>>> + *
> >>>>> + * Altering partial bits is supported with mask. For bits which
> >>>>> +have never
> >>>>> + * been set, unpredictable value will be seen depending on driver
> >>>>> + * implementation. For loopback/hairpin packet, metadata set on
> >>>>> +Rx/Tx may
> >>>>> + * or may not be propagated to the other path depending on HW
> >>>> capability.
> >>>>> + *
> >>>>> + * RTE_FLOW_ITEM_TYPE_META matches metadata.
> >>>>> + */
> >>>>> +struct rte_flow_action_set_meta {
> >>>>> + rte_be32_t data;
> >>>>> + rte_be32_t mask;
> >>>> As I understand tx_metadata is host endian. Just double-checking.
> >>>> Is a new dynamic field host endian or big endian?
> >>>> I definitely would like to see motivation in comments why data/mask
> >>>> are big- endian here.
> >>> metadata is opaque value, endianness does not matter, there are no
> >>> some special motivations for choosing endiannes.
> >>> rte_flow_item_meta() structure provides data with rte_be32_t type,
> >>> so meta related action does
> >> the same.
> >>
> >> Endianness of meta in mbuf and flow API should match and it must be
> > Yes, and they match (for meta), both are rte_be32_t. OK, will emphasize it
> in docs.
> >
> >> documented. Endianness is important if a HW supports less bits since
> >> it makes a hit for application to use LSB first if the bit space is sufficient.
> >> mark is defined as host-endian (uint32_t) and I think meta should be
> >> the same. Otherwise it complicates even more either mark or meta
> >> usage as discussed above .
> > mark is mark, meta is meta, these ones are not interrelated (despite
> > they are becoming similar). And there is no choice between mark and meta.
> > It is not obvious we should have the same endianness for both.
> > There are some applications using this legacy features, so there might
> > be compatibility issues either.
>
> There are few reasons above to make meta host endian:
> - match mark endianness (explained above, I still think that my reasons
> vaild)
> - make it easier for application to use it without endianness conversion
> if a sequence number is used to allocate metas (similar to mark in OVS)
> and bit space is less than 32-bits
>
> I see no single reason to keep it big-endian except a reason to keep it.
>
> Since tx_metadata is going away and metadata was used for Tx only before
> it is a good moment to fix it.
>
> >> Yes, I think that rte_flow_item_meta should be fixed since both mark
> >> and tx_metadata are host-endian.
> >>
> >> (it says nothing about HW interface which is vendor specific and
> >> vendor PMDs should care about it)
> > Handling this in PMD might introduce the extra endianness conversion
> > in datapath, impacting performance. Not nice, IMO.
>
> These concerns should not affect external interface since it could be
> different for different HW vendors.
OK, will alter metadata endianness to host one. There Is undefeatable argument
the other [META] items/actions are all in HE.
With best regards, Slava
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
2019-10-30 8:59 0% ` Slava Ovsiienko
2019-10-30 9:20 0% ` Andrew Rybchenko
@ 2019-10-30 10:03 0% ` Slava Ovsiienko
1 sibling, 0 replies; 200+ results
From: Slava Ovsiienko @ 2019-10-30 10:03 UTC (permalink / raw)
To: Andrew Rybchenko, Thomas Monjalon, olivier.matz
Cc: dev, Matan Azrad, Ori Kam, Yongseok Koh
> -----Original Message-----
> From: Slava Ovsiienko
> Sent: Wednesday, October 30, 2019 11:00
> To: Andrew Rybchenko <arybchenko@solarflare.com>; Thomas Monjalon
> <thomas@monjalon.net>; olivier.matz@6wind.com
> Cc: dev@dpdk.org; Matan Azrad <matan@mellanox.com>; Ori Kam
> <orika@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
> Subject: RE: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
>
> > -----Original Message-----
> > From: Andrew Rybchenko <arybchenko@solarflare.com>
> > Sent: Wednesday, October 30, 2019 9:35
> > To: Slava Ovsiienko <viacheslavo@mellanox.com>; Thomas Monjalon
> > <thomas@monjalon.net>; olivier.matz@6wind.com
> > Cc: dev@dpdk.org; Matan Azrad <matan@mellanox.com>; Ori Kam
> > <orika@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
> > Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
> >
> > @Olivier, please, take a look at the end of the mail.
> >
> > On 10/29/19 8:19 PM, Slava Ovsiienko wrote:
> > > Hi, Andrew
> > >
> > > Thank you for the review.
> > >
> > >> -----Original Message-----
> > >> From: Andrew Rybchenko <arybchenko@solarflare.com>
> > >> Sent: Tuesday, October 29, 2019 18:22
> > >> To: Slava Ovsiienko <viacheslavo@mellanox.com>; dev@dpdk.org
> > >> Cc: Thomas Monjalon <thomas@monjalon.net>; Matan Azrad
> > >> <matan@mellanox.com>; olivier.matz@6wind.com; Ori Kam
> > >> <orika@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
> > >> Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
> > >>
> > >> On 10/27/19 9:40 PM, Viacheslav Ovsiienko wrote:
> > >>> Currently, metadata can be set on egress path via mbuf tx_metadata
> > >>> field with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_META
> > >> matches metadata.
> > >>> This patch extends the metadata feature usability.
> > >>>
> > >>> 1) RTE_FLOW_ACTION_TYPE_SET_META
> > >>>
> > >>> When supporting multiple tables, Tx metadata can also be set by a
> > >>> rule and matched by another rule. This new action allows metadata
> > >>> to be set as a result of flow match.
> > >>>
> > >>> 2) Metadata on ingress
> > >>>
> > >>> There's also need to support metadata on ingress. Metadata can be
> > >>> set by SET_META action and matched by META item like Tx. The final
> > >>> value set by the action will be delivered to application via
> > >>> metadata dynamic field of mbuf which can be accessed by
> > >> RTE_FLOW_DYNF_METADATA().
> > >>> PKT_RX_DYNF_METADATA flag will be set along with the data.
> > >>>
> > >>> The mbuf dynamic field must be registered by calling
> > >>> rte_flow_dynf_metadata_register() prior to use SET_META action.
> > >>>
> > >>> The availability of dynamic mbuf metadata field can be checked
> > >>> with
> > >>> rte_flow_dynf_metadata_avail() routine.
> > >>>
> > >>> For loopback/hairpin packet, metadata set on Rx/Tx may or may not
> > >>> be propagated to the other path depending on hardware capability.
> > >>>
> > >>> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> > >>> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
> > >> Above explanations lack information about "meta" vs "mark" which
> > >> may be set on Rx as well and delivered in other mbuf field.
> > >> It should be explained by one more field is required and rules defined.
> > > There is some story about metadata features.
> > > Initially, there were proposed two metadata related actions:
> > >
> > > - RTE_FLOW_ACTION_TYPE_FLAG
> > > - RTE_FLOW_ACTION_TYPE_MARK
> > >
> > > These actions set the special flag in the packet metadata, MARK
> > > action stores some specified value in the metadata storage, and, on
> > > the packet receiving PMD puts the flag and value to the mbuf and
> > > applications can see the packet was threated inside flow engine
> > > according to the appropriate RTE flow(s). MARK and FLAG are like
> > > some kind of gateway to transfer some per-packet information from
> > > the flow
> > engine to the application via receiving datapath.
> > >
> > > From the datapath point of view, the MARK and FLAG are related to
> > > the
> > receiving side only.
> > > It would useful to have the same gateway on the transmitting side
> > > and there was the feature of type RTE_FLOW_ITEM_TYPE_META was
> > proposed.
> > > The application can fill the field in mbuf and this value will be
> > > transferred to
> > some field in the packet metadata inside the flow engine.
> > > It did not matter whether these metadata fields are shared because
> > > of MARK and META items belonged to different domains (receiving and
> > transmitting) and could be vendor-specific.
> > >
> > > So far, so good, DPDK proposes some entities to control metadata
> > > inside the flow engine and gateways to exchange these values on a
> > > per-
> > packet basis via datapaths.
> > >
> > > As we can see, the MARK and META means are not symmetric, there is
> > > absent action which would allow us to set META value on the
> > > transmitting
> > path. So, the action of type:
> > > - RTE_FLOW_ACTION_TYPE_SET_META is proposed.
> > >
> > > The next, applications raise the new requirements for packet metadata.
> > > The flow engines are getting more complex, internal switches are
> > > introduced, multiple ports might be supported within the same flow
> > > engine namespace. From the DPDK points of view, it means the packets
> > > might be sent on one eth_dev port and received on the other one, and
> > > the
> > packet path inside the flow engine entirely belongs to the same
> > hardware device. The simplest example is SR-IOV with PF, VFs and the
> representors.
> > > And there is a brilliant opportunity to provide some out-of-band
> > > channel to
> > transfer some extra data
> > > from one port to another one, besides the packet data itself.
> > >
> > >
> > >> Above explanations lack information about "meta" vs "mark" which
> > >> may be set on Rx as well and delivered in other mbuf field.
> > >> It should be explained by one more field is required and rules defined.
> > >> Otherwise we can endup in half PMDs supporting mark only, half PMDs
> > >> supporting meta only and applications in an interesting situation
> > >> to make a choice which one to use.
> > > There is no "mark" vs "meta". MARK and META means are kept for
> > > compatibility issues and legacy part works exactly as before. The
> > > trials (with flow_validate) is supposed to check whether PMD
> > > supports MARK or META feature on appropriate domain. It depends on
> > > PMD implementation, configuration and underlaying HW/FW/kernel
> > > capabilities
> > and should be resolved in runtime.
> >
> > The trials a way, but very tricky way. My imagination draws me
> > pictures how an application code could look like in attempt to use
> > either mark or meta for Rx only and these pictures are not nice.
> Agree, trials is not the best way.
> For now there is no application trying to choose mark or meta, because
> these ones belonged to other domains, and extension is newly introduced.
> So, the applications using mark will continue use mark, the same is regarding
> meta.
> The new application definitely will ask for both mark and of them, we have
> the requirements from customers - "give us as many through bits as you
> can".
> This new application just may refuse to work if metadata features are not
> detected, because relays on it strongly.
> BTW, trials are not so complex: rte_flow_validate(mark),
> rte_flow_validate_metadata() and that's it.
>
> > May be it will look acceptable when mark becomes a dynamic since usage
> > of either one or another dynamic field is definitely easier than usage
> > of either fixed or dynamic field.
> At least in PMD datapath it does not look very ugly.
> >
> > May be dynamic field for mark at fixed offset should be introduced in
> > the release or the nearest future? It will allow to preserve ABI up to
> > 20.11 and provide future proof API.
> > The trick is to register dynamic meta field at fixed offset at start
> > of a day to be sure that it is guaranteed to succeed.
> > It sounds like it is a transition mechanism from fixed to dynamic fields.
> >
> > [snip]
> >
> > >>> diff --git a/lib/librte_ethdev/rte_flow.h
> > >>> b/lib/librte_ethdev/rte_flow.h index 4fee105..b821557 100644
> > >>> --- a/lib/librte_ethdev/rte_flow.h
> > >>> +++ b/lib/librte_ethdev/rte_flow.h
> > >>> @@ -28,6 +28,8 @@
> > >>> #include <rte_byteorder.h>
> > >>> #include <rte_esp.h>
> > >>> #include <rte_higig.h>
> > >>> +#include <rte_mbuf.h>
> > >>> +#include <rte_mbuf_dyn.h>
> > >>>
> > >>> #ifdef __cplusplus
> > >>> extern "C" {
> > >>> @@ -418,7 +420,8 @@ enum rte_flow_item_type {
> > >>> /**
> > >>> * [META]
> > >>> *
> > >>> - * Matches a metadata value specified in mbuf metadata field.
> > >>> + * Matches a metadata value.
> > >>> + *
> > >>> * See struct rte_flow_item_meta.
> > >>> */
> > >>> RTE_FLOW_ITEM_TYPE_META,
> > >>> @@ -1263,9 +1266,17 @@ struct
> rte_flow_item_icmp6_nd_opt_tla_eth
> > {
> > >>> #endif
> > >>>
> > >>> /**
> > >>> - * RTE_FLOW_ITEM_TYPE_META.
> > >>> + * @warning
> > >>> + * @b EXPERIMENTAL: this structure may change without prior
> > >>> + notice
> > >> Is it allowed to make experimental back?
> > > I think we should remove EXPERIMENTAL here. We do not introduce new
> > > feature, but just extend the apply area.
> >
> > Agreed.
> >
> > >>> *
> > >>> - * Matches a specified metadata value.
> > >>> + * RTE_FLOW_ITEM_TYPE_META
> > >>> + *
> > >>> + * Matches a specified metadata value. On egress, metadata can be
> > >>> + set either by
> > >>> + * mbuf tx_metadata field with PKT_TX_METADATA flag or
> > >>> + * RTE_FLOW_ACTION_TYPE_SET_META. On ingress,
> > >>> + RTE_FLOW_ACTION_TYPE_SET_META sets
> > >>> + * metadata for a packet and the metadata will be reported via
> > >>> + mbuf metadata
> > >>> + * dynamic field with PKT_RX_DYNF_METADATA flag. The dynamic
> > mbuf
> > >>> + field must be
> > >>> + * registered in advance by rte_flow_dynf_metadata_register().
> > >>> */
> > >>> struct rte_flow_item_meta {
> > >>> rte_be32_t data;
> > >> [snip]
> > >>
> > >>> @@ -2429,6 +2447,55 @@ struct rte_flow_action_set_mac {
> > >>> uint8_t mac_addr[RTE_ETHER_ADDR_LEN];
> > >>> };
> > >>>
> > >>> +/**
> > >>> + * @warning
> > >>> + * @b EXPERIMENTAL: this structure may change without prior
> > >>> +notice
> > >>> + *
> > >>> + * RTE_FLOW_ACTION_TYPE_SET_META
> > >>> + *
> > >>> + * Set metadata. Metadata set by mbuf tx_metadata field with
> > >>> + * PKT_TX_METADATA flag on egress will be overridden by this action.
> > >>> +On
> > >>> + * ingress, the metadata will be carried by mbuf metadata dynamic
> > >>> +field
> > >>> + * with PKT_RX_DYNF_METADATA flag if set. The dynamic mbuf field
> > >>> +must be
> > >>> + * registered in advance by rte_flow_dynf_metadata_register().
> > >>> + *
> > >>> + * Altering partial bits is supported with mask. For bits which
> > >>> +have never
> > >>> + * been set, unpredictable value will be seen depending on driver
> > >>> + * implementation. For loopback/hairpin packet, metadata set on
> > >>> +Rx/Tx may
> > >>> + * or may not be propagated to the other path depending on HW
> > >> capability.
> > >>> + *
> > >>> + * RTE_FLOW_ITEM_TYPE_META matches metadata.
> > >>> + */
> > >>> +struct rte_flow_action_set_meta {
> > >>> + rte_be32_t data;
> > >>> + rte_be32_t mask;
> > >> As I understand tx_metadata is host endian. Just double-checking.
> > >> Is a new dynamic field host endian or big endian?
> > >> I definitely would like to see motivation in comments why data/mask
> > >> are big- endian here.
> > > metadata is opaque value, endianness does not matter, there are no
> > > some special motivations for choosing endiannes.
> > > rte_flow_item_meta() structure provides data with rte_be32_t type,
> > > so meta related action does
> > the same.
> >
> > Endianness of meta in mbuf and flow API should match and it must be
> Yes, and they match (for meta), both are rte_be32_t. OK, will emphasize it in
> docs.
>
> > documented. Endianness is important if a HW supports less bits since
> > it makes a hit for application to use LSB first if the bit space is sufficient.
> > mark is defined as host-endian (uint32_t) and I think meta should be
> > the same. Otherwise it complicates even more either mark or meta usage
> > as discussed above .
> mark is mark, meta is meta, these ones are not interrelated (despite they are
> becoming similar). And there is no choice between mark and meta.
> It is not obvious we should have the same endianness for both.
> There are some applications using this legacy features, so there might be
> compatibility issues either.
>
> >
> > Yes, I think that rte_flow_item_meta should be fixed since both mark
> > and tx_metadata are host-endian.
> >
> > (it says nothing about HW interface which is vendor specific and
> > vendor PMDs should care about it)
> Handling this in PMD might introduce the extra endianness conversion in
> datapath, impacting performance. Not nice, IMO.
Update: I've reviewed other [META] items/actions, all of them are in
host endianness. OK, we are moving tx_metadata to dynfield, it seems to
be good point to alter metadata endianness. And I see the way to avoid
conversions in data path
With best regards, Slava
> >
> > > I could assume the origin of selecting bigendian type was the
> > > endianness of metadata field in Tx descriptor of ConnectX NICs.
> > >
> > >>> +};
> > >>> +
> > >>> +/* Mbuf dynamic field offset for metadata. */ extern int
> > >>> +rte_flow_dynf_metadata_offs;
> > >>> +
> > >>> +/* Mbuf dynamic field flag mask for metadata. */ extern uint64_t
> > >>> +rte_flow_dynf_metadata_mask;
> > >> These two global variables look frightening to me.
> > >> It does not look good to me.
> > > For me too. But we need the performance, these ones are intended for
> > > usage in datapath, any overhead is painful.
> >
> > @Olivier, could you share your thoughts, please.
> >
> > Andrew.
>
> With best regards, Slava
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
2019-10-30 8:59 0% ` Slava Ovsiienko
@ 2019-10-30 9:20 0% ` Andrew Rybchenko
2019-10-30 10:05 0% ` Slava Ovsiienko
2019-10-30 10:03 0% ` Slava Ovsiienko
1 sibling, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-10-30 9:20 UTC (permalink / raw)
To: Slava Ovsiienko, Thomas Monjalon, olivier.matz
Cc: dev, Matan Azrad, Ori Kam, Yongseok Koh
On 10/30/19 11:59 AM, Slava Ovsiienko wrote:
>> -----Original Message-----
>> From: Andrew Rybchenko <arybchenko@solarflare.com>
>> Sent: Wednesday, October 30, 2019 9:35
>> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Thomas Monjalon
>> <thomas@monjalon.net>; olivier.matz@6wind.com
>> Cc: dev@dpdk.org; Matan Azrad <matan@mellanox.com>; Ori Kam
>> <orika@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
>> Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
>>
>> @Olivier, please, take a look at the end of the mail.
>>
>> On 10/29/19 8:19 PM, Slava Ovsiienko wrote:
>>> Hi, Andrew
>>>
>>> Thank you for the review.
>>>
>>>> -----Original Message-----
>>>> From: Andrew Rybchenko <arybchenko@solarflare.com>
>>>> Sent: Tuesday, October 29, 2019 18:22
>>>> To: Slava Ovsiienko <viacheslavo@mellanox.com>; dev@dpdk.org
>>>> Cc: Thomas Monjalon <thomas@monjalon.net>; Matan Azrad
>>>> <matan@mellanox.com>; olivier.matz@6wind.com; Ori Kam
>>>> <orika@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
>>>> Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
>>>>
>>>> On 10/27/19 9:40 PM, Viacheslav Ovsiienko wrote:
>>>>> Currently, metadata can be set on egress path via mbuf tx_metadata
>>>>> field with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_META
>>>> matches metadata.
>>>>> This patch extends the metadata feature usability.
>>>>>
>>>>> 1) RTE_FLOW_ACTION_TYPE_SET_META
>>>>>
>>>>> When supporting multiple tables, Tx metadata can also be set by a
>>>>> rule and matched by another rule. This new action allows metadata to
>>>>> be set as a result of flow match.
>>>>>
>>>>> 2) Metadata on ingress
>>>>>
>>>>> There's also need to support metadata on ingress. Metadata can be
>>>>> set by SET_META action and matched by META item like Tx. The final
>>>>> value set by the action will be delivered to application via
>>>>> metadata dynamic field of mbuf which can be accessed by
>>>> RTE_FLOW_DYNF_METADATA().
>>>>> PKT_RX_DYNF_METADATA flag will be set along with the data.
>>>>>
>>>>> The mbuf dynamic field must be registered by calling
>>>>> rte_flow_dynf_metadata_register() prior to use SET_META action.
>>>>>
>>>>> The availability of dynamic mbuf metadata field can be checked with
>>>>> rte_flow_dynf_metadata_avail() routine.
>>>>>
>>>>> For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
>>>>> propagated to the other path depending on hardware capability.
>>>>>
>>>>> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
>>>>> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
>>>> Above explanations lack information about "meta" vs "mark" which may
>>>> be set on Rx as well and delivered in other mbuf field.
>>>> It should be explained by one more field is required and rules defined.
>>> There is some story about metadata features.
>>> Initially, there were proposed two metadata related actions:
>>>
>>> - RTE_FLOW_ACTION_TYPE_FLAG
>>> - RTE_FLOW_ACTION_TYPE_MARK
>>>
>>> These actions set the special flag in the packet metadata, MARK action
>>> stores some specified value in the metadata storage, and, on the
>>> packet receiving PMD puts the flag and value to the mbuf and
>>> applications can see the packet was threated inside flow engine
>>> according to the appropriate RTE flow(s). MARK and FLAG are like some
>>> kind of gateway to transfer some per-packet information from the flow
>> engine to the application via receiving datapath.
>>> From the datapath point of view, the MARK and FLAG are related to the
>> receiving side only.
>>> It would useful to have the same gateway on the transmitting side and
>>> there was the feature of type RTE_FLOW_ITEM_TYPE_META was
>> proposed.
>>> The application can fill the field in mbuf and this value will be transferred to
>> some field in the packet metadata inside the flow engine.
>>> It did not matter whether these metadata fields are shared because of
>>> MARK and META items belonged to different domains (receiving and
>> transmitting) and could be vendor-specific.
>>> So far, so good, DPDK proposes some entities to control metadata
>>> inside the flow engine and gateways to exchange these values on a per-
>> packet basis via datapaths.
>>> As we can see, the MARK and META means are not symmetric, there is
>>> absent action which would allow us to set META value on the transmitting
>> path. So, the action of type:
>>> - RTE_FLOW_ACTION_TYPE_SET_META is proposed.
>>>
>>> The next, applications raise the new requirements for packet metadata.
>>> The flow engines are getting more complex, internal switches are
>>> introduced, multiple ports might be supported within the same flow
>>> engine namespace. From the DPDK points of view, it means the packets
>>> might be sent on one eth_dev port and received on the other one, and the
>> packet path inside the flow engine entirely belongs to the same hardware
>> device. The simplest example is SR-IOV with PF, VFs and the representors.
>>> And there is a brilliant opportunity to provide some out-of-band channel to
>> transfer some extra data
>>> from one port to another one, besides the packet data itself.
>>>
>>>
>>>> Above explanations lack information about "meta" vs "mark" which may
>>>> be set on Rx as well and delivered in other mbuf field.
>>>> It should be explained by one more field is required and rules defined.
>>>> Otherwise we can endup in half PMDs supporting mark only, half PMDs
>>>> supporting meta only and applications in an interesting situation to
>>>> make a choice which one to use.
>>> There is no "mark" vs "meta". MARK and META means are kept for
>>> compatibility issues and legacy part works exactly as before. The
>>> trials (with flow_validate) is supposed to check whether PMD supports
>>> MARK or META feature on appropriate domain. It depends on PMD
>>> implementation, configuration and underlaying HW/FW/kernel capabilities
>> and should be resolved in runtime.
>>
>> The trials a way, but very tricky way. My imagination draws me pictures how
>> an application code could look like in attempt to use either mark or meta for
>> Rx only and these pictures are not nice.
> Agree, trials is not the best way.
> For now there is no application trying to choose mark or meta, because these ones
> belonged to other domains, and extension is newly introduced.
> So, the applications using mark will continue use mark, the same is regarding meta.
> The new application definitely will ask for both mark and of them,
> we have the requirements from customers - "give us as many through bits as you can".
> This new application just may refuse to work if metadata features are not detected,
> because relays on it strongly.
> BTW, trials are not so complex: rte_flow_validate(mark), rte_flow_validate_metadata()
> and that's it.
In assumption that pattern is supported and fate action used together
with mark
is supported as well. Not that easy, but OK.
>> May be it will look acceptable when mark becomes a dynamic since usage of
>> either one or another dynamic field is definitely easier than usage of either
>> fixed or dynamic field.
> At least in PMD datapath it does not look very ugly.
>> May be dynamic field for mark at fixed offset should be introduced in the
>> release or the nearest future? It will allow to preserve ABI up to 20.11 and
>> provide future proof API.
>> The trick is to register dynamic meta field at fixed offset at start of a day to
>> be sure that it is guaranteed to succeed.
>> It sounds like it is a transition mechanism from fixed to dynamic fields.
>>
>> [snip]
>>
>>>>> diff --git a/lib/librte_ethdev/rte_flow.h
>>>>> b/lib/librte_ethdev/rte_flow.h index 4fee105..b821557 100644
>>>>> --- a/lib/librte_ethdev/rte_flow.h
>>>>> +++ b/lib/librte_ethdev/rte_flow.h
>>>>> @@ -28,6 +28,8 @@
>>>>> #include <rte_byteorder.h>
>>>>> #include <rte_esp.h>
>>>>> #include <rte_higig.h>
>>>>> +#include <rte_mbuf.h>
>>>>> +#include <rte_mbuf_dyn.h>
>>>>>
>>>>> #ifdef __cplusplus
>>>>> extern "C" {
>>>>> @@ -418,7 +420,8 @@ enum rte_flow_item_type {
>>>>> /**
>>>>> * [META]
>>>>> *
>>>>> - * Matches a metadata value specified in mbuf metadata field.
>>>>> + * Matches a metadata value.
>>>>> + *
>>>>> * See struct rte_flow_item_meta.
>>>>> */
>>>>> RTE_FLOW_ITEM_TYPE_META,
>>>>> @@ -1263,9 +1266,17 @@ struct rte_flow_item_icmp6_nd_opt_tla_eth
>> {
>>>>> #endif
>>>>>
>>>>> /**
>>>>> - * RTE_FLOW_ITEM_TYPE_META.
>>>>> + * @warning
>>>>> + * @b EXPERIMENTAL: this structure may change without prior notice
>>>> Is it allowed to make experimental back?
>>> I think we should remove EXPERIMENTAL here. We do not introduce new
>>> feature, but just extend the apply area.
>> Agreed.
>>
>>>>> *
>>>>> - * Matches a specified metadata value.
>>>>> + * RTE_FLOW_ITEM_TYPE_META
>>>>> + *
>>>>> + * Matches a specified metadata value. On egress, metadata can be
>>>>> + set either by
>>>>> + * mbuf tx_metadata field with PKT_TX_METADATA flag or
>>>>> + * RTE_FLOW_ACTION_TYPE_SET_META. On ingress,
>>>>> + RTE_FLOW_ACTION_TYPE_SET_META sets
>>>>> + * metadata for a packet and the metadata will be reported via mbuf
>>>>> + metadata
>>>>> + * dynamic field with PKT_RX_DYNF_METADATA flag. The dynamic
>> mbuf
>>>>> + field must be
>>>>> + * registered in advance by rte_flow_dynf_metadata_register().
>>>>> */
>>>>> struct rte_flow_item_meta {
>>>>> rte_be32_t data;
>>>> [snip]
>>>>
>>>>> @@ -2429,6 +2447,55 @@ struct rte_flow_action_set_mac {
>>>>> uint8_t mac_addr[RTE_ETHER_ADDR_LEN];
>>>>> };
>>>>>
>>>>> +/**
>>>>> + * @warning
>>>>> + * @b EXPERIMENTAL: this structure may change without prior notice
>>>>> + *
>>>>> + * RTE_FLOW_ACTION_TYPE_SET_META
>>>>> + *
>>>>> + * Set metadata. Metadata set by mbuf tx_metadata field with
>>>>> + * PKT_TX_METADATA flag on egress will be overridden by this action.
>>>>> +On
>>>>> + * ingress, the metadata will be carried by mbuf metadata dynamic
>>>>> +field
>>>>> + * with PKT_RX_DYNF_METADATA flag if set. The dynamic mbuf field
>>>>> +must be
>>>>> + * registered in advance by rte_flow_dynf_metadata_register().
>>>>> + *
>>>>> + * Altering partial bits is supported with mask. For bits which
>>>>> +have never
>>>>> + * been set, unpredictable value will be seen depending on driver
>>>>> + * implementation. For loopback/hairpin packet, metadata set on
>>>>> +Rx/Tx may
>>>>> + * or may not be propagated to the other path depending on HW
>>>> capability.
>>>>> + *
>>>>> + * RTE_FLOW_ITEM_TYPE_META matches metadata.
>>>>> + */
>>>>> +struct rte_flow_action_set_meta {
>>>>> + rte_be32_t data;
>>>>> + rte_be32_t mask;
>>>> As I understand tx_metadata is host endian. Just double-checking.
>>>> Is a new dynamic field host endian or big endian?
>>>> I definitely would like to see motivation in comments why data/mask
>>>> are big- endian here.
>>> metadata is opaque value, endianness does not matter, there are no
>>> some special motivations for choosing endiannes. rte_flow_item_meta()
>>> structure provides data with rte_be32_t type, so meta related action does
>> the same.
>>
>> Endianness of meta in mbuf and flow API should match and it must be
> Yes, and they match (for meta), both are rte_be32_t. OK, will emphasize it in docs.
>
>> documented. Endianness is important if a HW supports less bits since it
>> makes a hit for application to use LSB first if the bit space is sufficient.
>> mark is defined as host-endian (uint32_t) and I think meta should be the
>> same. Otherwise it complicates even more either mark or meta usage as
>> discussed above .
> mark is mark, meta is meta, these ones are not interrelated (despite they
> are becoming similar). And there is no choice between mark and meta.
> It is not obvious we should have the same endianness for both.
> There are some applications using this legacy features, so there might be compatibility
> issues either.
There are few reasons above to make meta host endian:
- match mark endianness (explained above, I still think that my reasons
vaild)
- make it easier for application to use it without endianness conversion
if a sequence number is used to allocate metas (similar to mark in OVS)
and bit space is less than 32-bits
I see no single reason to keep it big-endian except a reason to keep it.
Since tx_metadata is going away and metadata was used for Tx only
before it is a good moment to fix it.
>> Yes, I think that rte_flow_item_meta should be fixed since both mark and
>> tx_metadata are host-endian.
>>
>> (it says nothing about HW interface which is vendor specific and vendor
>> PMDs should care about it)
> Handling this in PMD might introduce the extra endianness conversion in datapath,
> impacting performance. Not nice, IMO.
These concerns should not affect external interface since
it could be different for different HW vendors.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
2019-10-30 7:35 3% ` Andrew Rybchenko
@ 2019-10-30 8:59 0% ` Slava Ovsiienko
2019-10-30 9:20 0% ` Andrew Rybchenko
2019-10-30 10:03 0% ` Slava Ovsiienko
0 siblings, 2 replies; 200+ results
From: Slava Ovsiienko @ 2019-10-30 8:59 UTC (permalink / raw)
To: Andrew Rybchenko, Thomas Monjalon, olivier.matz
Cc: dev, Matan Azrad, Ori Kam, Yongseok Koh
> -----Original Message-----
> From: Andrew Rybchenko <arybchenko@solarflare.com>
> Sent: Wednesday, October 30, 2019 9:35
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Thomas Monjalon
> <thomas@monjalon.net>; olivier.matz@6wind.com
> Cc: dev@dpdk.org; Matan Azrad <matan@mellanox.com>; Ori Kam
> <orika@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
>
> @Olivier, please, take a look at the end of the mail.
>
> On 10/29/19 8:19 PM, Slava Ovsiienko wrote:
> > Hi, Andrew
> >
> > Thank you for the review.
> >
> >> -----Original Message-----
> >> From: Andrew Rybchenko <arybchenko@solarflare.com>
> >> Sent: Tuesday, October 29, 2019 18:22
> >> To: Slava Ovsiienko <viacheslavo@mellanox.com>; dev@dpdk.org
> >> Cc: Thomas Monjalon <thomas@monjalon.net>; Matan Azrad
> >> <matan@mellanox.com>; olivier.matz@6wind.com; Ori Kam
> >> <orika@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
> >> Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
> >>
> >> On 10/27/19 9:40 PM, Viacheslav Ovsiienko wrote:
> >>> Currently, metadata can be set on egress path via mbuf tx_metadata
> >>> field with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_META
> >> matches metadata.
> >>> This patch extends the metadata feature usability.
> >>>
> >>> 1) RTE_FLOW_ACTION_TYPE_SET_META
> >>>
> >>> When supporting multiple tables, Tx metadata can also be set by a
> >>> rule and matched by another rule. This new action allows metadata to
> >>> be set as a result of flow match.
> >>>
> >>> 2) Metadata on ingress
> >>>
> >>> There's also need to support metadata on ingress. Metadata can be
> >>> set by SET_META action and matched by META item like Tx. The final
> >>> value set by the action will be delivered to application via
> >>> metadata dynamic field of mbuf which can be accessed by
> >> RTE_FLOW_DYNF_METADATA().
> >>> PKT_RX_DYNF_METADATA flag will be set along with the data.
> >>>
> >>> The mbuf dynamic field must be registered by calling
> >>> rte_flow_dynf_metadata_register() prior to use SET_META action.
> >>>
> >>> The availability of dynamic mbuf metadata field can be checked with
> >>> rte_flow_dynf_metadata_avail() routine.
> >>>
> >>> For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
> >>> propagated to the other path depending on hardware capability.
> >>>
> >>> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> >>> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
> >> Above explanations lack information about "meta" vs "mark" which may
> >> be set on Rx as well and delivered in other mbuf field.
> >> It should be explained by one more field is required and rules defined.
> > There is some story about metadata features.
> > Initially, there were proposed two metadata related actions:
> >
> > - RTE_FLOW_ACTION_TYPE_FLAG
> > - RTE_FLOW_ACTION_TYPE_MARK
> >
> > These actions set the special flag in the packet metadata, MARK action
> > stores some specified value in the metadata storage, and, on the
> > packet receiving PMD puts the flag and value to the mbuf and
> > applications can see the packet was threated inside flow engine
> > according to the appropriate RTE flow(s). MARK and FLAG are like some
> > kind of gateway to transfer some per-packet information from the flow
> engine to the application via receiving datapath.
> >
> > From the datapath point of view, the MARK and FLAG are related to the
> receiving side only.
> > It would useful to have the same gateway on the transmitting side and
> > there was the feature of type RTE_FLOW_ITEM_TYPE_META was
> proposed.
> > The application can fill the field in mbuf and this value will be transferred to
> some field in the packet metadata inside the flow engine.
> > It did not matter whether these metadata fields are shared because of
> > MARK and META items belonged to different domains (receiving and
> transmitting) and could be vendor-specific.
> >
> > So far, so good, DPDK proposes some entities to control metadata
> > inside the flow engine and gateways to exchange these values on a per-
> packet basis via datapaths.
> >
> > As we can see, the MARK and META means are not symmetric, there is
> > absent action which would allow us to set META value on the transmitting
> path. So, the action of type:
> > - RTE_FLOW_ACTION_TYPE_SET_META is proposed.
> >
> > The next, applications raise the new requirements for packet metadata.
> > The flow engines are getting more complex, internal switches are
> > introduced, multiple ports might be supported within the same flow
> > engine namespace. From the DPDK points of view, it means the packets
> > might be sent on one eth_dev port and received on the other one, and the
> packet path inside the flow engine entirely belongs to the same hardware
> device. The simplest example is SR-IOV with PF, VFs and the representors.
> > And there is a brilliant opportunity to provide some out-of-band channel to
> transfer some extra data
> > from one port to another one, besides the packet data itself.
> >
> >
> >> Above explanations lack information about "meta" vs "mark" which may
> >> be set on Rx as well and delivered in other mbuf field.
> >> It should be explained by one more field is required and rules defined.
> >> Otherwise we can endup in half PMDs supporting mark only, half PMDs
> >> supporting meta only and applications in an interesting situation to
> >> make a choice which one to use.
> > There is no "mark" vs "meta". MARK and META means are kept for
> > compatibility issues and legacy part works exactly as before. The
> > trials (with flow_validate) is supposed to check whether PMD supports
> > MARK or META feature on appropriate domain. It depends on PMD
> > implementation, configuration and underlaying HW/FW/kernel capabilities
> and should be resolved in runtime.
>
> The trials a way, but very tricky way. My imagination draws me pictures how
> an application code could look like in attempt to use either mark or meta for
> Rx only and these pictures are not nice.
Agree, trials is not the best way.
For now there is no application trying to choose mark or meta, because these ones
belonged to other domains, and extension is newly introduced.
So, the applications using mark will continue use mark, the same is regarding meta.
The new application definitely will ask for both mark and of them,
we have the requirements from customers - "give us as many through bits as you can".
This new application just may refuse to work if metadata features are not detected,
because relays on it strongly.
BTW, trials are not so complex: rte_flow_validate(mark), rte_flow_validate_metadata()
and that's it.
> May be it will look acceptable when mark becomes a dynamic since usage of
> either one or another dynamic field is definitely easier than usage of either
> fixed or dynamic field.
At least in PMD datapath it does not look very ugly.
>
> May be dynamic field for mark at fixed offset should be introduced in the
> release or the nearest future? It will allow to preserve ABI up to 20.11 and
> provide future proof API.
> The trick is to register dynamic meta field at fixed offset at start of a day to
> be sure that it is guaranteed to succeed.
> It sounds like it is a transition mechanism from fixed to dynamic fields.
>
> [snip]
>
> >>> diff --git a/lib/librte_ethdev/rte_flow.h
> >>> b/lib/librte_ethdev/rte_flow.h index 4fee105..b821557 100644
> >>> --- a/lib/librte_ethdev/rte_flow.h
> >>> +++ b/lib/librte_ethdev/rte_flow.h
> >>> @@ -28,6 +28,8 @@
> >>> #include <rte_byteorder.h>
> >>> #include <rte_esp.h>
> >>> #include <rte_higig.h>
> >>> +#include <rte_mbuf.h>
> >>> +#include <rte_mbuf_dyn.h>
> >>>
> >>> #ifdef __cplusplus
> >>> extern "C" {
> >>> @@ -418,7 +420,8 @@ enum rte_flow_item_type {
> >>> /**
> >>> * [META]
> >>> *
> >>> - * Matches a metadata value specified in mbuf metadata field.
> >>> + * Matches a metadata value.
> >>> + *
> >>> * See struct rte_flow_item_meta.
> >>> */
> >>> RTE_FLOW_ITEM_TYPE_META,
> >>> @@ -1263,9 +1266,17 @@ struct rte_flow_item_icmp6_nd_opt_tla_eth
> {
> >>> #endif
> >>>
> >>> /**
> >>> - * RTE_FLOW_ITEM_TYPE_META.
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this structure may change without prior notice
> >> Is it allowed to make experimental back?
> > I think we should remove EXPERIMENTAL here. We do not introduce new
> > feature, but just extend the apply area.
>
> Agreed.
>
> >>> *
> >>> - * Matches a specified metadata value.
> >>> + * RTE_FLOW_ITEM_TYPE_META
> >>> + *
> >>> + * Matches a specified metadata value. On egress, metadata can be
> >>> + set either by
> >>> + * mbuf tx_metadata field with PKT_TX_METADATA flag or
> >>> + * RTE_FLOW_ACTION_TYPE_SET_META. On ingress,
> >>> + RTE_FLOW_ACTION_TYPE_SET_META sets
> >>> + * metadata for a packet and the metadata will be reported via mbuf
> >>> + metadata
> >>> + * dynamic field with PKT_RX_DYNF_METADATA flag. The dynamic
> mbuf
> >>> + field must be
> >>> + * registered in advance by rte_flow_dynf_metadata_register().
> >>> */
> >>> struct rte_flow_item_meta {
> >>> rte_be32_t data;
> >> [snip]
> >>
> >>> @@ -2429,6 +2447,55 @@ struct rte_flow_action_set_mac {
> >>> uint8_t mac_addr[RTE_ETHER_ADDR_LEN];
> >>> };
> >>>
> >>> +/**
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this structure may change without prior notice
> >>> + *
> >>> + * RTE_FLOW_ACTION_TYPE_SET_META
> >>> + *
> >>> + * Set metadata. Metadata set by mbuf tx_metadata field with
> >>> + * PKT_TX_METADATA flag on egress will be overridden by this action.
> >>> +On
> >>> + * ingress, the metadata will be carried by mbuf metadata dynamic
> >>> +field
> >>> + * with PKT_RX_DYNF_METADATA flag if set. The dynamic mbuf field
> >>> +must be
> >>> + * registered in advance by rte_flow_dynf_metadata_register().
> >>> + *
> >>> + * Altering partial bits is supported with mask. For bits which
> >>> +have never
> >>> + * been set, unpredictable value will be seen depending on driver
> >>> + * implementation. For loopback/hairpin packet, metadata set on
> >>> +Rx/Tx may
> >>> + * or may not be propagated to the other path depending on HW
> >> capability.
> >>> + *
> >>> + * RTE_FLOW_ITEM_TYPE_META matches metadata.
> >>> + */
> >>> +struct rte_flow_action_set_meta {
> >>> + rte_be32_t data;
> >>> + rte_be32_t mask;
> >> As I understand tx_metadata is host endian. Just double-checking.
> >> Is a new dynamic field host endian or big endian?
> >> I definitely would like to see motivation in comments why data/mask
> >> are big- endian here.
> > metadata is opaque value, endianness does not matter, there are no
> > some special motivations for choosing endiannes. rte_flow_item_meta()
> > structure provides data with rte_be32_t type, so meta related action does
> the same.
>
> Endianness of meta in mbuf and flow API should match and it must be
Yes, and they match (for meta), both are rte_be32_t. OK, will emphasize it in docs.
> documented. Endianness is important if a HW supports less bits since it
> makes a hit for application to use LSB first if the bit space is sufficient.
> mark is defined as host-endian (uint32_t) and I think meta should be the
> same. Otherwise it complicates even more either mark or meta usage as
> discussed above .
mark is mark, meta is meta, these ones are not interrelated (despite they
are becoming similar). And there is no choice between mark and meta.
It is not obvious we should have the same endianness for both.
There are some applications using this legacy features, so there might be compatibility
issues either.
>
> Yes, I think that rte_flow_item_meta should be fixed since both mark and
> tx_metadata are host-endian.
>
> (it says nothing about HW interface which is vendor specific and vendor
> PMDs should care about it)
Handling this in PMD might introduce the extra endianness conversion in datapath,
impacting performance. Not nice, IMO.
>
> > I could assume the origin of selecting bigendian type was the
> > endianness of metadata field in Tx descriptor of ConnectX NICs.
> >
> >>> +};
> >>> +
> >>> +/* Mbuf dynamic field offset for metadata. */ extern int
> >>> +rte_flow_dynf_metadata_offs;
> >>> +
> >>> +/* Mbuf dynamic field flag mask for metadata. */ extern uint64_t
> >>> +rte_flow_dynf_metadata_mask;
> >> These two global variables look frightening to me.
> >> It does not look good to me.
> > For me too. But we need the performance, these ones are intended for
> > usage in datapath, any overhead is painful.
>
> @Olivier, could you share your thoughts, please.
>
> Andrew.
With best regards, Slava
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3 2/2] ipsec: remove redundant replay_win_sz
@ 2019-10-30 8:57 5% ` Hemant Agrawal
2019-10-30 13:08 0% ` Ananyev, Konstantin
2019-10-31 4:54 5% ` [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size Hemant Agrawal
1 sibling, 1 reply; 200+ results
From: Hemant Agrawal @ 2019-10-30 8:57 UTC (permalink / raw)
To: dev, akhil.goyal; +Cc: konstantin.ananyev, Hemant Agrawal
The rte_security lib has introduced replay_win_sz,
so it can be removed from the rte_ipsec lib.
Also, the relaved tests,app are also update to reflect
the usages.
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
---
v3: fix the compilation issue
app/test/test_ipsec.c | 2 +-
doc/guides/rel_notes/release_19_11.rst | 10 ++++++++--
examples/ipsec-secgw/ipsec.c | 1 +
examples/ipsec-secgw/sa.c | 2 +-
lib/librte_ipsec/Makefile | 2 +-
lib/librte_ipsec/meson.build | 1 +
lib/librte_ipsec/rte_ipsec_sa.h | 6 ------
lib/librte_ipsec/sa.c | 4 ++--
8 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
index 4007eff19..9e3dabd93 100644
--- a/app/test/test_ipsec.c
+++ b/app/test/test_ipsec.c
@@ -689,7 +689,7 @@ fill_ipsec_param(uint32_t replay_win_sz, uint64_t flags)
prm->userdata = 1;
prm->flags = flags;
- prm->replay_win_sz = replay_win_sz;
+ prm->ipsec_xform.replay_win_sz = replay_win_sz;
/* setup ipsec xform */
prm->ipsec_xform = ut_params->ipsec_xform;
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index ae8e7b2f0..aa16c8422 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -365,6 +365,12 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
+* security: A new field ''replay_win_sz'' has been added to the structure
+ ``rte_security_ipsec_xform``, which specify the Anti replay window size
+ to enable sequence replay attack handling.
+
+* ipsec: The field ''replay_win_sz'' has been removed from the structure
+ ''rte_ipsec_sa_prm'' as it has been added to the security library.
Shared Library Versions
-----------------------
@@ -407,7 +413,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_gso.so.1
librte_hash.so.2
librte_ip_frag.so.1
- librte_ipsec.so.1
+ + librte_ipsec.so.2
librte_jobstats.so.1
librte_kni.so.2
librte_kvargs.so.1
@@ -437,7 +443,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_reorder.so.1
librte_ring.so.2
+ librte_sched.so.4
- librte_security.so.2
+ + librte_security.so.3
librte_stack.so.1
librte_table.so.3
librte_timer.so.1
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 51fb22e8a..159e81f99 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -49,6 +49,7 @@ set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
/* TODO support for Transport */
}
ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
+ ipsec->replay_win_sz = app_sa_prm.window_size;
}
int
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 14ee94731..3d687c459 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -1055,7 +1055,7 @@ fill_ipsec_app_sa_prm(struct rte_ipsec_sa_prm *prm,
prm->flags = app_prm->flags;
prm->ipsec_xform.options.esn = app_prm->enable_esn;
- prm->replay_win_sz = app_prm->window_size;
+ prm->ipsec_xform.replay_win_sz = app_prm->window_size;
}
static int
diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile
index 81fb99980..161ea9e3d 100644
--- a/lib/librte_ipsec/Makefile
+++ b/lib/librte_ipsec/Makefile
@@ -14,7 +14,7 @@ LDLIBS += -lrte_cryptodev -lrte_security -lrte_hash
EXPORT_MAP := rte_ipsec_version.map
-LIBABIVER := 1
+LIBABIVER := 2
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) += esp_inb.c
diff --git a/lib/librte_ipsec/meson.build b/lib/librte_ipsec/meson.build
index 70358526b..e8604dadd 100644
--- a/lib/librte_ipsec/meson.build
+++ b/lib/librte_ipsec/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2018 Intel Corporation
+version = 2
allow_experimental_apis = true
sources = files('esp_inb.c', 'esp_outb.c', 'sa.c', 'ses.c', 'ipsec_sad.c')
diff --git a/lib/librte_ipsec/rte_ipsec_sa.h b/lib/librte_ipsec/rte_ipsec_sa.h
index 47ce169d2..1cfde5874 100644
--- a/lib/librte_ipsec/rte_ipsec_sa.h
+++ b/lib/librte_ipsec/rte_ipsec_sa.h
@@ -47,12 +47,6 @@ struct rte_ipsec_sa_prm {
uint8_t proto; /**< next header protocol */
} trs; /**< transport mode related parameters */
};
-
- /**
- * window size to enable sequence replay attack handling.
- * replay checking is disabled if the window size is 0.
- */
- uint32_t replay_win_sz;
};
/**
diff --git a/lib/librte_ipsec/sa.c b/lib/librte_ipsec/sa.c
index 23d394b46..6f1d92c3c 100644
--- a/lib/librte_ipsec/sa.c
+++ b/lib/librte_ipsec/sa.c
@@ -439,7 +439,7 @@ rte_ipsec_sa_size(const struct rte_ipsec_sa_prm *prm)
return rc;
/* determine required size */
- wsz = prm->replay_win_sz;
+ wsz = prm->ipsec_xform.replay_win_sz;
return ipsec_sa_size(type, &wsz, &nb);
}
@@ -461,7 +461,7 @@ rte_ipsec_sa_init(struct rte_ipsec_sa *sa, const struct rte_ipsec_sa_prm *prm,
return rc;
/* determine required size */
- wsz = prm->replay_win_sz;
+ wsz = prm->ipsec_xform.replay_win_sz;
sz = ipsec_sa_size(type, &wsz, &nb);
if (sz < 0)
return sz;
--
2.17.1
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
2019-10-29 17:19 2% ` Slava Ovsiienko
2019-10-29 18:30 0% ` Thomas Monjalon
@ 2019-10-30 7:35 3% ` Andrew Rybchenko
2019-10-30 8:59 0% ` Slava Ovsiienko
1 sibling, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-10-30 7:35 UTC (permalink / raw)
To: Slava Ovsiienko, Thomas Monjalon, olivier.matz
Cc: dev, Matan Azrad, Ori Kam, Yongseok Koh
@Olivier, please, take a look at the end of the mail.
On 10/29/19 8:19 PM, Slava Ovsiienko wrote:
> Hi, Andrew
>
> Thank you for the review.
>
>> -----Original Message-----
>> From: Andrew Rybchenko <arybchenko@solarflare.com>
>> Sent: Tuesday, October 29, 2019 18:22
>> To: Slava Ovsiienko <viacheslavo@mellanox.com>; dev@dpdk.org
>> Cc: Thomas Monjalon <thomas@monjalon.net>; Matan Azrad
>> <matan@mellanox.com>; olivier.matz@6wind.com; Ori Kam
>> <orika@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
>> Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
>>
>> On 10/27/19 9:40 PM, Viacheslav Ovsiienko wrote:
>>> Currently, metadata can be set on egress path via mbuf tx_metadata
>>> field with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_META
>> matches metadata.
>>> This patch extends the metadata feature usability.
>>>
>>> 1) RTE_FLOW_ACTION_TYPE_SET_META
>>>
>>> When supporting multiple tables, Tx metadata can also be set by a rule
>>> and matched by another rule. This new action allows metadata to be set
>>> as a result of flow match.
>>>
>>> 2) Metadata on ingress
>>>
>>> There's also need to support metadata on ingress. Metadata can be set
>>> by SET_META action and matched by META item like Tx. The final value
>>> set by the action will be delivered to application via metadata
>>> dynamic field of mbuf which can be accessed by
>> RTE_FLOW_DYNF_METADATA().
>>> PKT_RX_DYNF_METADATA flag will be set along with the data.
>>>
>>> The mbuf dynamic field must be registered by calling
>>> rte_flow_dynf_metadata_register() prior to use SET_META action.
>>>
>>> The availability of dynamic mbuf metadata field can be checked with
>>> rte_flow_dynf_metadata_avail() routine.
>>>
>>> For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
>>> propagated to the other path depending on hardware capability.
>>>
>>> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
>>> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
>> Above explanations lack information about "meta" vs "mark" which may be
>> set on Rx as well and delivered in other mbuf field.
>> It should be explained by one more field is required and rules defined.
> There is some story about metadata features.
> Initially, there were proposed two metadata related actions:
>
> - RTE_FLOW_ACTION_TYPE_FLAG
> - RTE_FLOW_ACTION_TYPE_MARK
>
> These actions set the special flag in the packet metadata, MARK action stores some
> specified value in the metadata storage, and, on the packet receiving PMD puts the flag
> and value to the mbuf and applications can see the packet was threated inside flow engine
> according to the appropriate RTE flow(s). MARK and FLAG are like some kind of gateway
> to transfer some per-packet information from the flow engine to the application
> via receiving datapath.
>
> From the datapath point of view, the MARK and FLAG are related to the receiving side only.
> It would useful to have the same gateway on the transmitting side and there was the feature
> of type RTE_FLOW_ITEM_TYPE_META was proposed. The application can fill the field in mbuf
> and this value will be transferred to some field in the packet metadata inside the flow engine.
> It did not matter whether these metadata fields are shared because of MARK and META items
> belonged to different domains (receiving and transmitting) and could be vendor-specific.
>
> So far, so good, DPDK proposes some entities to control metadata inside the flow engine
> and gateways to exchange these values on a per-packet basis via datapaths.
>
> As we can see, the MARK and META means are not symmetric, there is absent action which
> would allow us to set META value on the transmitting path. So, the action of type:
> - RTE_FLOW_ACTION_TYPE_SET_META is proposed.
>
> The next, applications raise the new requirements for packet metadata. The flow engines are
> getting more complex, internal switches are introduced, multiple ports might be supported within
> the same flow engine namespace. From the DPDK points of view, it means the packets might be sent
> on one eth_dev port and received on the other one, and the packet path inside the flow engine entirely
> belongs to the same hardware device. The simplest example is SR-IOV with PF, VFs and the representors.
> And there is a brilliant opportunity to provide some out-of-band channel to transfer some extra data
> from one port to another one, besides the packet data itself.
>
>
>> Above explanations lack information about "meta" vs "mark" which may be
>> set on Rx as well and delivered in other mbuf field.
>> It should be explained by one more field is required and rules defined.
>> Otherwise we can endup in half PMDs supporting mark only, half PMDs
>> supporting meta only and applications in an interesting situation to make a
>> choice which one to use.
> There is no "mark" vs "meta". MARK and META means are kept for compatibility issues
> and legacy part works exactly as before. The trials (with flow_validate) is supposed
> to check whether PMD supports MARK or META feature on appropriate domain. It depends
> on PMD implementation, configuration and underlaying HW/FW/kernel capabilities and
> should be resolved in runtime.
The trials a way, but very tricky way. My imagination draws me
pictures how an application code could look like in attempt to use
either mark or meta for Rx only and these pictures are not nice.
May be it will look acceptable when mark becomes a dynamic
since usage of either one or another dynamic field is definitely
easier than usage of either fixed or dynamic field.
May be dynamic field for mark at fixed offset should be
introduced in the release or the nearest future? It will allow
to preserve ABI up to 20.11 and provide future proof API.
The trick is to register dynamic meta field at fixed offset
at start of a day to be sure that it is guaranteed to succeed.
It sounds like it is a transition mechanism from fixed to
dynamic fields.
[snip]
>>> diff --git a/lib/librte_ethdev/rte_flow.h
>>> b/lib/librte_ethdev/rte_flow.h index 4fee105..b821557 100644
>>> --- a/lib/librte_ethdev/rte_flow.h
>>> +++ b/lib/librte_ethdev/rte_flow.h
>>> @@ -28,6 +28,8 @@
>>> #include <rte_byteorder.h>
>>> #include <rte_esp.h>
>>> #include <rte_higig.h>
>>> +#include <rte_mbuf.h>
>>> +#include <rte_mbuf_dyn.h>
>>>
>>> #ifdef __cplusplus
>>> extern "C" {
>>> @@ -418,7 +420,8 @@ enum rte_flow_item_type {
>>> /**
>>> * [META]
>>> *
>>> - * Matches a metadata value specified in mbuf metadata field.
>>> + * Matches a metadata value.
>>> + *
>>> * See struct rte_flow_item_meta.
>>> */
>>> RTE_FLOW_ITEM_TYPE_META,
>>> @@ -1263,9 +1266,17 @@ struct rte_flow_item_icmp6_nd_opt_tla_eth {
>>> #endif
>>>
>>> /**
>>> - * RTE_FLOW_ITEM_TYPE_META.
>>> + * @warning
>>> + * @b EXPERIMENTAL: this structure may change without prior notice
>> Is it allowed to make experimental back?
> I think we should remove EXPERIMENTAL here. We do not introduce new
> feature, but just extend the apply area.
Agreed.
>>> *
>>> - * Matches a specified metadata value.
>>> + * RTE_FLOW_ITEM_TYPE_META
>>> + *
>>> + * Matches a specified metadata value. On egress, metadata can be set
>>> + either by
>>> + * mbuf tx_metadata field with PKT_TX_METADATA flag or
>>> + * RTE_FLOW_ACTION_TYPE_SET_META. On ingress,
>>> + RTE_FLOW_ACTION_TYPE_SET_META sets
>>> + * metadata for a packet and the metadata will be reported via mbuf
>>> + metadata
>>> + * dynamic field with PKT_RX_DYNF_METADATA flag. The dynamic mbuf
>>> + field must be
>>> + * registered in advance by rte_flow_dynf_metadata_register().
>>> */
>>> struct rte_flow_item_meta {
>>> rte_be32_t data;
>> [snip]
>>
>>> @@ -2429,6 +2447,55 @@ struct rte_flow_action_set_mac {
>>> uint8_t mac_addr[RTE_ETHER_ADDR_LEN];
>>> };
>>>
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this structure may change without prior notice
>>> + *
>>> + * RTE_FLOW_ACTION_TYPE_SET_META
>>> + *
>>> + * Set metadata. Metadata set by mbuf tx_metadata field with
>>> + * PKT_TX_METADATA flag on egress will be overridden by this action.
>>> +On
>>> + * ingress, the metadata will be carried by mbuf metadata dynamic
>>> +field
>>> + * with PKT_RX_DYNF_METADATA flag if set. The dynamic mbuf field
>>> +must be
>>> + * registered in advance by rte_flow_dynf_metadata_register().
>>> + *
>>> + * Altering partial bits is supported with mask. For bits which have
>>> +never
>>> + * been set, unpredictable value will be seen depending on driver
>>> + * implementation. For loopback/hairpin packet, metadata set on Rx/Tx
>>> +may
>>> + * or may not be propagated to the other path depending on HW
>> capability.
>>> + *
>>> + * RTE_FLOW_ITEM_TYPE_META matches metadata.
>>> + */
>>> +struct rte_flow_action_set_meta {
>>> + rte_be32_t data;
>>> + rte_be32_t mask;
>> As I understand tx_metadata is host endian. Just double-checking.
>> Is a new dynamic field host endian or big endian?
>> I definitely would like to see motivation in comments why data/mask are big-
>> endian here.
> metadata is opaque value, endianness does not matter, there are no some
> special motivations for choosing endiannes. rte_flow_item_meta() structure
> provides data with rte_be32_t type, so meta related action does the same.
Endianness of meta in mbuf and flow API should match and it must be
documented. Endianness is important if a HW supports less bits since
it makes a hit for application to use LSB first if the bit space is
sufficient.
mark is defined as host-endian (uint32_t) and I think meta should be the
same. Otherwise it complicates even more either mark or meta usage
as discussed above .
Yes, I think that rte_flow_item_meta should be fixed since both
mark and tx_metadata are host-endian.
(it says nothing about HW interface which is vendor specific and
vendor PMDs should care about it)
> I could assume the origin of selecting bigendian type was the endianness
> of metadata field in Tx descriptor of ConnectX NICs.
>
>>> +};
>>> +
>>> +/* Mbuf dynamic field offset for metadata. */ extern int
>>> +rte_flow_dynf_metadata_offs;
>>> +
>>> +/* Mbuf dynamic field flag mask for metadata. */ extern uint64_t
>>> +rte_flow_dynf_metadata_mask;
>> These two global variables look frightening to me.
>> It does not look good to me.
> For me too. But we need the performance, these ones are
> intended for usage in datapath, any overhead is painful.
@Olivier, could you share your thoughts, please.
Andrew.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from host
2019-10-30 4:08 0% ` Jerin Jacob
@ 2019-10-30 7:22 0% ` Shahaf Shuler
0 siblings, 0 replies; 200+ results
From: Shahaf Shuler @ 2019-10-30 7:22 UTC (permalink / raw)
To: Jerin Jacob, Thomas Monjalon, Stephen Hemminger,
Andrew Rybchenko, Ferruh Yigit
Cc: dpdk-dev
Wednesday, October 30, 2019 6:09 AM, Jerin Jacob:
> Subject: Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from
> host
>
> On Wed, Oct 30, 2019 at 12:21 AM Thomas Monjalon
> <thomas@monjalon.net> wrote:
> >
> > In a virtual environment, the network controller may have to configure
> > some SR-IOV VF parameters for security reasons.
>
> Just to understand, Could you explain more details/examples for security
> reasons?
>
> >
> > When the PF (host port) is driven by DPDK (OVS-DPDK case), we face two
> > different cases:
> > - driver is bifurcated (Mellanox case),
> > so the VF can be configured via the kernel.
> > - driver is on top of UIO or VFIO, so DPDK API is required,
>
> Not true. Both UIO and VFIO are NOT allowed to create SRIOV VF from the
> PF device.
> It is only allowed through igb-uio out of tree driver without iommu support.
Per my understanding Thomas proposal is not to create the VFs from the PF device. it is to configure their network attributes from the PF after they have been created.
>
>
> > and PMD-specific APIs were used.
> > This new generic API will avoid vendors fragmentation.
>
> The API is good. But I have concerns about the vendor implementation of
> this API.
> It can support only vendors with bifurcated driver(Mellanox case).
> or using igb_uio(non iommu case) but not the devices with VFIO(Which is the
> first-class citizen).
>
> All the control plane control stuff to replace Linux with "port representor"
> logic will be of the mercy of an "out of tree" driver either with igb_uio or
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> es.dpdk.org%2Fpatch%2F58810%2F&data=02%7C01%7Cshahafs%40mel
> lanox.com%7C8da6ffacecde48af24f608d75ceee28c%7Ca652971c7d2e4d9ba6
> a4d149256f461b%7C0%7C0%7C637080053397844419&sdata=sAIRqTnAN
> G8lIb2eYhvcylU%2F6%2F81eXPDeGbnrUdMnis%3D&reserved=0
I am not sure I follow.
Device that supports representor should enable the HV to configure their macs. It is the best if it can allow it using the in-tree drivers (VFIO, Mellanox bifurcated..) by using, for example, so device registers on the device bar.
Otherwise such vendor will need to recommend its customers to use other, out of tree, driver to get the needed functionality to enable switchdev and representors.
>
> I am _not against_ on DPDK supports port representor or controlling netdev
> VF traffic, but if we have taken that path then DPDK should have the
> infrastructure to support for all driver models like VFIO(Addressed in [1])
>
> I would have this question when DPDK starts supporting port
> representor(but I was not aware that kernel security issue on netdev ports
> controlled by DPDK in non-bifurcated driver case and concise effort block
> such scheme by kernel [2])
>
>
> [1]
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> es.dpdk.org%2Fpatch%2F58810%2F&data=02%7C01%7Cshahafs%40mel
> lanox.com%7C8da6ffacecde48af24f608d75ceee28c%7Ca652971c7d2e4d9ba6
> a4d149256f461b%7C0%7C0%7C637080053397844419&sdata=sAIRqTnAN
> G8lIb2eYhvcylU%2F6%2F81eXPDeGbnrUdMnis%3D&reserved=0
> [2]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fpatch%2F10522381%2F&data=02%7C01%7Cshahafs
> %40mellanox.com%7C8da6ffacecde48af24f608d75ceee28c%7Ca652971c7d2e
> 4d9ba6a4d149256f461b%7C0%7C0%7C637080053397844419&sdata=fyEo
> fHJQM51L8ssvLNyaLwrsCK8bBJiuPT%2FgMje3QxE%3D&reserved=0
>
>
>
> >
> > Some PMD-specific API could migrate to this generic model.
> > As an example, the default MAC address configuration is demonstrated
> > for a VF mapped to mlx5 representor port.
> >
> > As it breaks the ABI, I propose to merge this API in DPDK 19.11-rc2.
> >
> > I am sorry I had not send a patch since proposing a RFC in August.
> > (I gave priority to the summit and the -rc1 release)
> >
> >
> > Thomas Monjalon (3):
> > ethdev: identify SR-IOV VF from host
> > ethdev: set VF MAC address from host
> > net/mlx5: set VF MAC address from host
> >
> > drivers/net/mlx5/mlx5.c | 6 +++
> > drivers/net/mlx5/mlx5.h | 1 +
> > drivers/net/mlx5/mlx5_mac.c | 19 ++++++++
> > lib/librte_ethdev/rte_ethdev.c | 55 +++++++++++++++++++++---
> > lib/librte_ethdev/rte_ethdev.h | 38 ++++++++++++++++
> > lib/librte_ethdev/rte_ethdev_core.h | 1 +
> > lib/librte_ethdev/rte_ethdev_version.map | 1 +
> > 7 files changed, 114 insertions(+), 7 deletions(-)
> >
> > --
> > 2.23.0
> >
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 2/2] ipsec: remove redundant replay_win_sz
@ 2019-10-30 6:57 5% ` Hemant Agrawal
1 sibling, 0 replies; 200+ results
From: Hemant Agrawal @ 2019-10-30 6:57 UTC (permalink / raw)
To: dev, akhil.goyal; +Cc: konstantin.ananyev, Hemant Agrawal
The rte_security lib has introduced replay_win_sz,
so it can be removed from the rte_ipsec lib.
Also, the relaved tests,app are also update to reflect
the usages.
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
---
app/test/test_ipsec.c | 2 +-
doc/guides/rel_notes/release_19_11.rst | 10 ++++++++--
examples/ipsec-secgw/ipsec.c | 1 +
examples/ipsec-secgw/sa.c | 2 +-
lib/librte_ipsec/Makefile | 2 +-
lib/librte_ipsec/meson.build | 1 +
lib/librte_ipsec/rte_ipsec_sa.h | 6 ------
lib/librte_ipsec/sa.c | 4 ++--
8 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
index 4007eff19..9e3dabd93 100644
--- a/app/test/test_ipsec.c
+++ b/app/test/test_ipsec.c
@@ -689,7 +689,7 @@ fill_ipsec_param(uint32_t replay_win_sz, uint64_t flags)
prm->userdata = 1;
prm->flags = flags;
- prm->replay_win_sz = replay_win_sz;
+ prm->ipsec_xform.replay_win_sz = replay_win_sz;
/* setup ipsec xform */
prm->ipsec_xform = ut_params->ipsec_xform;
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index ae8e7b2f0..aa16c8422 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -365,6 +365,12 @@ ABI Changes
align the Ethernet header on receive and all known encapsulations
preserve the alignment of the header.
+* security: A new field ''replay_win_sz'' has been added to the structure
+ ``rte_security_ipsec_xform``, which specify the Anti replay window size
+ to enable sequence replay attack handling.
+
+* ipsec: The field ''replay_win_sz'' has been removed from the structure
+ ''rte_ipsec_sa_prm'' as it has been added to the security library.
Shared Library Versions
-----------------------
@@ -407,7 +413,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_gso.so.1
librte_hash.so.2
librte_ip_frag.so.1
- librte_ipsec.so.1
+ + librte_ipsec.so.2
librte_jobstats.so.1
librte_kni.so.2
librte_kvargs.so.1
@@ -437,7 +443,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_reorder.so.1
librte_ring.so.2
+ librte_sched.so.4
- librte_security.so.2
+ + librte_security.so.3
librte_stack.so.1
librte_table.so.3
librte_timer.so.1
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 51fb22e8a..159e81f99 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -49,6 +49,7 @@ set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
/* TODO support for Transport */
}
ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
+ ipsec->replay_win_sz = app_sa_prm.window_size;
}
int
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 14ee94731..46cdc1241 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -1055,7 +1055,7 @@ fill_ipsec_app_sa_prm(struct rte_ipsec_sa_prm *prm,
prm->flags = app_prm->flags;
prm->ipsec_xform.options.esn = app_prm->enable_esn;
- prm->replay_win_sz = app_prm->window_size;
+ prm->ipsec_xform.replay_win_sz = app_prm->replay_win_sz;
}
static int
diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile
index 81fb99980..161ea9e3d 100644
--- a/lib/librte_ipsec/Makefile
+++ b/lib/librte_ipsec/Makefile
@@ -14,7 +14,7 @@ LDLIBS += -lrte_cryptodev -lrte_security -lrte_hash
EXPORT_MAP := rte_ipsec_version.map
-LIBABIVER := 1
+LIBABIVER := 2
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) += esp_inb.c
diff --git a/lib/librte_ipsec/meson.build b/lib/librte_ipsec/meson.build
index 70358526b..e8604dadd 100644
--- a/lib/librte_ipsec/meson.build
+++ b/lib/librte_ipsec/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2018 Intel Corporation
+version = 2
allow_experimental_apis = true
sources = files('esp_inb.c', 'esp_outb.c', 'sa.c', 'ses.c', 'ipsec_sad.c')
diff --git a/lib/librte_ipsec/rte_ipsec_sa.h b/lib/librte_ipsec/rte_ipsec_sa.h
index 47ce169d2..1cfde5874 100644
--- a/lib/librte_ipsec/rte_ipsec_sa.h
+++ b/lib/librte_ipsec/rte_ipsec_sa.h
@@ -47,12 +47,6 @@ struct rte_ipsec_sa_prm {
uint8_t proto; /**< next header protocol */
} trs; /**< transport mode related parameters */
};
-
- /**
- * window size to enable sequence replay attack handling.
- * replay checking is disabled if the window size is 0.
- */
- uint32_t replay_win_sz;
};
/**
diff --git a/lib/librte_ipsec/sa.c b/lib/librte_ipsec/sa.c
index 23d394b46..6f1d92c3c 100644
--- a/lib/librte_ipsec/sa.c
+++ b/lib/librte_ipsec/sa.c
@@ -439,7 +439,7 @@ rte_ipsec_sa_size(const struct rte_ipsec_sa_prm *prm)
return rc;
/* determine required size */
- wsz = prm->replay_win_sz;
+ wsz = prm->ipsec_xform.replay_win_sz;
return ipsec_sa_size(type, &wsz, &nb);
}
@@ -461,7 +461,7 @@ rte_ipsec_sa_init(struct rte_ipsec_sa *sa, const struct rte_ipsec_sa_prm *prm,
return rc;
/* determine required size */
- wsz = prm->replay_win_sz;
+ wsz = prm->ipsec_xform.replay_win_sz;
sz = ipsec_sa_size(type, &wsz, &nb);
if (sz < 0)
return sz;
--
2.17.1
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
2019-10-29 18:30 0% ` Thomas Monjalon
2019-10-29 18:35 0% ` Slava Ovsiienko
@ 2019-10-30 6:28 0% ` Andrew Rybchenko
1 sibling, 0 replies; 200+ results
From: Andrew Rybchenko @ 2019-10-30 6:28 UTC (permalink / raw)
To: Thomas Monjalon, Slava Ovsiienko; +Cc: dev, Matan Azrad, olivier.matz, Ori Kam
On 10/29/19 9:30 PM, Thomas Monjalon wrote:
> 29/10/2019 18:19, Slava Ovsiienko:
>> From: Andrew Rybchenko <arybchenko@solarflare.com>
>>>> --- a/doc/guides/rel_notes/deprecation.rst
>>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>>> +* ethdev: DEV_TX_OFFLOAD_MATCH_METADATA will be removed, static
>>>> +metadata
>>>> + mbuf field will be removed in 20.02, metadata feature will use
>>>> +dynamic mbuf
>>>> + field and flag instead.
>>>> +
>>> Isn't it breaking stable API/ABI? Should target release be 20.11?
>> tx_metadata is in union, it should not be ABI break.
>> And we propose to remove tx_metadata at all in 19.11
>> and share the dynamic metadata field between Rx and Tx METAdata.
> Yes please, let's remove tx_metadata from mbuf now,
> while adding metadata dynamic field.
> I am sure nobody will complain that we sanitized this feature
> before releasing DPDK 19.11 LTS.
OK for me.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from host
2019-10-29 18:50 3% ` [dpdk-dev] [PATCH v2 0/3] " Thomas Monjalon
@ 2019-10-30 4:08 0% ` Jerin Jacob
2019-10-30 7:22 0% ` Shahaf Shuler
2019-10-30 15:07 0% ` Ilya Maximets
1 sibling, 1 reply; 200+ results
From: Jerin Jacob @ 2019-10-30 4:08 UTC (permalink / raw)
To: Thomas Monjalon, Stephen Hemminger, Andrew Rybchenko, Ferruh Yigit
Cc: dpdk-dev
On Wed, Oct 30, 2019 at 12:21 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> In a virtual environment, the network controller may have to configure
> some SR-IOV VF parameters for security reasons.
Just to understand, Could you explain more details/examples for
security reasons?
>
> When the PF (host port) is driven by DPDK (OVS-DPDK case),
> we face two different cases:
> - driver is bifurcated (Mellanox case),
> so the VF can be configured via the kernel.
> - driver is on top of UIO or VFIO, so DPDK API is required,
Not true. Both UIO and VFIO are NOT allowed to create SRIOV VF from
the PF device.
It is only allowed through igb-uio out of tree driver without iommu support.
> and PMD-specific APIs were used.
> This new generic API will avoid vendors fragmentation.
The API is good. But I have concerns about the vendor implementation
of this API.
It can support only vendors with bifurcated driver(Mellanox case).
or using igb_uio(non iommu case) but not the devices with VFIO(Which
is the first-class citizen).
All the control plane control stuff to replace Linux with "port
representor" logic
will be of the mercy of an "out of tree" driver either with igb_uio
or http://patches.dpdk.org/patch/58810/
I am _not against_ on DPDK supports port representor or controlling
netdev VF traffic,
but if we have taken that path then DPDK should have the
infrastructure to support for
all driver models like VFIO(Addressed in [1])
I would have this question when DPDK starts supporting port
representor(but I was not
aware that kernel security issue on netdev ports controlled by DPDK in
non-bifurcated driver case
and concise effort block such scheme by kernel [2])
[1]
http://patches.dpdk.org/patch/58810/
[2]
https://patchwork.kernel.org/patch/10522381/
>
> Some PMD-specific API could migrate to this generic model.
> As an example, the default MAC address configuration is demonstrated
> for a VF mapped to mlx5 representor port.
>
> As it breaks the ABI, I propose to merge this API in DPDK 19.11-rc2.
>
> I am sorry I had not send a patch since proposing a RFC in August.
> (I gave priority to the summit and the -rc1 release)
>
>
> Thomas Monjalon (3):
> ethdev: identify SR-IOV VF from host
> ethdev: set VF MAC address from host
> net/mlx5: set VF MAC address from host
>
> drivers/net/mlx5/mlx5.c | 6 +++
> drivers/net/mlx5/mlx5.h | 1 +
> drivers/net/mlx5/mlx5_mac.c | 19 ++++++++
> lib/librte_ethdev/rte_ethdev.c | 55 +++++++++++++++++++++---
> lib/librte_ethdev/rte_ethdev.h | 38 ++++++++++++++++
> lib/librte_ethdev/rte_ethdev_core.h | 1 +
> lib/librte_ethdev/rte_ethdev_version.map | 1 +
> 7 files changed, 114 insertions(+), 7 deletions(-)
>
> --
> 2.23.0
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from host
@ 2019-10-29 18:50 3% ` Thomas Monjalon
2019-10-30 4:08 0% ` Jerin Jacob
2019-10-30 15:07 0% ` Ilya Maximets
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-10-29 18:50 UTC (permalink / raw)
Cc: dev
In a virtual environment, the network controller may have to configure
some SR-IOV VF parameters for security reasons.
When the PF (host port) is driven by DPDK (OVS-DPDK case),
we face two different cases:
- driver is bifurcated (Mellanox case),
so the VF can be configured via the kernel.
- driver is on top of UIO or VFIO, so DPDK API is required,
and PMD-specific APIs were used.
This new generic API will avoid vendors fragmentation.
Some PMD-specific API could migrate to this generic model.
As an example, the default MAC address configuration is demonstrated
for a VF mapped to mlx5 representor port.
As it breaks the ABI, I propose to merge this API in DPDK 19.11-rc2.
I am sorry I had not send a patch since proposing a RFC in August.
(I gave priority to the summit and the -rc1 release)
Thomas Monjalon (3):
ethdev: identify SR-IOV VF from host
ethdev: set VF MAC address from host
net/mlx5: set VF MAC address from host
drivers/net/mlx5/mlx5.c | 6 +++
drivers/net/mlx5/mlx5.h | 1 +
drivers/net/mlx5/mlx5_mac.c | 19 ++++++++
lib/librte_ethdev/rte_ethdev.c | 55 +++++++++++++++++++++---
lib/librte_ethdev/rte_ethdev.h | 38 ++++++++++++++++
lib/librte_ethdev/rte_ethdev_core.h | 1 +
lib/librte_ethdev/rte_ethdev_version.map | 1 +
7 files changed, 114 insertions(+), 7 deletions(-)
--
2.23.0
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
2019-10-29 18:30 0% ` Thomas Monjalon
@ 2019-10-29 18:35 0% ` Slava Ovsiienko
2019-10-30 6:28 0% ` Andrew Rybchenko
1 sibling, 0 replies; 200+ results
From: Slava Ovsiienko @ 2019-10-29 18:35 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Andrew Rybchenko, dev, Matan Azrad, olivier.matz, Ori Kam
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, October 29, 2019 20:30
> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> Cc: Andrew Rybchenko <arybchenko@solarflare.com>; dev@dpdk.org;
> Matan Azrad <matan@mellanox.com>; olivier.matz@6wind.com; Ori Kam
> <orika@mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
>
> 29/10/2019 18:19, Slava Ovsiienko:
> > From: Andrew Rybchenko <arybchenko@solarflare.com>
> > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > +* ethdev: DEV_TX_OFFLOAD_MATCH_METADATA will be removed,
> static
> > > > +metadata
> > > > + mbuf field will be removed in 20.02, metadata feature will use
> > > > +dynamic mbuf
> > > > + field and flag instead.
> > > > +
> > >
> > > Isn't it breaking stable API/ABI? Should target release be 20.11?
> >
> > tx_metadata is in union, it should not be ABI break.
> > And we propose to remove tx_metadata at all in 19.11 and share the
> > dynamic metadata field between Rx and Tx METAdata.
>
> Yes please, let's remove tx_metadata from mbuf now, while adding
> metadata dynamic field.
> I am sure nobody will complain that we sanitized this feature before
> releasing DPDK 19.11 LTS.
OK, I'll extend this patch to small series and update tx_metadata in the
dedicated commit (to simplify reviewing either).
With best regards, Slava
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
2019-10-29 17:19 2% ` Slava Ovsiienko
@ 2019-10-29 18:30 0% ` Thomas Monjalon
2019-10-29 18:35 0% ` Slava Ovsiienko
2019-10-30 6:28 0% ` Andrew Rybchenko
2019-10-30 7:35 3% ` Andrew Rybchenko
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-10-29 18:30 UTC (permalink / raw)
To: Slava Ovsiienko; +Cc: Andrew Rybchenko, dev, Matan Azrad, olivier.matz, Ori Kam
29/10/2019 18:19, Slava Ovsiienko:
> From: Andrew Rybchenko <arybchenko@solarflare.com>
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > +* ethdev: DEV_TX_OFFLOAD_MATCH_METADATA will be removed, static
> > > +metadata
> > > + mbuf field will be removed in 20.02, metadata feature will use
> > > +dynamic mbuf
> > > + field and flag instead.
> > > +
> >
> > Isn't it breaking stable API/ABI? Should target release be 20.11?
>
> tx_metadata is in union, it should not be ABI break.
> And we propose to remove tx_metadata at all in 19.11
> and share the dynamic metadata field between Rx and Tx METAdata.
Yes please, let's remove tx_metadata from mbuf now,
while adding metadata dynamic field.
I am sure nobody will complain that we sanitized this feature
before releasing DPDK 19.11 LTS.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
2019-10-29 16:22 3% ` Andrew Rybchenko
@ 2019-10-29 17:19 2% ` Slava Ovsiienko
2019-10-29 18:30 0% ` Thomas Monjalon
2019-10-30 7:35 3% ` Andrew Rybchenko
0 siblings, 2 replies; 200+ results
From: Slava Ovsiienko @ 2019-10-29 17:19 UTC (permalink / raw)
To: Andrew Rybchenko, dev
Cc: Thomas Monjalon, Matan Azrad, olivier.matz, Ori Kam, Yongseok Koh
Hi, Andrew
Thank you for the review.
> -----Original Message-----
> From: Andrew Rybchenko <arybchenko@solarflare.com>
> Sent: Tuesday, October 29, 2019 18:22
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; dev@dpdk.org
> Cc: Thomas Monjalon <thomas@monjalon.net>; Matan Azrad
> <matan@mellanox.com>; olivier.matz@6wind.com; Ori Kam
> <orika@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
>
> On 10/27/19 9:40 PM, Viacheslav Ovsiienko wrote:
> > Currently, metadata can be set on egress path via mbuf tx_metadata
> > field with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_META
> matches metadata.
> >
> > This patch extends the metadata feature usability.
> >
> > 1) RTE_FLOW_ACTION_TYPE_SET_META
> >
> > When supporting multiple tables, Tx metadata can also be set by a rule
> > and matched by another rule. This new action allows metadata to be set
> > as a result of flow match.
> >
> > 2) Metadata on ingress
> >
> > There's also need to support metadata on ingress. Metadata can be set
> > by SET_META action and matched by META item like Tx. The final value
> > set by the action will be delivered to application via metadata
> > dynamic field of mbuf which can be accessed by
> RTE_FLOW_DYNF_METADATA().
> > PKT_RX_DYNF_METADATA flag will be set along with the data.
> >
> > The mbuf dynamic field must be registered by calling
> > rte_flow_dynf_metadata_register() prior to use SET_META action.
> >
> > The availability of dynamic mbuf metadata field can be checked with
> > rte_flow_dynf_metadata_avail() routine.
> >
> > For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
> > propagated to the other path depending on hardware capability.
> >
> > Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> > Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
>
> Above explanations lack information about "meta" vs "mark" which may be
> set on Rx as well and delivered in other mbuf field.
> It should be explained by one more field is required and rules defined.
There is some story about metadata features.
Initially, there were proposed two metadata related actions:
- RTE_FLOW_ACTION_TYPE_FLAG
- RTE_FLOW_ACTION_TYPE_MARK
These actions set the special flag in the packet metadata, MARK action stores some
specified value in the metadata storage, and, on the packet receiving PMD puts the flag
and value to the mbuf and applications can see the packet was threated inside flow engine
according to the appropriate RTE flow(s). MARK and FLAG are like some kind of gateway
to transfer some per-packet information from the flow engine to the application
via receiving datapath.
From the datapath point of view, the MARK and FLAG are related to the receiving side only.
It would useful to have the same gateway on the transmitting side and there was the feature
of type RTE_FLOW_ITEM_TYPE_META was proposed. The application can fill the field in mbuf
and this value will be transferred to some field in the packet metadata inside the flow engine.
It did not matter whether these metadata fields are shared because of MARK and META items
belonged to different domains (receiving and transmitting) and could be vendor-specific.
So far, so good, DPDK proposes some entities to control metadata inside the flow engine
and gateways to exchange these values on a per-packet basis via datapaths.
As we can see, the MARK and META means are not symmetric, there is absent action which
would allow us to set META value on the transmitting path. So, the action of type:
- RTE_FLOW_ACTION_TYPE_SET_META is proposed.
The next, applications raise the new requirements for packet metadata. The flow engines are
getting more complex, internal switches are introduced, multiple ports might be supported within
the same flow engine namespace. From the DPDK points of view, it means the packets might be sent
on one eth_dev port and received on the other one, and the packet path inside the flow engine entirely
belongs to the same hardware device. The simplest example is SR-IOV with PF, VFs and the representors.
And there is a brilliant opportunity to provide some out-of-band channel to transfer some extra data
from one port to another one, besides the packet data itself.
> Above explanations lack information about "meta" vs "mark" which may be
> set on Rx as well and delivered in other mbuf field.
> It should be explained by one more field is required and rules defined.
> Otherwise we can endup in half PMDs supporting mark only, half PMDs
> supporting meta only and applications in an interesting situation to make a
> choice which one to use.
There is no "mark" vs "meta". MARK and META means are kept for compatibility issues
and legacy part works exactly as before. The trials (with flow_validate) is supposed
to check whether PMD supports MARK or META feature on appropriate domain. It depends
on PMD implementation, configuration and underlaying HW/FW/kernel capabilities and
should be resolved in runtime.
>
> [snip]
>
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > index 159ce19..c943aca 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -658,6 +658,32 @@ the physical device, with virtual groups in the
> PMD or not at all.
> > | ``mask`` | ``id`` | zeroed to match any value |
> > +----------+----------+---------------------------+
> >
> > +Item: ``META``
> > +^^^^^^^^^^^^^^^^^
> > +
> > +Matches 32 bit metadata item set.
> > +
> > +On egress, metadata can be set either by mbuf metadata field with
> > +PKT_TX_METADATA flag or ``SET_META`` action. On ingress,
> ``SET_META``
> > +action sets metadata for a packet and the metadata will be reported
> > +via ``metadata`` dynamic field of ``rte_mbuf`` with
> PKT_RX_DYNF_METADATA flag.
> > +
> > +- Default ``mask`` matches the specified Rx metadata value.
> > +
> > +.. _table_rte_flow_item_meta:
> > +
> > +.. table:: META
> > +
> > + +----------+----------+---------------------------------------+
> > + | Field | Subfield | Value |
> > +
> +==========+==========+=======================================
> +
> > + | ``spec`` | ``data`` | 32 bit metadata value |
> > + +----------+----------+---------------------------------------+
> > + | ``last`` | ``data`` | upper range value |
> > + +----------+----------+---------------------------------------+
> > + | ``mask`` | ``data`` | bit-mask applies to "spec" and "last" |
> > + +----------+----------+---------------------------------------+
> > +
> > Data matching item types
> > ~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > @@ -1232,21 +1258,6 @@ Matches a PPPoE session protocol identifier.
> > - ``proto_id``: PPP protocol identifier.
> > - Default ``mask`` matches proto_id only.
> >
> > -
> > -.. _table_rte_flow_item_meta:
> > -
> > -.. table:: META
> > -
> > - +----------+----------+---------------------------------------+
> > - | Field | Subfield | Value |
> > -
> +==========+==========+=======================================
> +
> > - | ``spec`` | ``data`` | 32 bit metadata value |
> > - +----------+--------------------------------------------------+
> > - | ``last`` | ``data`` | upper range value |
> > - +----------+----------+---------------------------------------+
> > - | ``mask`` | ``data`` | bit-mask applies to "spec" and "last" |
> > - +----------+----------+---------------------------------------+
> > -
> > Item: ``NSH``
> > ^^^^^^^^^^^^^
> >
> > @@ -2466,6 +2477,37 @@ Value to decrease TCP acknowledgment
> number by is a big-endian 32 bit integer.
> >
> > Using this action on non-matching traffic will result in undefined behavior.
> >
> > +Action: ``SET_META``
> > +^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Set metadata. Item ``META`` matches metadata.
> > +
> > +Metadata set by mbuf metadata field with PKT_TX_METADATA flag on
> > +egress will be overridden by this action. On ingress, the metadata
> > +will be carried by ``metadata`` dynamic field of ``rte_mbuf`` which
> > +can be accessed by ``RTE_FLOW_DYNF_METADATA()``.
> PKT_RX_DYNF_METADATA
> > +flag will be set along with the data.
> > +
> > +The mbuf dynamic field must be registered by calling
> > +``rte_flow_dynf_metadata_register()`` prior to use ``SET_META`` action.
> > +
> > +Altering partial bits is supported with ``mask``. For bits which have
> > +never been set, unpredictable value will be seen depending on driver
> > +implementation. For loopback/hairpin packet, metadata set on Rx/Tx
> > +may or may not be propagated to the other path depending on HW
> capability.
> > +
> > +.. _table_rte_flow_action_set_meta:
> > +
> > +.. table:: SET_META
> > +
> > + +----------+----------------------------+
> > + | Field | Value |
> > + +==========+============================+
> > + | ``data`` | 32 bit metadata value |
> > + +----------+----------------------------+
> > + | ``mask`` | bit-mask applies to "data" |
> > + +----------+----------------------------+
> > +
> > Negative types
> > ~~~~~~~~~~~~~~
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index 3aa1634..9d54d8e 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -106,6 +106,10 @@ Deprecation Notices
> > struct ``rte_eth_dev_info`` for the port capability and in struct
> > ``rte_eth_rxmode`` for the port configuration.
> >
> > +* ethdev: DEV_TX_OFFLOAD_MATCH_METADATA will be removed, static
> > +metadata
> > + mbuf field will be removed in 20.02, metadata feature will use
> > +dynamic mbuf
> > + field and flag instead.
> > +
>
> Isn't it breaking stable API/ABI? Should target release be 20.11?
tx_metadata is in union, it should not be ABI break.
And we propose to remove tx_metadata at all in 19.11
and share the dynamic metadata field between Rx and Tx METAdata.
> I think that DEV_TX_OFFLOAD_MATCH_METADATA should marked as
> deprecated now as well as tx_metadata field in mbuf.
>
> > * cryptodev: support for using IV with all sizes is added, J0 still can
> > be used but only when IV length in following structs
> ``rte_crypto_auth_xform``,
> > ``rte_crypto_aead_xform`` is set to zero. When IV length is
> > greater or equal diff --git a/doc/guides/rel_notes/release_19_11.rst
> > b/doc/guides/rel_notes/release_19_11.rst
> > index 0e5bb5d..6d331f6 100644
> > --- a/doc/guides/rel_notes/release_19_11.rst
> > +++ b/doc/guides/rel_notes/release_19_11.rst
> > @@ -232,6 +232,21 @@ New Features
> > gives ability to print port supported ptypes in different protocol layers.
> >
> >
> > +* **Add support of support dynamic fields and flags in mbuf.**
> > +
> > + This new feature adds the ability to dynamically register some room
> > + for a field or a flag in the mbuf structure. This is typically used
> > + for specific offload features, where adding a static field or flag
> > + in the mbuf is not justified.
> > +
>
> I guess above is just incorrect merge.
Oops, thanks for spotting,
>
> > +* **Extended metadata support in rte_flow.**
> > +
> > + Flow metadata is extended to both Rx and Tx.
> > +
> > + * Tx metadata can also be set by SET_META action of rte_flow.
> > + * Rx metadata is delivered to host via a dynamic field of ``rte_mbuf``
> with
> > + PKT_RX_DYNF_METADATA.
> > +
>
> Two empty lines are required before the next section.
Accepted.
>
> > Removed Items
> > -------------
> >
> > diff --git a/lib/librte_ethdev/rte_ethdev.h
> > b/lib/librte_ethdev/rte_ethdev.h index c36c1b6..b19c86b 100644
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > @@ -1048,7 +1048,6 @@ struct rte_eth_conf {
> > #define DEV_RX_OFFLOAD_KEEP_CRC 0x00010000
> > #define DEV_RX_OFFLOAD_SCTP_CKSUM 0x00020000
> > #define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM 0x00040000
> > -
OK, accepted.
>
> Unrelated change.
>
> > #define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM
> | \
> > DEV_RX_OFFLOAD_UDP_CKSUM | \
> > DEV_RX_OFFLOAD_TCP_CKSUM)
>
> [snip]
>
> > diff --git a/lib/librte_ethdev/rte_flow.c
> > b/lib/librte_ethdev/rte_flow.c index ca0f680..6090177 100644
> > --- a/lib/librte_ethdev/rte_flow.c
> > +++ b/lib/librte_ethdev/rte_flow.c
> > @@ -12,10 +12,18 @@
> > #include <rte_errno.h>
> > #include <rte_branch_prediction.h>
> > #include <rte_string_fns.h>
> > +#include <rte_mbuf.h>
> > +#include <rte_mbuf_dyn.h>
> > #include "rte_ethdev.h"
> > #include "rte_flow_driver.h"
> > #include "rte_flow.h"
> >
> > +/* Mbuf dynamic field name for metadata. */ int
> > +rte_flow_dynf_metadata_offs = -1;
> > +
> > +/* Mbuf dynamic field flag bit number for metadata. */ uint64_t
> > +rte_flow_dynf_metadata_mask;
> > +
> > /**
> > * Flow elements description tables.
> > */
> > @@ -157,8 +165,41 @@ struct rte_flow_desc_data {
> > MK_FLOW_ACTION(DEC_TCP_SEQ, sizeof(rte_be32_t)),
> > MK_FLOW_ACTION(INC_TCP_ACK, sizeof(rte_be32_t)),
> > MK_FLOW_ACTION(DEC_TCP_ACK, sizeof(rte_be32_t)),
> > + MK_FLOW_ACTION(SET_META, sizeof(struct
> rte_flow_action_set_meta)),
> > };
> >
> > +int
> > +rte_flow_dynf_metadata_register(void)
> > +{
> > + int offset;
> > + int flag;
> > +
> > + static const struct rte_mbuf_dynfield desc_offs = {
> > + .name = MBUF_DYNF_METADATA_NAME,
> > + .size = sizeof(uint32_t),
> > + .align = __alignof__(uint32_t),
> > + .flags = 0,
>
> I think flags initialization to 0 is redundant.
It was left just for reminding that field exist. Do you think we do not need the reminding? OK.
>
> > + };
> > + static const struct rte_mbuf_dynflag desc_flag = {
> > + .name = MBUF_DYNF_METADATA_NAME,
> > + };
> > +
> > + offset = rte_mbuf_dynfield_register(&desc_offs);
> > + if (offset < 0)
> > + goto error;
> > + flag = rte_mbuf_dynflag_register(&desc_flag);
> > + if (flag < 0)
> > + goto error;
> > + rte_flow_dynf_metadata_offs = offset;
> > + rte_flow_dynf_metadata_mask = (1ULL << flag);
> > + return 0;
> > +
> > +error:
>
> Just an observation...
> Impossibility to unregister hits here. Field may be registered, but will be used.
Metadata field is useless without flag. Yes, we have no opportunity to unregister,
so we just forget about "field with no flag" and that's it.
>
> > + rte_flow_dynf_metadata_offs = -1;
> > + rte_flow_dynf_metadata_mask = 0ULL;
> > + return -rte_errno;
> > +}
> > +
> > static int
> > flow_err(uint16_t port_id, int ret, struct rte_flow_error *error)
> > {
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index 4fee105..b821557 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -28,6 +28,8 @@
> > #include <rte_byteorder.h>
> > #include <rte_esp.h>
> > #include <rte_higig.h>
> > +#include <rte_mbuf.h>
> > +#include <rte_mbuf_dyn.h>
> >
> > #ifdef __cplusplus
> > extern "C" {
> > @@ -418,7 +420,8 @@ enum rte_flow_item_type {
> > /**
> > * [META]
> > *
> > - * Matches a metadata value specified in mbuf metadata field.
> > + * Matches a metadata value.
> > + *
> > * See struct rte_flow_item_meta.
> > */
> > RTE_FLOW_ITEM_TYPE_META,
> > @@ -1263,9 +1266,17 @@ struct rte_flow_item_icmp6_nd_opt_tla_eth {
> > #endif
> >
> > /**
> > - * RTE_FLOW_ITEM_TYPE_META.
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
>
> Is it allowed to make experimental back?
I think we should remove EXPERIMENTAL here. We do not introduce new
feature, but just extend the apply area.
>
> > *
> > - * Matches a specified metadata value.
> > + * RTE_FLOW_ITEM_TYPE_META
> > + *
> > + * Matches a specified metadata value. On egress, metadata can be set
> > + either by
> > + * mbuf tx_metadata field with PKT_TX_METADATA flag or
> > + * RTE_FLOW_ACTION_TYPE_SET_META. On ingress,
> > + RTE_FLOW_ACTION_TYPE_SET_META sets
> > + * metadata for a packet and the metadata will be reported via mbuf
> > + metadata
> > + * dynamic field with PKT_RX_DYNF_METADATA flag. The dynamic mbuf
> > + field must be
> > + * registered in advance by rte_flow_dynf_metadata_register().
> > */
> > struct rte_flow_item_meta {
> > rte_be32_t data;
>
> [snip]
>
> > @@ -2429,6 +2447,55 @@ struct rte_flow_action_set_mac {
> > uint8_t mac_addr[RTE_ETHER_ADDR_LEN];
> > };
> >
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * RTE_FLOW_ACTION_TYPE_SET_META
> > + *
> > + * Set metadata. Metadata set by mbuf tx_metadata field with
> > + * PKT_TX_METADATA flag on egress will be overridden by this action.
> > +On
> > + * ingress, the metadata will be carried by mbuf metadata dynamic
> > +field
> > + * with PKT_RX_DYNF_METADATA flag if set. The dynamic mbuf field
> > +must be
> > + * registered in advance by rte_flow_dynf_metadata_register().
> > + *
> > + * Altering partial bits is supported with mask. For bits which have
> > +never
> > + * been set, unpredictable value will be seen depending on driver
> > + * implementation. For loopback/hairpin packet, metadata set on Rx/Tx
> > +may
> > + * or may not be propagated to the other path depending on HW
> capability.
> > + *
> > + * RTE_FLOW_ITEM_TYPE_META matches metadata.
> > + */
> > +struct rte_flow_action_set_meta {
> > + rte_be32_t data;
> > + rte_be32_t mask;
>
> As I understand tx_metadata is host endian. Just double-checking.
> Is a new dynamic field host endian or big endian?
> I definitely would like to see motivation in comments why data/mask are big-
> endian here.
metadata is opaque value, endianness does not matter, there are no some
special motivations for choosing endiannes. rte_flow_item_meta() structure
provides data with rte_be32_t type, so meta related action does the same.
I could assume the origin of selecting bigendian type was the endianness
of metadata field in Tx descriptor of ConnectX NICs.
>
> > +};
> > +
> > +/* Mbuf dynamic field offset for metadata. */ extern int
> > +rte_flow_dynf_metadata_offs;
> > +
> > +/* Mbuf dynamic field flag mask for metadata. */ extern uint64_t
> > +rte_flow_dynf_metadata_mask;
>
> These two global variables look frightening to me.
> It does not look good to me.
For me too. But we need the performance, these ones are
intended for usage in datapath, any overhead is painful.
>
> > +
> > +/* Mbuf dynamic field pointer for metadata. */ #define
> > +RTE_FLOW_DYNF_METADATA(m) \
> > + RTE_MBUF_DYNFIELD((m), rte_flow_dynf_metadata_offs, uint32_t
> *)
> > +
> > +/* Mbuf dynamic flag for metadata. */ #define PKT_RX_DYNF_METADATA
> > +(rte_flow_dynf_metadata_mask)
> > +
> > +__rte_experimental
> > +static inline uint32_t
> > +rte_flow_dynf_metadata_get(struct rte_mbuf *m) {
>
> Above curly bracket should be on its own line in the case of function
> definition.
>
> Shouldn't m be 'const struct rte_mbuf *'?
You are right, it would be better, will update.
>
> > + return *RTE_FLOW_DYNF_METADATA(m);
> > +}
> > +
> > +__rte_experimental
> > +static inline void
> > +rte_flow_dynf_metadata_set(struct rte_mbuf *m, uint32_t v) {
>
> Above curly bracket should be on its own line in the case of function
> definition.
>
> > + *RTE_FLOW_DYNF_METADATA(m) = v;
> > +}
> > +
> > /*
> > * Definition of a single action.
> > *
> > @@ -2662,6 +2729,32 @@ enum rte_flow_conv_op {
> > };
> >
> > /**
> > + * Check if mbuf dynamic field for metadata is registered.
> > + *
> > + * @return
> > + * True if registered, false otherwise.
> > + */
> > +__rte_experimental
> > +static inline int
> > +rte_flow_dynf_metadata_avail(void) {
>
> Above curly bracket should be on its own line in the case of function
> definition.
>
> > + return !!rte_flow_dynf_metadata_mask; }
> > +
> > +/**
> > + * Register mbuf dynamic field and flag for metadata.
> > + *
> > + * This function must be called prior to use SET_META action in order
> > +to
> > + * register the dynamic mbuf field. Otherwise, the data cannot be
> > +delivered to
> > + * application.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +__rte_experimental
> > +int
> > +rte_flow_dynf_metadata_register(void);
> > +
> > +/**
> > * Check whether a flow rule can be created on a given port.
> > *
> > * The flow rule is validated for correctness and whether it could
> > be accepted diff --git a/lib/librte_mbuf/rte_mbuf_dyn.h
> > b/lib/librte_mbuf/rte_mbuf_dyn.h index 2e9d418..a4a0cf5 100644
> > --- a/lib/librte_mbuf/rte_mbuf_dyn.h
> > +++ b/lib/librte_mbuf/rte_mbuf_dyn.h
> > @@ -234,6 +234,10 @@ int rte_mbuf_dynflag_lookup(const char *name,
> > __rte_experimental
> > void rte_mbuf_dyn_dump(FILE *out);
> >
> > -/* Placeholder for dynamic fields and flags declarations. */
> > -
> > +/*
> > + * Placeholder for dynamic fields and flags declarations.
> > + * This is centralizing point to gather all field names
> > + * and parameters together.
> > + */
>
> It is not a comment for below define. So, I think empty line is required to
> separate the comment from below define.
> I'm not sure that the clarification is required, but it is up to Olivier.
>
> > +#define MBUF_DYNF_METADATA_NAME "rte_flow_dynfield_metadata"
>
> Empty line is missing here
Thanks, will add one.
>
> > #endif
With best regards, Slava
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
@ 2019-10-29 16:22 3% ` Andrew Rybchenko
2019-10-29 17:19 2% ` Slava Ovsiienko
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-10-29 16:22 UTC (permalink / raw)
To: Viacheslav Ovsiienko, dev
Cc: thomas, matan, olivier.matz, orika, Yongseok Koh
On 10/27/19 9:40 PM, Viacheslav Ovsiienko wrote:
> Currently, metadata can be set on egress path via mbuf tx_metadata field
> with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_META matches metadata.
>
> This patch extends the metadata feature usability.
>
> 1) RTE_FLOW_ACTION_TYPE_SET_META
>
> When supporting multiple tables, Tx metadata can also be set by a rule and
> matched by another rule. This new action allows metadata to be set as a
> result of flow match.
>
> 2) Metadata on ingress
>
> There's also need to support metadata on ingress. Metadata can be set by
> SET_META action and matched by META item like Tx. The final value set by
> the action will be delivered to application via metadata dynamic field of
> mbuf which can be accessed by RTE_FLOW_DYNF_METADATA().
> PKT_RX_DYNF_METADATA flag will be set along with the data.
>
> The mbuf dynamic field must be registered by calling
> rte_flow_dynf_metadata_register() prior to use SET_META action.
>
> The availability of dynamic mbuf metadata field can be checked
> with rte_flow_dynf_metadata_avail() routine.
>
> For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
> propagated to the other path depending on hardware capability.
>
> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
Above explanations lack information about "meta" vs "mark" which
may be set on Rx as well and delivered in other mbuf field.
It should be explained by one more field is required and rules
defined. Otherwise we can endup in half PMDs supporting
mark only, half PMDs supporting meta only and applications
in an interesting situation to make a choice which one to use.
[snip]
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 159ce19..c943aca 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -658,6 +658,32 @@ the physical device, with virtual groups in the PMD or not at all.
> | ``mask`` | ``id`` | zeroed to match any value |
> +----------+----------+---------------------------+
>
> +Item: ``META``
> +^^^^^^^^^^^^^^^^^
> +
> +Matches 32 bit metadata item set.
> +
> +On egress, metadata can be set either by mbuf metadata field with
> +PKT_TX_METADATA flag or ``SET_META`` action. On ingress, ``SET_META``
> +action sets metadata for a packet and the metadata will be reported via
> +``metadata`` dynamic field of ``rte_mbuf`` with PKT_RX_DYNF_METADATA flag.
> +
> +- Default ``mask`` matches the specified Rx metadata value.
> +
> +.. _table_rte_flow_item_meta:
> +
> +.. table:: META
> +
> + +----------+----------+---------------------------------------+
> + | Field | Subfield | Value |
> + +==========+==========+=======================================+
> + | ``spec`` | ``data`` | 32 bit metadata value |
> + +----------+----------+---------------------------------------+
> + | ``last`` | ``data`` | upper range value |
> + +----------+----------+---------------------------------------+
> + | ``mask`` | ``data`` | bit-mask applies to "spec" and "last" |
> + +----------+----------+---------------------------------------+
> +
> Data matching item types
> ~~~~~~~~~~~~~~~~~~~~~~~~
>
> @@ -1232,21 +1258,6 @@ Matches a PPPoE session protocol identifier.
> - ``proto_id``: PPP protocol identifier.
> - Default ``mask`` matches proto_id only.
>
> -
> -.. _table_rte_flow_item_meta:
> -
> -.. table:: META
> -
> - +----------+----------+---------------------------------------+
> - | Field | Subfield | Value |
> - +==========+==========+=======================================+
> - | ``spec`` | ``data`` | 32 bit metadata value |
> - +----------+--------------------------------------------------+
> - | ``last`` | ``data`` | upper range value |
> - +----------+----------+---------------------------------------+
> - | ``mask`` | ``data`` | bit-mask applies to "spec" and "last" |
> - +----------+----------+---------------------------------------+
> -
> Item: ``NSH``
> ^^^^^^^^^^^^^
>
> @@ -2466,6 +2477,37 @@ Value to decrease TCP acknowledgment number by is a big-endian 32 bit integer.
>
> Using this action on non-matching traffic will result in undefined behavior.
>
> +Action: ``SET_META``
> +^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Set metadata. Item ``META`` matches metadata.
> +
> +Metadata set by mbuf metadata field with PKT_TX_METADATA flag on egress will be
> +overridden by this action. On ingress, the metadata will be carried by
> +``metadata`` dynamic field of ``rte_mbuf`` which can be accessed by
> +``RTE_FLOW_DYNF_METADATA()``. PKT_RX_DYNF_METADATA flag will be set along
> +with the data.
> +
> +The mbuf dynamic field must be registered by calling
> +``rte_flow_dynf_metadata_register()`` prior to use ``SET_META`` action.
> +
> +Altering partial bits is supported with ``mask``. For bits which have never been
> +set, unpredictable value will be seen depending on driver implementation. For
> +loopback/hairpin packet, metadata set on Rx/Tx may or may not be propagated to
> +the other path depending on HW capability.
> +
> +.. _table_rte_flow_action_set_meta:
> +
> +.. table:: SET_META
> +
> + +----------+----------------------------+
> + | Field | Value |
> + +==========+============================+
> + | ``data`` | 32 bit metadata value |
> + +----------+----------------------------+
> + | ``mask`` | bit-mask applies to "data" |
> + +----------+----------------------------+
> +
> Negative types
> ~~~~~~~~~~~~~~
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 3aa1634..9d54d8e 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -106,6 +106,10 @@ Deprecation Notices
> struct ``rte_eth_dev_info`` for the port capability and in struct
> ``rte_eth_rxmode`` for the port configuration.
>
> +* ethdev: DEV_TX_OFFLOAD_MATCH_METADATA will be removed, static metadata
> + mbuf field will be removed in 20.02, metadata feature will use dynamic mbuf
> + field and flag instead.
> +
Isn't it breaking stable API/ABI? Should target release be 20.11?
I think that DEV_TX_OFFLOAD_MATCH_METADATA should marked
as deprecated now as well as tx_metadata field in mbuf.
> * cryptodev: support for using IV with all sizes is added, J0 still can
> be used but only when IV length in following structs ``rte_crypto_auth_xform``,
> ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
> diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
> index 0e5bb5d..6d331f6 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -232,6 +232,21 @@ New Features
> gives ability to print port supported ptypes in different protocol layers.
>
>
> +* **Add support of support dynamic fields and flags in mbuf.**
> +
> + This new feature adds the ability to dynamically register some room
> + for a field or a flag in the mbuf structure. This is typically used
> + for specific offload features, where adding a static field or flag
> + in the mbuf is not justified.
> +
I guess above is just incorrect merge.
> +* **Extended metadata support in rte_flow.**
> +
> + Flow metadata is extended to both Rx and Tx.
> +
> + * Tx metadata can also be set by SET_META action of rte_flow.
> + * Rx metadata is delivered to host via a dynamic field of ``rte_mbuf`` with
> + PKT_RX_DYNF_METADATA.
> +
Two empty lines are required before the next section.
> Removed Items
> -------------
>
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index c36c1b6..b19c86b 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1048,7 +1048,6 @@ struct rte_eth_conf {
> #define DEV_RX_OFFLOAD_KEEP_CRC 0x00010000
> #define DEV_RX_OFFLOAD_SCTP_CKSUM 0x00020000
> #define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM 0x00040000
> -
Unrelated change.
> #define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \
> DEV_RX_OFFLOAD_UDP_CKSUM | \
> DEV_RX_OFFLOAD_TCP_CKSUM)
[snip]
> diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c
> index ca0f680..6090177 100644
> --- a/lib/librte_ethdev/rte_flow.c
> +++ b/lib/librte_ethdev/rte_flow.c
> @@ -12,10 +12,18 @@
> #include <rte_errno.h>
> #include <rte_branch_prediction.h>
> #include <rte_string_fns.h>
> +#include <rte_mbuf.h>
> +#include <rte_mbuf_dyn.h>
> #include "rte_ethdev.h"
> #include "rte_flow_driver.h"
> #include "rte_flow.h"
>
> +/* Mbuf dynamic field name for metadata. */
> +int rte_flow_dynf_metadata_offs = -1;
> +
> +/* Mbuf dynamic field flag bit number for metadata. */
> +uint64_t rte_flow_dynf_metadata_mask;
> +
> /**
> * Flow elements description tables.
> */
> @@ -157,8 +165,41 @@ struct rte_flow_desc_data {
> MK_FLOW_ACTION(DEC_TCP_SEQ, sizeof(rte_be32_t)),
> MK_FLOW_ACTION(INC_TCP_ACK, sizeof(rte_be32_t)),
> MK_FLOW_ACTION(DEC_TCP_ACK, sizeof(rte_be32_t)),
> + MK_FLOW_ACTION(SET_META, sizeof(struct rte_flow_action_set_meta)),
> };
>
> +int
> +rte_flow_dynf_metadata_register(void)
> +{
> + int offset;
> + int flag;
> +
> + static const struct rte_mbuf_dynfield desc_offs = {
> + .name = MBUF_DYNF_METADATA_NAME,
> + .size = sizeof(uint32_t),
> + .align = __alignof__(uint32_t),
> + .flags = 0,
I think flags initialization to 0 is redundant.
> + };
> + static const struct rte_mbuf_dynflag desc_flag = {
> + .name = MBUF_DYNF_METADATA_NAME,
> + };
> +
> + offset = rte_mbuf_dynfield_register(&desc_offs);
> + if (offset < 0)
> + goto error;
> + flag = rte_mbuf_dynflag_register(&desc_flag);
> + if (flag < 0)
> + goto error;
> + rte_flow_dynf_metadata_offs = offset;
> + rte_flow_dynf_metadata_mask = (1ULL << flag);
> + return 0;
> +
> +error:
Just an observation...
Impossibility to unregister hits here. Field may be registered,
but will be used.
> + rte_flow_dynf_metadata_offs = -1;
> + rte_flow_dynf_metadata_mask = 0ULL;
> + return -rte_errno;
> +}
> +
> static int
> flow_err(uint16_t port_id, int ret, struct rte_flow_error *error)
> {
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index 4fee105..b821557 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -28,6 +28,8 @@
> #include <rte_byteorder.h>
> #include <rte_esp.h>
> #include <rte_higig.h>
> +#include <rte_mbuf.h>
> +#include <rte_mbuf_dyn.h>
>
> #ifdef __cplusplus
> extern "C" {
> @@ -418,7 +420,8 @@ enum rte_flow_item_type {
> /**
> * [META]
> *
> - * Matches a metadata value specified in mbuf metadata field.
> + * Matches a metadata value.
> + *
> * See struct rte_flow_item_meta.
> */
> RTE_FLOW_ITEM_TYPE_META,
> @@ -1263,9 +1266,17 @@ struct rte_flow_item_icmp6_nd_opt_tla_eth {
> #endif
>
> /**
> - * RTE_FLOW_ITEM_TYPE_META.
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
Is it allowed to make experimental back?
> *
> - * Matches a specified metadata value.
> + * RTE_FLOW_ITEM_TYPE_META
> + *
> + * Matches a specified metadata value. On egress, metadata can be set either by
> + * mbuf tx_metadata field with PKT_TX_METADATA flag or
> + * RTE_FLOW_ACTION_TYPE_SET_META. On ingress, RTE_FLOW_ACTION_TYPE_SET_META sets
> + * metadata for a packet and the metadata will be reported via mbuf metadata
> + * dynamic field with PKT_RX_DYNF_METADATA flag. The dynamic mbuf field must be
> + * registered in advance by rte_flow_dynf_metadata_register().
> */
> struct rte_flow_item_meta {
> rte_be32_t data;
[snip]
> @@ -2429,6 +2447,55 @@ struct rte_flow_action_set_mac {
> uint8_t mac_addr[RTE_ETHER_ADDR_LEN];
> };
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * RTE_FLOW_ACTION_TYPE_SET_META
> + *
> + * Set metadata. Metadata set by mbuf tx_metadata field with
> + * PKT_TX_METADATA flag on egress will be overridden by this action. On
> + * ingress, the metadata will be carried by mbuf metadata dynamic field
> + * with PKT_RX_DYNF_METADATA flag if set. The dynamic mbuf field must be
> + * registered in advance by rte_flow_dynf_metadata_register().
> + *
> + * Altering partial bits is supported with mask. For bits which have never
> + * been set, unpredictable value will be seen depending on driver
> + * implementation. For loopback/hairpin packet, metadata set on Rx/Tx may
> + * or may not be propagated to the other path depending on HW capability.
> + *
> + * RTE_FLOW_ITEM_TYPE_META matches metadata.
> + */
> +struct rte_flow_action_set_meta {
> + rte_be32_t data;
> + rte_be32_t mask;
As I understand tx_metadata is host endian. Just double-checking.
Is a new dynamic field host endian or big endian?
I definitely would like to see motivation in comments why data/mask
are big-endian here.
> +};
> +
> +/* Mbuf dynamic field offset for metadata. */
> +extern int rte_flow_dynf_metadata_offs;
> +
> +/* Mbuf dynamic field flag mask for metadata. */
> +extern uint64_t rte_flow_dynf_metadata_mask;
These two global variables look frightening to me.
It does not look good to me.
> +
> +/* Mbuf dynamic field pointer for metadata. */
> +#define RTE_FLOW_DYNF_METADATA(m) \
> + RTE_MBUF_DYNFIELD((m), rte_flow_dynf_metadata_offs, uint32_t *)
> +
> +/* Mbuf dynamic flag for metadata. */
> +#define PKT_RX_DYNF_METADATA (rte_flow_dynf_metadata_mask)
> +
> +__rte_experimental
> +static inline uint32_t
> +rte_flow_dynf_metadata_get(struct rte_mbuf *m) {
Above curly bracket should be on its own line in the case of function
definition.
Shouldn't m be 'const struct rte_mbuf *'?
> + return *RTE_FLOW_DYNF_METADATA(m);
> +}
> +
> +__rte_experimental
> +static inline void
> +rte_flow_dynf_metadata_set(struct rte_mbuf *m, uint32_t v) {
Above curly bracket should be on its own line in the case of function
definition.
> + *RTE_FLOW_DYNF_METADATA(m) = v;
> +}
> +
> /*
> * Definition of a single action.
> *
> @@ -2662,6 +2729,32 @@ enum rte_flow_conv_op {
> };
>
> /**
> + * Check if mbuf dynamic field for metadata is registered.
> + *
> + * @return
> + * True if registered, false otherwise.
> + */
> +__rte_experimental
> +static inline int
> +rte_flow_dynf_metadata_avail(void) {
Above curly bracket should be on its own line in the case of function
definition.
> + return !!rte_flow_dynf_metadata_mask;
> +}
> +
> +/**
> + * Register mbuf dynamic field and flag for metadata.
> + *
> + * This function must be called prior to use SET_META action in order to
> + * register the dynamic mbuf field. Otherwise, the data cannot be delivered to
> + * application.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +__rte_experimental
> +int
> +rte_flow_dynf_metadata_register(void);
> +
> +/**
> * Check whether a flow rule can be created on a given port.
> *
> * The flow rule is validated for correctness and whether it could be accepted
> diff --git a/lib/librte_mbuf/rte_mbuf_dyn.h b/lib/librte_mbuf/rte_mbuf_dyn.h
> index 2e9d418..a4a0cf5 100644
> --- a/lib/librte_mbuf/rte_mbuf_dyn.h
> +++ b/lib/librte_mbuf/rte_mbuf_dyn.h
> @@ -234,6 +234,10 @@ int rte_mbuf_dynflag_lookup(const char *name,
> __rte_experimental
> void rte_mbuf_dyn_dump(FILE *out);
>
> -/* Placeholder for dynamic fields and flags declarations. */
> -
> +/*
> + * Placeholder for dynamic fields and flags declarations.
> + * This is centralizing point to gather all field names
> + * and parameters together.
> + */
It is not a comment for below define. So, I think empty line is
required to separate the comment from below define.
I'm not sure that the clarification is required, but it is up to Olivier.
> +#define MBUF_DYNF_METADATA_NAME "rte_flow_dynfield_metadata"
Empty line is missing here
> #endif
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
2019-10-29 15:59 3% ` Jerin Jacob
@ 2019-10-29 16:16 0% ` Wang, Haiyue
0 siblings, 0 replies; 200+ results
From: Wang, Haiyue @ 2019-10-29 16:16 UTC (permalink / raw)
To: Jerin Jacob
Cc: Thomas Monjalon, Yigit, Ferruh, dpdk-dev, Ye, Xiaolong, Kinsella,
Ray, Iremonger, Bernard, Sun, Chenmin, Andrew Rybchenko,
Slava Ovsiienko, Stephen Hemminger, David Marchand, Jerin Jacob
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, October 29, 2019 23:59
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
>
> On Tue, Oct 29, 2019 at 9:12 PM Wang, Haiyue <haiyue.wang@intel.com> wrote:
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Tuesday, October 29, 2019 22:09
> > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> Hemminger
> > > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > > <jerinj@marvell.com>
> > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> > >
> > > > > > >
> > > > > >
> > > > > > How about *_str_* style ?
> > > > >
> > > > > _name kind of implies it the string. may be _mode is good as it is short.
> > > > >
> > > > > > int
> > > > > > rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id,
> > > > > > char *buf, int buflen)
> > > > >
> > > >
> > > > About the function, keep the same is better ? Then we need no whole
> > > > replace, just update the parameters, and the parameters indicated that
> > > > it is in string format.
> > >
> > > In this case, we need additional PMD op to get the buflen as
> > > the application will not know the buffer size in advance. It needs to come
> > > from the driver and common code.
> > >
> > >
> > > See below.
> > >
> > > >
> > > > > We don't need buflen as it is not known to the application. The
> > > > > typical pattern, we followed,
> > > > > in dpdk is, when function called buf as NULL then the function returns
> > > > > the expected size so that
> > > > > the application can alloc and get the buffer from ethdev layer on the
> > > > > next iteration.
> > > > >
> > > > >
> > > >
> > > > A little complicated and too heavy for using ? where is the example code ?
> > >
> > > See rte_eth_xstats_get_names() API as example for dynamic buffer allocation
> > > and similar use case in DPDK.
> >
> > In fact, this is no so complex as dynamic string handling. :)
> >
> > /* Get count */
> > cnt_xstats = rte_eth_xstats_get_names(port_id, NULL, 0);
> > if (cnt_xstats < 0) {
> > printf("Error: Cannot get count of xstats\n");
> > return;
> > }
> >
> > xstats_names = malloc(sizeof(struct rte_eth_xstat_name) * cnt_xstats);
> >
> > struct rte_eth_xstat_name {
> > char name[RTE_ETH_XSTATS_NAME_SIZE]; /**< The statistic name. */
> > };
>
>
> not really, it will be,[1]
>
> count = rte_eth_rx_burst_mode_name(port_id, queue_id, NULL);
> buf = malloc(count);
> count = rte_eth_rx_burst_mode_name(port_id, queue_id, buf);
>
>
I mean 'cnt_xstats' can be calculated like:
count = RTE_NB_STATS;
count += nb_rxqs * RTE_NB_RXQ_STATS;
count += nb_txqs * RTE_NB_TXQ_STATS;
But for string, what I know is that use 'snprintf(NULL, 0, ...)' to get
the real length, in other words:
1). NULL, call 'snprintf' to loop to get the length
2). Not none, call 'sprint' to loop to dump into buffer.
So in the function, have to handle two kind of loops.
And application has to handle memory allocation, free etc. Why not
just use a structure ? It is clean.
> >
> >
> > Frankly speaking, after re-thinking, I prefer to keep current design.
> > 1) Use the structure to expose the *raw* data. Make the APIs work as
> > a SDK, DON'T image to format the string for user. User can call the
> > API to dump to file, print to console etc. Because he has the raw
> > data.
>
> [1] Dont have such issue.
>
> >
> > struct rte_eth_burst_mode {
> > uint64_t options;
> > };
> >
> > The 'options' bit definition reflects the rx/tx source code structure roughly:
> >
> > "tree drivers/net/ | grep rxtx"
> > │ ├── virtio_rxtx_simple_sse.c
> > └── vmxnet3_rxtx.c
>
> Files don't represent the actual mode PMD is running. So listing the
> file example is not correct.
>
I mean the function in it.
>
> >
> > 2. add "char dev_specific[]" data as needed if a PMD wants to expose it,
> > enhance the APIs step by step, and do it as needed.
>
> This would change ABI for no reason and who allocates the memory for
> dev_specific?
I mean like 'char dev_specific[128]', not zero length data. Sorry for confusion.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
@ 2019-10-29 15:59 3% ` Jerin Jacob
2019-10-29 16:16 0% ` Wang, Haiyue
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2019-10-29 15:59 UTC (permalink / raw)
To: Wang, Haiyue
Cc: Thomas Monjalon, Yigit, Ferruh, dpdk-dev, Ye, Xiaolong, Kinsella,
Ray, Iremonger, Bernard, Sun, Chenmin, Andrew Rybchenko,
Slava Ovsiienko, Stephen Hemminger, David Marchand, Jerin Jacob
On Tue, Oct 29, 2019 at 9:12 PM Wang, Haiyue <haiyue.wang@intel.com> wrote:
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Tuesday, October 29, 2019 22:09
> > To: Wang, Haiyue <haiyue.wang@intel.com>
> > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > <jerinj@marvell.com>
> > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> >
> > > > > >
> > > > >
> > > > > How about *_str_* style ?
> > > >
> > > > _name kind of implies it the string. may be _mode is good as it is short.
> > > >
> > > > > int
> > > > > rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id,
> > > > > char *buf, int buflen)
> > > >
> > >
> > > About the function, keep the same is better ? Then we need no whole
> > > replace, just update the parameters, and the parameters indicated that
> > > it is in string format.
> >
> > In this case, we need additional PMD op to get the buflen as
> > the application will not know the buffer size in advance. It needs to come
> > from the driver and common code.
> >
> >
> > See below.
> >
> > >
> > > > We don't need buflen as it is not known to the application. The
> > > > typical pattern, we followed,
> > > > in dpdk is, when function called buf as NULL then the function returns
> > > > the expected size so that
> > > > the application can alloc and get the buffer from ethdev layer on the
> > > > next iteration.
> > > >
> > > >
> > >
> > > A little complicated and too heavy for using ? where is the example code ?
> >
> > See rte_eth_xstats_get_names() API as example for dynamic buffer allocation
> > and similar use case in DPDK.
>
> In fact, this is no so complex as dynamic string handling. :)
>
> /* Get count */
> cnt_xstats = rte_eth_xstats_get_names(port_id, NULL, 0);
> if (cnt_xstats < 0) {
> printf("Error: Cannot get count of xstats\n");
> return;
> }
>
> xstats_names = malloc(sizeof(struct rte_eth_xstat_name) * cnt_xstats);
>
> struct rte_eth_xstat_name {
> char name[RTE_ETH_XSTATS_NAME_SIZE]; /**< The statistic name. */
> };
not really, it will be,[1]
count = rte_eth_rx_burst_mode_name(port_id, queue_id, NULL);
buf = malloc(count);
count = rte_eth_rx_burst_mode_name(port_id, queue_id, buf);
>
>
> Frankly speaking, after re-thinking, I prefer to keep current design.
> 1) Use the structure to expose the *raw* data. Make the APIs work as
> a SDK, DON'T image to format the string for user. User can call the
> API to dump to file, print to console etc. Because he has the raw
> data.
[1] Dont have such issue.
>
> struct rte_eth_burst_mode {
> uint64_t options;
> };
>
> The 'options' bit definition reflects the rx/tx source code structure roughly:
>
> "tree drivers/net/ | grep rxtx"
> │ ├── virtio_rxtx_simple_sse.c
> └── vmxnet3_rxtx.c
Files don't represent the actual mode PMD is running. So listing the
file example is not correct.
>
> 2. add "char dev_specific[]" data as needed if a PMD wants to expose it,
> enhance the APIs step by step, and do it as needed.
This would change ABI for no reason and who allocates the memory for
dev_specific?
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v6 02/12] build: annotate versioned symbols with __vsym macro
@ 2019-10-29 14:12 2% ` Andrzej Ostruszka
1 sibling, 0 replies; 200+ results
From: Andrzej Ostruszka @ 2019-10-29 14:12 UTC (permalink / raw)
To: dev, John McNamara, Marko Kovacevic, David Hunt, Neil Horman,
Bruce Richardson, Vladimir Medvedkin, Robert Sanford,
Erik Gabriel Carrillo
Cc: mattias.ronnblom, stephen
Every implementation of a particular version of given symbol needs to be
marked in its declaration as such (using `__vsym` macro). This patch
fixes this and also clarifies the documentation about that.
Signed-off-by: Andrzej Ostruszka <aostruszka@marvell.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
doc/guides/contributing/versioning.rst | 14 +++++++---
lib/librte_distributor/rte_distributor.c | 18 ++++++------
lib/librte_distributor/rte_distributor_v20.c | 18 ++++++------
.../common/include/rte_function_versioning.h | 7 +++++
lib/librte_lpm/rte_lpm.c | 28 +++++++++----------
lib/librte_lpm/rte_lpm6.c | 16 +++++------
lib/librte_timer/rte_timer.c | 20 ++++++-------
7 files changed, 67 insertions(+), 54 deletions(-)
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 8a38928c0..fcd2d50f1 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -225,6 +225,10 @@ The macros exported are:
fully qualified function ``p``, so that if a symbol becomes versioned, it
can still be mapped back to the public symbol name.
+* ``__vsym``: Annotation to be used in a declaration of the internal symbol
+ ``be`` to signal that it is being used as an implementation of a particular
+ version of symbol ``b``.
+
Examples of ABI Macro use
^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -345,8 +349,9 @@ with the public symbol name
.. code-block:: c
- struct rte_acl_ctx *
+ -struct rte_acl_ctx *
-rte_acl_create(const struct rte_acl_param *param)
+ +struct rte_acl_ctx * __vsym
+rte_acl_create_v20(const struct rte_acl_param *param)
{
size_t sz;
@@ -354,7 +359,8 @@ with the public symbol name
...
Note that the base name of the symbol was kept intact, as this is conducive to
-the macros used for versioning symbols. That is our next step, mapping this new
+the macros used for versioning symbols and we have annotated the function as an
+implementation of versioned symbol. That is our next step, mapping this new
symbol name to the initial symbol name at version node 2.0. Immediately after
the function, we add this line of code
@@ -374,7 +380,7 @@ name, with a different suffix, and implement it appropriately
.. code-block:: c
- struct rte_acl_ctx *
+ struct rte_acl_ctx * __vsym
rte_acl_create_v21(const struct rte_acl_param *param, int debug);
{
struct rte_acl_ctx *ctx = rte_acl_create_v20(param);
@@ -423,7 +429,7 @@ defined, we add this
.. code-block:: c
- struct rte_acl_ctx *
+ struct rte_acl_ctx * __vsym
rte_acl_create_v21(const struct rte_acl_param *param, int debug)
{
...
diff --git a/lib/librte_distributor/rte_distributor.c b/lib/librte_distributor/rte_distributor.c
index 7df97df92..2cc32ddba 100644
--- a/lib/librte_distributor/rte_distributor.c
+++ b/lib/librte_distributor/rte_distributor.c
@@ -32,7 +32,7 @@ EAL_REGISTER_TAILQ(rte_dist_burst_tailq)
/**** Burst Packet APIs called by workers ****/
-void
+void __vsym
rte_distributor_request_pkt_v1705(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **oldpkt,
unsigned int count)
@@ -89,7 +89,7 @@ MAP_STATIC_SYMBOL(void rte_distributor_request_pkt(struct rte_distributor *d,
unsigned int count),
rte_distributor_request_pkt_v1705);
-int
+int __vsym
rte_distributor_poll_pkt_v1705(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **pkts)
{
@@ -134,7 +134,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_poll_pkt(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **pkts),
rte_distributor_poll_pkt_v1705);
-int
+int __vsym
rte_distributor_get_pkt_v1705(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **pkts,
struct rte_mbuf **oldpkt, unsigned int return_count)
@@ -169,7 +169,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_get_pkt(struct rte_distributor *d,
struct rte_mbuf **oldpkt, unsigned int return_count),
rte_distributor_get_pkt_v1705);
-int
+int __vsym
rte_distributor_return_pkt_v1705(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **oldpkt, int num)
{
@@ -359,7 +359,7 @@ release(struct rte_distributor *d, unsigned int wkr)
/* process a set of packets to distribute them to workers */
-int
+int __vsym
rte_distributor_process_v1705(struct rte_distributor *d,
struct rte_mbuf **mbufs, unsigned int num_mbufs)
{
@@ -506,7 +506,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_process(struct rte_distributor *d,
rte_distributor_process_v1705);
/* return to the caller, packets returned from workers */
-int
+int __vsym
rte_distributor_returned_pkts_v1705(struct rte_distributor *d,
struct rte_mbuf **mbufs, unsigned int max_mbufs)
{
@@ -556,7 +556,7 @@ total_outstanding(const struct rte_distributor *d)
* Flush the distributor, so that there are no outstanding packets in flight or
* queued up.
*/
-int
+int __vsym
rte_distributor_flush_v1705(struct rte_distributor *d)
{
unsigned int flushed;
@@ -591,7 +591,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_flush(struct rte_distributor *d),
rte_distributor_flush_v1705);
/* clears the internal returns array in the distributor */
-void
+void __vsym
rte_distributor_clear_returns_v1705(struct rte_distributor *d)
{
unsigned int wkr;
@@ -613,7 +613,7 @@ MAP_STATIC_SYMBOL(void rte_distributor_clear_returns(struct rte_distributor *d),
rte_distributor_clear_returns_v1705);
/* creates a distributor instance */
-struct rte_distributor *
+struct rte_distributor * __vsym
rte_distributor_create_v1705(const char *name,
unsigned int socket_id,
unsigned int num_workers,
diff --git a/lib/librte_distributor/rte_distributor_v20.c b/lib/librte_distributor/rte_distributor_v20.c
index db6c49258..7a6fddf55 100644
--- a/lib/librte_distributor/rte_distributor_v20.c
+++ b/lib/librte_distributor/rte_distributor_v20.c
@@ -27,7 +27,7 @@ EAL_REGISTER_TAILQ(rte_distributor_tailq)
/**** APIs called by workers ****/
-void
+void __vsym
rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
@@ -43,7 +43,7 @@ rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
}
VERSION_SYMBOL(rte_distributor_request_pkt, _v20, 2.0);
-struct rte_mbuf *
+struct rte_mbuf * __vsym
rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
unsigned worker_id)
{
@@ -59,7 +59,7 @@ rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
}
VERSION_SYMBOL(rte_distributor_poll_pkt, _v20, 2.0);
-struct rte_mbuf *
+struct rte_mbuf * __vsym
rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
@@ -71,7 +71,7 @@ rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
}
VERSION_SYMBOL(rte_distributor_get_pkt, _v20, 2.0);
-int
+int __vsym
rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
@@ -204,7 +204,7 @@ process_returns(struct rte_distributor_v20 *d)
}
/* process a set of packets to distribute them to workers */
-int
+int __vsym
rte_distributor_process_v20(struct rte_distributor_v20 *d,
struct rte_mbuf **mbufs, unsigned num_mbufs)
{
@@ -321,7 +321,7 @@ rte_distributor_process_v20(struct rte_distributor_v20 *d,
VERSION_SYMBOL(rte_distributor_process, _v20, 2.0);
/* return to the caller, packets returned from workers */
-int
+int __vsym
rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
struct rte_mbuf **mbufs, unsigned max_mbufs)
{
@@ -359,7 +359,7 @@ total_outstanding(const struct rte_distributor_v20 *d)
/* flush the distributor, so that there are no outstanding packets in flight or
* queued up. */
-int
+int __vsym
rte_distributor_flush_v20(struct rte_distributor_v20 *d)
{
const unsigned flushed = total_outstanding(d);
@@ -372,7 +372,7 @@ rte_distributor_flush_v20(struct rte_distributor_v20 *d)
VERSION_SYMBOL(rte_distributor_flush, _v20, 2.0);
/* clears the internal returns array in the distributor */
-void
+void __vsym
rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
{
d->returns.start = d->returns.count = 0;
@@ -383,7 +383,7 @@ rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
VERSION_SYMBOL(rte_distributor_clear_returns, _v20, 2.0);
/* creates a distributor instance */
-struct rte_distributor_v20 *
+struct rte_distributor_v20 * __vsym
rte_distributor_create_v20(const char *name,
unsigned socket_id,
unsigned num_workers)
diff --git a/lib/librte_eal/common/include/rte_function_versioning.h b/lib/librte_eal/common/include/rte_function_versioning.h
index eae619d60..c924351d5 100644
--- a/lib/librte_eal/common/include/rte_function_versioning.h
+++ b/lib/librte_eal/common/include/rte_function_versioning.h
@@ -52,6 +52,13 @@
* symbol <b> to the internal symbol <b><e>
*/
#define BIND_DEFAULT_SYMBOL(b, e, n) __asm__(".symver " RTE_STR(b) RTE_STR(e) ", " RTE_STR(b) "@@DPDK_" RTE_STR(n))
+
+/*
+ * __vsym
+ * Annotation to be used in declaration of the internal symbol <b><e> to signal
+ * that it is being used as an implementation of a particular version of symbol
+ * <b>.
+ */
#define __vsym __attribute__((used))
/*
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index c96395e26..106916dc8 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -90,7 +90,7 @@ depth_to_range(uint8_t depth)
/*
* Find an existing lpm table and return a pointer to it.
*/
-struct rte_lpm_v20 *
+struct rte_lpm_v20 * __vsym
rte_lpm_find_existing_v20(const char *name)
{
struct rte_lpm_v20 *l = NULL;
@@ -116,7 +116,7 @@ rte_lpm_find_existing_v20(const char *name)
}
VERSION_SYMBOL(rte_lpm_find_existing, _v20, 2.0);
-struct rte_lpm *
+struct rte_lpm * __vsym
rte_lpm_find_existing_v1604(const char *name)
{
struct rte_lpm *l = NULL;
@@ -147,7 +147,7 @@ MAP_STATIC_SYMBOL(struct rte_lpm *rte_lpm_find_existing(const char *name),
/*
* Allocates memory for LPM object
*/
-struct rte_lpm_v20 *
+struct rte_lpm_v20 * __vsym
rte_lpm_create_v20(const char *name, int socket_id, int max_rules,
__rte_unused int flags)
{
@@ -220,7 +220,7 @@ rte_lpm_create_v20(const char *name, int socket_id, int max_rules,
}
VERSION_SYMBOL(rte_lpm_create, _v20, 2.0);
-struct rte_lpm *
+struct rte_lpm * __vsym
rte_lpm_create_v1604(const char *name, int socket_id,
const struct rte_lpm_config *config)
{
@@ -329,7 +329,7 @@ MAP_STATIC_SYMBOL(
/*
* Deallocates memory for given LPM table.
*/
-void
+void __vsym
rte_lpm_free_v20(struct rte_lpm_v20 *lpm)
{
struct rte_lpm_list *lpm_list;
@@ -358,7 +358,7 @@ rte_lpm_free_v20(struct rte_lpm_v20 *lpm)
}
VERSION_SYMBOL(rte_lpm_free, _v20, 2.0);
-void
+void __vsym
rte_lpm_free_v1604(struct rte_lpm *lpm)
{
struct rte_lpm_list *lpm_list;
@@ -1177,7 +1177,7 @@ add_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
/*
* Add a route
*/
-int
+int __vsym
rte_lpm_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
uint8_t next_hop)
{
@@ -1218,7 +1218,7 @@ rte_lpm_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
}
VERSION_SYMBOL(rte_lpm_add, _v20, 2.0);
-int
+int __vsym
rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t next_hop)
{
@@ -1264,7 +1264,7 @@ MAP_STATIC_SYMBOL(int rte_lpm_add(struct rte_lpm *lpm, uint32_t ip,
/*
* Look for a rule in the high-level rules table
*/
-int
+int __vsym
rte_lpm_is_rule_present_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
uint8_t *next_hop)
{
@@ -1291,7 +1291,7 @@ uint8_t *next_hop)
}
VERSION_SYMBOL(rte_lpm_is_rule_present, _v20, 2.0);
-int
+int __vsym
rte_lpm_is_rule_present_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t *next_hop)
{
@@ -1844,7 +1844,7 @@ delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
/*
* Deletes a rule
*/
-int
+int __vsym
rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
{
int32_t rule_to_delete_index, sub_rule_index;
@@ -1898,7 +1898,7 @@ rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
}
VERSION_SYMBOL(rte_lpm_delete, _v20, 2.0);
-int
+int __vsym
rte_lpm_delete_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
{
int32_t rule_to_delete_index, sub_rule_index;
@@ -1957,7 +1957,7 @@ MAP_STATIC_SYMBOL(int rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip,
/*
* Delete all rules from the LPM table.
*/
-void
+void __vsym
rte_lpm_delete_all_v20(struct rte_lpm_v20 *lpm)
{
/* Zero rule information. */
@@ -1974,7 +1974,7 @@ rte_lpm_delete_all_v20(struct rte_lpm_v20 *lpm)
}
VERSION_SYMBOL(rte_lpm_delete_all, _v20, 2.0);
-void
+void __vsym
rte_lpm_delete_all_v1604(struct rte_lpm *lpm)
{
/* Zero rule information. */
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index e20f82460..0d161dc32 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -812,7 +812,7 @@ add_step(struct rte_lpm6 *lpm, struct rte_lpm6_tbl_entry *tbl,
/*
* Add a route
*/
-int
+int __vsym
rte_lpm6_add_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint8_t next_hop)
{
@@ -862,7 +862,7 @@ simulate_add(struct rte_lpm6 *lpm, const uint8_t *masked_ip, uint8_t depth)
return 0;
}
-int
+int __vsym
rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint32_t next_hop)
{
@@ -955,7 +955,7 @@ lookup_step(const struct rte_lpm6 *lpm, const struct rte_lpm6_tbl_entry *tbl,
/*
* Looks up an IP
*/
-int
+int __vsym
rte_lpm6_lookup_v20(const struct rte_lpm6 *lpm, uint8_t *ip, uint8_t *next_hop)
{
uint32_t next_hop32 = 0;
@@ -973,7 +973,7 @@ rte_lpm6_lookup_v20(const struct rte_lpm6 *lpm, uint8_t *ip, uint8_t *next_hop)
}
VERSION_SYMBOL(rte_lpm6_lookup, _v20, 2.0);
-int
+int __vsym
rte_lpm6_lookup_v1705(const struct rte_lpm6 *lpm, uint8_t *ip,
uint32_t *next_hop)
{
@@ -1008,7 +1008,7 @@ MAP_STATIC_SYMBOL(int rte_lpm6_lookup(const struct rte_lpm6 *lpm, uint8_t *ip,
/*
* Looks up a group of IP addresses
*/
-int
+int __vsym
rte_lpm6_lookup_bulk_func_v20(const struct rte_lpm6 *lpm,
uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
int16_t * next_hops, unsigned n)
@@ -1049,7 +1049,7 @@ rte_lpm6_lookup_bulk_func_v20(const struct rte_lpm6 *lpm,
}
VERSION_SYMBOL(rte_lpm6_lookup_bulk_func, _v20, 2.0);
-int
+int __vsym
rte_lpm6_lookup_bulk_func_v1705(const struct rte_lpm6 *lpm,
uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
int32_t *next_hops, unsigned int n)
@@ -1099,7 +1099,7 @@ MAP_STATIC_SYMBOL(int rte_lpm6_lookup_bulk_func(const struct rte_lpm6 *lpm,
/*
* Look for a rule in the high-level rules table
*/
-int
+int __vsym
rte_lpm6_is_rule_present_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint8_t *next_hop)
{
@@ -1119,7 +1119,7 @@ rte_lpm6_is_rule_present_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
}
VERSION_SYMBOL(rte_lpm6_is_rule_present, _v20, 2.0);
-int
+int __vsym
rte_lpm6_is_rule_present_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint32_t *next_hop)
{
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 3834c9473..381a9f43f 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -131,7 +131,7 @@ rte_timer_data_dealloc(uint32_t id)
return 0;
}
-void
+void __vsym
rte_timer_subsystem_init_v20(void)
{
unsigned lcore_id;
@@ -153,7 +153,7 @@ VERSION_SYMBOL(rte_timer_subsystem_init, _v20, 2.0);
* secondary processes should be empty, the zeroth entry can be shared by
* multiple processes.
*/
-int
+int __vsym
rte_timer_subsystem_init_v1905(void)
{
const struct rte_memzone *mz;
@@ -551,7 +551,7 @@ __rte_timer_reset(struct rte_timer *tim, uint64_t expire,
}
/* Reset and start the timer associated with the timer handle tim */
-int
+int __vsym
rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
enum rte_timer_type type, unsigned int tim_lcore,
rte_timer_cb_t fct, void *arg)
@@ -574,7 +574,7 @@ rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
}
VERSION_SYMBOL(rte_timer_reset, _v20, 2.0);
-int
+int __vsym
rte_timer_reset_v1905(struct rte_timer *tim, uint64_t ticks,
enum rte_timer_type type, unsigned int tim_lcore,
rte_timer_cb_t fct, void *arg)
@@ -657,14 +657,14 @@ __rte_timer_stop(struct rte_timer *tim, int local_is_locked,
}
/* Stop the timer associated with the timer handle tim */
-int
+int __vsym
rte_timer_stop_v20(struct rte_timer *tim)
{
return __rte_timer_stop(tim, 0, &default_timer_data);
}
VERSION_SYMBOL(rte_timer_stop, _v20, 2.0);
-int
+int __vsym
rte_timer_stop_v1905(struct rte_timer *tim)
{
return rte_timer_alt_stop(default_data_id, tim);
@@ -817,14 +817,14 @@ __rte_timer_manage(struct rte_timer_data *timer_data)
priv_timer[lcore_id].running_tim = NULL;
}
-void
+void __vsym
rte_timer_manage_v20(void)
{
__rte_timer_manage(&default_timer_data);
}
VERSION_SYMBOL(rte_timer_manage, _v20, 2.0);
-int
+int __vsym
rte_timer_manage_v1905(void)
{
struct rte_timer_data *timer_data;
@@ -1074,14 +1074,14 @@ __rte_timer_dump_stats(struct rte_timer_data *timer_data __rte_unused, FILE *f)
#endif
}
-void
+void __vsym
rte_timer_dump_stats_v20(FILE *f)
{
__rte_timer_dump_stats(&default_timer_data, f);
}
VERSION_SYMBOL(rte_timer_dump_stats, _v20, 2.0);
-int
+int __vsym
rte_timer_dump_stats_v1905(FILE *f)
{
return rte_timer_alt_dump_stats(default_data_id, f);
--
2.17.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [RFC] ethdev: add new fields for max LRO session size
2019-10-27 9:04 3% ` Matan Azrad
@ 2019-10-29 12:25 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-10-29 12:25 UTC (permalink / raw)
To: Matan Azrad, Andrew Rybchenko, Thomas Monjalon
Cc: dev, Konstantin Ananyev, Olivier Matz
On 10/27/2019 9:04 AM, Matan Azrad wrote:
> Hi All
>
> From: Andrew Rybchenko
>> On 10/18/19 7:35 PM, Ferruh Yigit wrote:
>>> On 10/2/2019 2:58 PM, Thomas Monjalon wrote:
>>>> 24/09/2019 14:03, Matan Azrad:
>>>>> From: Ferruh Yigit
>>>>>> On 9/15/2019 8:48 AM, Matan Azrad wrote:
>>>>>>> Hi Ferruh
>>>>>>>
>>>>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>>>>> On 8/29/2019 8:47 AM, Matan Azrad wrote:
>>>>>>>>> It may be needed by the user to limit the LRO session packet size.
>>>>>>>>> In order to allow the above limitation, add new Rx configuration
>>>>>>>>> for the maximum LRO session size.
>>>>>>>>>
>>>>>>>>> In addition, Add a new capability to expose the maximum LRO
>>>>>>>>> session size supported by the port.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Matan Azrad <matan@mellanox.com>
>>>>>>>> Hi Matan,
>>>>>>>>
>>>>>>>> Is there any existing user of this new field?
>>>>>>> All the LRO users need it due to the next reasons:
>>>>>>>
>>>>>>> 1. If scatter is enabled - The dpdk user can limit the LRO session
>>>>>>> size created
>>>>>> by the HW by this field, if no field like that - there is no way to limit it.
>>>>>>> 2. No scatter - the dpdk user may want to limit the LRO packet
>>>>>>> size in order
>>>>>> to save enough tail-room in the mbuf for its own usage.
>>>>>>> 3. The limitation of max_rx_pkt_len is not enough - doesn't make
>>>>>>> sense to
>>>>>> limit LRO traffic as single packet.
>>>>>> So should there be more complement patches to this RFC? To update
>>>>>> the users of the field with the new field.
>>>>>
>>>>> We already exposed it as ABI breakage in the last deprecation notice.
>>>>> We probably cannot complete it for 19.11 version, hopefully for 20.02 it
>> will be completed.
>>>> We won't break the ABI in 20.02.
>>>> What should be done in 19.11?
>>>>
>>> The ask was to add code that uses new added fields, this patch only
>>> adds new field to two public ethdev struct.
>>>
>>> @Thomas, @Andrew, if this patch doesn't goes it on this release it
>>> will have to wait a year. I would like to see the implementation but
>>> it is not there, what is your comment?
>>
>> I don't mind to accept it in 19.11 modulo better description of what is LRO
>> session length/size.
>
>
> Thanks,
>
> We can create the patch for ethdev for 19.11-RC2.
>
> Also PMD implementation to use it for RC2.
>
> Is it OK? (We need to break ABI as described in the deprecation notice)
>
OK from me to have ethdev update and PMD implementation for rc2.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 01/11] build: annotate versioned symbols with __vsym macro
2019-10-28 14:21 2% ` [dpdk-dev] [PATCH v5 01/11] build: annotate versioned symbols with __vsym macro Andrzej Ostruszka
@ 2019-10-29 10:49 0% ` Neil Horman
0 siblings, 0 replies; 200+ results
From: Neil Horman @ 2019-10-29 10:49 UTC (permalink / raw)
To: Andrzej Ostruszka
Cc: dev, John McNamara, Marko Kovacevic, David Hunt,
Bruce Richardson, Vladimir Medvedkin, Robert Sanford,
Erik Gabriel Carrillo, mattias.ronnblom, stephen
On Mon, Oct 28, 2019 at 03:21:35PM +0100, Andrzej Ostruszka wrote:
> Every implementation of a particular version of given symbol needs to be
> marked in its declaration as such (using `__vsym` macro). This patch
> fixes this and also clarifies the documentation about that.
>
> Signed-off-by: Andrzej Ostruszka <aostruszka@marvell.com>
> ---
> doc/guides/contributing/versioning.rst | 18 ++++++++----
> lib/librte_distributor/rte_distributor.c | 18 ++++++------
> lib/librte_distributor/rte_distributor_v20.c | 18 ++++++------
> .../common/include/rte_function_versioning.h | 11 ++++++--
> lib/librte_lpm/rte_lpm.c | 28 +++++++++----------
> lib/librte_lpm/rte_lpm6.c | 16 +++++------
> lib/librte_timer/rte_timer.c | 20 ++++++-------
> 7 files changed, 71 insertions(+), 58 deletions(-)
>
> diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
> index 64984c54e..fcd2d50f1 100644
> --- a/doc/guides/contributing/versioning.rst
> +++ b/doc/guides/contributing/versioning.rst
> @@ -215,16 +215,20 @@ library so that older binaries need not be immediately recompiled.
> The macros exported are:
>
> * ``VERSION_SYMBOL(b, e, n)``: Creates a symbol version table entry binding
> - versioned symbol ``b@DPDK_n`` to the internal function ``b_e``.
> + versioned symbol ``b@DPDK_n`` to the internal function ``be``.
>
> * ``BIND_DEFAULT_SYMBOL(b, e, n)``: Creates a symbol version entry instructing
> the linker to bind references to symbol ``b`` to the internal symbol
> - ``b_e``.
> + ``be``.
>
> * ``MAP_STATIC_SYMBOL(f, p)``: Declare the prototype ``f``, and map it to the
> fully qualified function ``p``, so that if a symbol becomes versioned, it
> can still be mapped back to the public symbol name.
>
> +* ``__vsym``: Annotation to be used in a declaration of the internal symbol
> + ``be`` to signal that it is being used as an implementation of a particular
> + version of symbol ``b``.
> +
> Examples of ABI Macro use
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> @@ -345,8 +349,9 @@ with the public symbol name
>
> .. code-block:: c
>
> - struct rte_acl_ctx *
> + -struct rte_acl_ctx *
> -rte_acl_create(const struct rte_acl_param *param)
> + +struct rte_acl_ctx * __vsym
> +rte_acl_create_v20(const struct rte_acl_param *param)
> {
> size_t sz;
> @@ -354,7 +359,8 @@ with the public symbol name
> ...
>
> Note that the base name of the symbol was kept intact, as this is conducive to
> -the macros used for versioning symbols. That is our next step, mapping this new
> +the macros used for versioning symbols and we have annotated the function as an
> +implementation of versioned symbol. That is our next step, mapping this new
> symbol name to the initial symbol name at version node 2.0. Immediately after
> the function, we add this line of code
>
> @@ -374,7 +380,7 @@ name, with a different suffix, and implement it appropriately
>
> .. code-block:: c
>
> - struct rte_acl_ctx *
> + struct rte_acl_ctx * __vsym
> rte_acl_create_v21(const struct rte_acl_param *param, int debug);
> {
> struct rte_acl_ctx *ctx = rte_acl_create_v20(param);
> @@ -423,7 +429,7 @@ defined, we add this
>
> .. code-block:: c
>
> - struct rte_acl_ctx *
> + struct rte_acl_ctx * __vsym
> rte_acl_create_v21(const struct rte_acl_param *param, int debug)
> {
> ...
> diff --git a/lib/librte_distributor/rte_distributor.c b/lib/librte_distributor/rte_distributor.c
> index 7df97df92..2cc32ddba 100644
> --- a/lib/librte_distributor/rte_distributor.c
> +++ b/lib/librte_distributor/rte_distributor.c
> @@ -32,7 +32,7 @@ EAL_REGISTER_TAILQ(rte_dist_burst_tailq)
>
> /**** Burst Packet APIs called by workers ****/
>
> -void
> +void __vsym
> rte_distributor_request_pkt_v1705(struct rte_distributor *d,
> unsigned int worker_id, struct rte_mbuf **oldpkt,
> unsigned int count)
> @@ -89,7 +89,7 @@ MAP_STATIC_SYMBOL(void rte_distributor_request_pkt(struct rte_distributor *d,
> unsigned int count),
> rte_distributor_request_pkt_v1705);
>
> -int
> +int __vsym
> rte_distributor_poll_pkt_v1705(struct rte_distributor *d,
> unsigned int worker_id, struct rte_mbuf **pkts)
> {
> @@ -134,7 +134,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_poll_pkt(struct rte_distributor *d,
> unsigned int worker_id, struct rte_mbuf **pkts),
> rte_distributor_poll_pkt_v1705);
>
> -int
> +int __vsym
> rte_distributor_get_pkt_v1705(struct rte_distributor *d,
> unsigned int worker_id, struct rte_mbuf **pkts,
> struct rte_mbuf **oldpkt, unsigned int return_count)
> @@ -169,7 +169,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_get_pkt(struct rte_distributor *d,
> struct rte_mbuf **oldpkt, unsigned int return_count),
> rte_distributor_get_pkt_v1705);
>
> -int
> +int __vsym
> rte_distributor_return_pkt_v1705(struct rte_distributor *d,
> unsigned int worker_id, struct rte_mbuf **oldpkt, int num)
> {
> @@ -359,7 +359,7 @@ release(struct rte_distributor *d, unsigned int wkr)
>
>
> /* process a set of packets to distribute them to workers */
> -int
> +int __vsym
> rte_distributor_process_v1705(struct rte_distributor *d,
> struct rte_mbuf **mbufs, unsigned int num_mbufs)
> {
> @@ -506,7 +506,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_process(struct rte_distributor *d,
> rte_distributor_process_v1705);
>
> /* return to the caller, packets returned from workers */
> -int
> +int __vsym
> rte_distributor_returned_pkts_v1705(struct rte_distributor *d,
> struct rte_mbuf **mbufs, unsigned int max_mbufs)
> {
> @@ -556,7 +556,7 @@ total_outstanding(const struct rte_distributor *d)
> * Flush the distributor, so that there are no outstanding packets in flight or
> * queued up.
> */
> -int
> +int __vsym
> rte_distributor_flush_v1705(struct rte_distributor *d)
> {
> unsigned int flushed;
> @@ -591,7 +591,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_flush(struct rte_distributor *d),
> rte_distributor_flush_v1705);
>
> /* clears the internal returns array in the distributor */
> -void
> +void __vsym
> rte_distributor_clear_returns_v1705(struct rte_distributor *d)
> {
> unsigned int wkr;
> @@ -613,7 +613,7 @@ MAP_STATIC_SYMBOL(void rte_distributor_clear_returns(struct rte_distributor *d),
> rte_distributor_clear_returns_v1705);
>
> /* creates a distributor instance */
> -struct rte_distributor *
> +struct rte_distributor * __vsym
> rte_distributor_create_v1705(const char *name,
> unsigned int socket_id,
> unsigned int num_workers,
> diff --git a/lib/librte_distributor/rte_distributor_v20.c b/lib/librte_distributor/rte_distributor_v20.c
> index db6c49258..7a6fddf55 100644
> --- a/lib/librte_distributor/rte_distributor_v20.c
> +++ b/lib/librte_distributor/rte_distributor_v20.c
> @@ -27,7 +27,7 @@ EAL_REGISTER_TAILQ(rte_distributor_tailq)
>
> /**** APIs called by workers ****/
>
> -void
> +void __vsym
> rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
> unsigned worker_id, struct rte_mbuf *oldpkt)
> {
> @@ -43,7 +43,7 @@ rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
> }
> VERSION_SYMBOL(rte_distributor_request_pkt, _v20, 2.0);
>
> -struct rte_mbuf *
> +struct rte_mbuf * __vsym
> rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
> unsigned worker_id)
> {
> @@ -59,7 +59,7 @@ rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
> }
> VERSION_SYMBOL(rte_distributor_poll_pkt, _v20, 2.0);
>
> -struct rte_mbuf *
> +struct rte_mbuf * __vsym
> rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
> unsigned worker_id, struct rte_mbuf *oldpkt)
> {
> @@ -71,7 +71,7 @@ rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
> }
> VERSION_SYMBOL(rte_distributor_get_pkt, _v20, 2.0);
>
> -int
> +int __vsym
> rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
> unsigned worker_id, struct rte_mbuf *oldpkt)
> {
> @@ -204,7 +204,7 @@ process_returns(struct rte_distributor_v20 *d)
> }
>
> /* process a set of packets to distribute them to workers */
> -int
> +int __vsym
> rte_distributor_process_v20(struct rte_distributor_v20 *d,
> struct rte_mbuf **mbufs, unsigned num_mbufs)
> {
> @@ -321,7 +321,7 @@ rte_distributor_process_v20(struct rte_distributor_v20 *d,
> VERSION_SYMBOL(rte_distributor_process, _v20, 2.0);
>
> /* return to the caller, packets returned from workers */
> -int
> +int __vsym
> rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
> struct rte_mbuf **mbufs, unsigned max_mbufs)
> {
> @@ -359,7 +359,7 @@ total_outstanding(const struct rte_distributor_v20 *d)
>
> /* flush the distributor, so that there are no outstanding packets in flight or
> * queued up. */
> -int
> +int __vsym
> rte_distributor_flush_v20(struct rte_distributor_v20 *d)
> {
> const unsigned flushed = total_outstanding(d);
> @@ -372,7 +372,7 @@ rte_distributor_flush_v20(struct rte_distributor_v20 *d)
> VERSION_SYMBOL(rte_distributor_flush, _v20, 2.0);
>
> /* clears the internal returns array in the distributor */
> -void
> +void __vsym
> rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
> {
> d->returns.start = d->returns.count = 0;
> @@ -383,7 +383,7 @@ rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
> VERSION_SYMBOL(rte_distributor_clear_returns, _v20, 2.0);
>
> /* creates a distributor instance */
> -struct rte_distributor_v20 *
> +struct rte_distributor_v20 * __vsym
> rte_distributor_create_v20(const char *name,
> unsigned socket_id,
> unsigned num_workers)
> diff --git a/lib/librte_eal/common/include/rte_function_versioning.h b/lib/librte_eal/common/include/rte_function_versioning.h
> index 55e88ffae..c924351d5 100644
> --- a/lib/librte_eal/common/include/rte_function_versioning.h
> +++ b/lib/librte_eal/common/include/rte_function_versioning.h
> @@ -42,16 +42,23 @@
> /*
> * VERSION_SYMBOL
> * Creates a symbol version table entry binding symbol <b>@DPDK_<n> to the internal
> - * function name <b>_<e>
> + * function name <b><e>
> */
> #define VERSION_SYMBOL(b, e, n) __asm__(".symver " RTE_STR(b) RTE_STR(e) ", " RTE_STR(b) "@DPDK_" RTE_STR(n))
>
> /*
> * BIND_DEFAULT_SYMBOL
> * Creates a symbol version entry instructing the linker to bind references to
> - * symbol <b> to the internal symbol <b>_<e>
> + * symbol <b> to the internal symbol <b><e>
> */
> #define BIND_DEFAULT_SYMBOL(b, e, n) __asm__(".symver " RTE_STR(b) RTE_STR(e) ", " RTE_STR(b) "@@DPDK_" RTE_STR(n))
> +
> +/*
> + * __vsym
> + * Annotation to be used in declaration of the internal symbol <b><e> to signal
> + * that it is being used as an implementation of a particular version of symbol
> + * <b>.
> + */
> #define __vsym __attribute__((used))
>
> /*
> diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
> index c96395e26..106916dc8 100644
> --- a/lib/librte_lpm/rte_lpm.c
> +++ b/lib/librte_lpm/rte_lpm.c
> @@ -90,7 +90,7 @@ depth_to_range(uint8_t depth)
> /*
> * Find an existing lpm table and return a pointer to it.
> */
> -struct rte_lpm_v20 *
> +struct rte_lpm_v20 * __vsym
> rte_lpm_find_existing_v20(const char *name)
> {
> struct rte_lpm_v20 *l = NULL;
> @@ -116,7 +116,7 @@ rte_lpm_find_existing_v20(const char *name)
> }
> VERSION_SYMBOL(rte_lpm_find_existing, _v20, 2.0);
>
> -struct rte_lpm *
> +struct rte_lpm * __vsym
> rte_lpm_find_existing_v1604(const char *name)
> {
> struct rte_lpm *l = NULL;
> @@ -147,7 +147,7 @@ MAP_STATIC_SYMBOL(struct rte_lpm *rte_lpm_find_existing(const char *name),
> /*
> * Allocates memory for LPM object
> */
> -struct rte_lpm_v20 *
> +struct rte_lpm_v20 * __vsym
> rte_lpm_create_v20(const char *name, int socket_id, int max_rules,
> __rte_unused int flags)
> {
> @@ -220,7 +220,7 @@ rte_lpm_create_v20(const char *name, int socket_id, int max_rules,
> }
> VERSION_SYMBOL(rte_lpm_create, _v20, 2.0);
>
> -struct rte_lpm *
> +struct rte_lpm * __vsym
> rte_lpm_create_v1604(const char *name, int socket_id,
> const struct rte_lpm_config *config)
> {
> @@ -329,7 +329,7 @@ MAP_STATIC_SYMBOL(
> /*
> * Deallocates memory for given LPM table.
> */
> -void
> +void __vsym
> rte_lpm_free_v20(struct rte_lpm_v20 *lpm)
> {
> struct rte_lpm_list *lpm_list;
> @@ -358,7 +358,7 @@ rte_lpm_free_v20(struct rte_lpm_v20 *lpm)
> }
> VERSION_SYMBOL(rte_lpm_free, _v20, 2.0);
>
> -void
> +void __vsym
> rte_lpm_free_v1604(struct rte_lpm *lpm)
> {
> struct rte_lpm_list *lpm_list;
> @@ -1177,7 +1177,7 @@ add_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
> /*
> * Add a route
> */
> -int
> +int __vsym
> rte_lpm_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
> uint8_t next_hop)
> {
> @@ -1218,7 +1218,7 @@ rte_lpm_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
> }
> VERSION_SYMBOL(rte_lpm_add, _v20, 2.0);
>
> -int
> +int __vsym
> rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
> uint32_t next_hop)
> {
> @@ -1264,7 +1264,7 @@ MAP_STATIC_SYMBOL(int rte_lpm_add(struct rte_lpm *lpm, uint32_t ip,
> /*
> * Look for a rule in the high-level rules table
> */
> -int
> +int __vsym
> rte_lpm_is_rule_present_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
> uint8_t *next_hop)
> {
> @@ -1291,7 +1291,7 @@ uint8_t *next_hop)
> }
> VERSION_SYMBOL(rte_lpm_is_rule_present, _v20, 2.0);
>
> -int
> +int __vsym
> rte_lpm_is_rule_present_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
> uint32_t *next_hop)
> {
> @@ -1844,7 +1844,7 @@ delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
> /*
> * Deletes a rule
> */
> -int
> +int __vsym
> rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
> {
> int32_t rule_to_delete_index, sub_rule_index;
> @@ -1898,7 +1898,7 @@ rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
> }
> VERSION_SYMBOL(rte_lpm_delete, _v20, 2.0);
>
> -int
> +int __vsym
> rte_lpm_delete_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
> {
> int32_t rule_to_delete_index, sub_rule_index;
> @@ -1957,7 +1957,7 @@ MAP_STATIC_SYMBOL(int rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip,
> /*
> * Delete all rules from the LPM table.
> */
> -void
> +void __vsym
> rte_lpm_delete_all_v20(struct rte_lpm_v20 *lpm)
> {
> /* Zero rule information. */
> @@ -1974,7 +1974,7 @@ rte_lpm_delete_all_v20(struct rte_lpm_v20 *lpm)
> }
> VERSION_SYMBOL(rte_lpm_delete_all, _v20, 2.0);
>
> -void
> +void __vsym
> rte_lpm_delete_all_v1604(struct rte_lpm *lpm)
> {
> /* Zero rule information. */
> diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
> index e20f82460..0d161dc32 100644
> --- a/lib/librte_lpm/rte_lpm6.c
> +++ b/lib/librte_lpm/rte_lpm6.c
> @@ -812,7 +812,7 @@ add_step(struct rte_lpm6 *lpm, struct rte_lpm6_tbl_entry *tbl,
> /*
> * Add a route
> */
> -int
> +int __vsym
> rte_lpm6_add_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
> uint8_t next_hop)
> {
> @@ -862,7 +862,7 @@ simulate_add(struct rte_lpm6 *lpm, const uint8_t *masked_ip, uint8_t depth)
> return 0;
> }
>
> -int
> +int __vsym
> rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
> uint32_t next_hop)
> {
> @@ -955,7 +955,7 @@ lookup_step(const struct rte_lpm6 *lpm, const struct rte_lpm6_tbl_entry *tbl,
> /*
> * Looks up an IP
> */
> -int
> +int __vsym
> rte_lpm6_lookup_v20(const struct rte_lpm6 *lpm, uint8_t *ip, uint8_t *next_hop)
> {
> uint32_t next_hop32 = 0;
> @@ -973,7 +973,7 @@ rte_lpm6_lookup_v20(const struct rte_lpm6 *lpm, uint8_t *ip, uint8_t *next_hop)
> }
> VERSION_SYMBOL(rte_lpm6_lookup, _v20, 2.0);
>
> -int
> +int __vsym
> rte_lpm6_lookup_v1705(const struct rte_lpm6 *lpm, uint8_t *ip,
> uint32_t *next_hop)
> {
> @@ -1008,7 +1008,7 @@ MAP_STATIC_SYMBOL(int rte_lpm6_lookup(const struct rte_lpm6 *lpm, uint8_t *ip,
> /*
> * Looks up a group of IP addresses
> */
> -int
> +int __vsym
> rte_lpm6_lookup_bulk_func_v20(const struct rte_lpm6 *lpm,
> uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
> int16_t * next_hops, unsigned n)
> @@ -1049,7 +1049,7 @@ rte_lpm6_lookup_bulk_func_v20(const struct rte_lpm6 *lpm,
> }
> VERSION_SYMBOL(rte_lpm6_lookup_bulk_func, _v20, 2.0);
>
> -int
> +int __vsym
> rte_lpm6_lookup_bulk_func_v1705(const struct rte_lpm6 *lpm,
> uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
> int32_t *next_hops, unsigned int n)
> @@ -1099,7 +1099,7 @@ MAP_STATIC_SYMBOL(int rte_lpm6_lookup_bulk_func(const struct rte_lpm6 *lpm,
> /*
> * Look for a rule in the high-level rules table
> */
> -int
> +int __vsym
> rte_lpm6_is_rule_present_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
> uint8_t *next_hop)
> {
> @@ -1119,7 +1119,7 @@ rte_lpm6_is_rule_present_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
> }
> VERSION_SYMBOL(rte_lpm6_is_rule_present, _v20, 2.0);
>
> -int
> +int __vsym
> rte_lpm6_is_rule_present_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
> uint32_t *next_hop)
> {
> diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
> index 3834c9473..381a9f43f 100644
> --- a/lib/librte_timer/rte_timer.c
> +++ b/lib/librte_timer/rte_timer.c
> @@ -131,7 +131,7 @@ rte_timer_data_dealloc(uint32_t id)
> return 0;
> }
>
> -void
> +void __vsym
> rte_timer_subsystem_init_v20(void)
> {
> unsigned lcore_id;
> @@ -153,7 +153,7 @@ VERSION_SYMBOL(rte_timer_subsystem_init, _v20, 2.0);
> * secondary processes should be empty, the zeroth entry can be shared by
> * multiple processes.
> */
> -int
> +int __vsym
> rte_timer_subsystem_init_v1905(void)
> {
> const struct rte_memzone *mz;
> @@ -551,7 +551,7 @@ __rte_timer_reset(struct rte_timer *tim, uint64_t expire,
> }
>
> /* Reset and start the timer associated with the timer handle tim */
> -int
> +int __vsym
> rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
> enum rte_timer_type type, unsigned int tim_lcore,
> rte_timer_cb_t fct, void *arg)
> @@ -574,7 +574,7 @@ rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
> }
> VERSION_SYMBOL(rte_timer_reset, _v20, 2.0);
>
> -int
> +int __vsym
> rte_timer_reset_v1905(struct rte_timer *tim, uint64_t ticks,
> enum rte_timer_type type, unsigned int tim_lcore,
> rte_timer_cb_t fct, void *arg)
> @@ -657,14 +657,14 @@ __rte_timer_stop(struct rte_timer *tim, int local_is_locked,
> }
>
> /* Stop the timer associated with the timer handle tim */
> -int
> +int __vsym
> rte_timer_stop_v20(struct rte_timer *tim)
> {
> return __rte_timer_stop(tim, 0, &default_timer_data);
> }
> VERSION_SYMBOL(rte_timer_stop, _v20, 2.0);
>
> -int
> +int __vsym
> rte_timer_stop_v1905(struct rte_timer *tim)
> {
> return rte_timer_alt_stop(default_data_id, tim);
> @@ -817,14 +817,14 @@ __rte_timer_manage(struct rte_timer_data *timer_data)
> priv_timer[lcore_id].running_tim = NULL;
> }
>
> -void
> +void __vsym
> rte_timer_manage_v20(void)
> {
> __rte_timer_manage(&default_timer_data);
> }
> VERSION_SYMBOL(rte_timer_manage, _v20, 2.0);
>
> -int
> +int __vsym
> rte_timer_manage_v1905(void)
> {
> struct rte_timer_data *timer_data;
> @@ -1074,14 +1074,14 @@ __rte_timer_dump_stats(struct rte_timer_data *timer_data __rte_unused, FILE *f)
> #endif
> }
>
> -void
> +void __vsym
> rte_timer_dump_stats_v20(FILE *f)
> {
> __rte_timer_dump_stats(&default_timer_data, f);
> }
> VERSION_SYMBOL(rte_timer_dump_stats, _v20, 2.0);
>
> -int
> +int __vsym
> rte_timer_dump_stats_v1905(FILE *f)
> {
> return rte_timer_alt_dump_stats(default_data_id, f);
> --
> 2.17.1
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: remove deprecated port count function
2019-10-28 11:38 0% ` Andrew Rybchenko
@ 2019-10-29 8:43 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2019-10-29 8:43 UTC (permalink / raw)
To: Andrew Rybchenko
Cc: Thomas Monjalon, Neil Horman, John McNamara, Marko Kovacevic,
Ferruh Yigit, dpdk-dev
On Mon, Oct 28, 2019 at 5:09 PM Andrew Rybchenko
<arybchenko@solarflare.com> wrote:
>
> On 10/28/19 1:49 PM, Thomas Monjalon wrote:
> > The function rte_eth_dev_count() was marked as deprecated in DPDK 18.05
> > in commit d9a42a69febf ("ethdev: deprecate port count function").
> > It was planned to be removed after 19.11 LTS release,
> > but given we must not break ABI between 19.11 and 20.11,
> > it is removed now.
> >
> > Note the ABI version is not dumped in this commit
> > because other changes already did.
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: Jerin Jacob <jerinj@marvell.com>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 01/11] build: annotate versioned symbols with __vsym macro
@ 2019-10-28 14:21 2% ` Andrzej Ostruszka
2019-10-29 10:49 0% ` Neil Horman
1 sibling, 1 reply; 200+ results
From: Andrzej Ostruszka @ 2019-10-28 14:21 UTC (permalink / raw)
To: dev, John McNamara, Marko Kovacevic, David Hunt, Neil Horman,
Bruce Richardson, Vladimir Medvedkin, Robert Sanford,
Erik Gabriel Carrillo
Cc: mattias.ronnblom, stephen
Every implementation of a particular version of given symbol needs to be
marked in its declaration as such (using `__vsym` macro). This patch
fixes this and also clarifies the documentation about that.
Signed-off-by: Andrzej Ostruszka <aostruszka@marvell.com>
---
doc/guides/contributing/versioning.rst | 18 ++++++++----
lib/librte_distributor/rte_distributor.c | 18 ++++++------
lib/librte_distributor/rte_distributor_v20.c | 18 ++++++------
.../common/include/rte_function_versioning.h | 11 ++++++--
lib/librte_lpm/rte_lpm.c | 28 +++++++++----------
lib/librte_lpm/rte_lpm6.c | 16 +++++------
lib/librte_timer/rte_timer.c | 20 ++++++-------
7 files changed, 71 insertions(+), 58 deletions(-)
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 64984c54e..fcd2d50f1 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -215,16 +215,20 @@ library so that older binaries need not be immediately recompiled.
The macros exported are:
* ``VERSION_SYMBOL(b, e, n)``: Creates a symbol version table entry binding
- versioned symbol ``b@DPDK_n`` to the internal function ``b_e``.
+ versioned symbol ``b@DPDK_n`` to the internal function ``be``.
* ``BIND_DEFAULT_SYMBOL(b, e, n)``: Creates a symbol version entry instructing
the linker to bind references to symbol ``b`` to the internal symbol
- ``b_e``.
+ ``be``.
* ``MAP_STATIC_SYMBOL(f, p)``: Declare the prototype ``f``, and map it to the
fully qualified function ``p``, so that if a symbol becomes versioned, it
can still be mapped back to the public symbol name.
+* ``__vsym``: Annotation to be used in a declaration of the internal symbol
+ ``be`` to signal that it is being used as an implementation of a particular
+ version of symbol ``b``.
+
Examples of ABI Macro use
^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -345,8 +349,9 @@ with the public symbol name
.. code-block:: c
- struct rte_acl_ctx *
+ -struct rte_acl_ctx *
-rte_acl_create(const struct rte_acl_param *param)
+ +struct rte_acl_ctx * __vsym
+rte_acl_create_v20(const struct rte_acl_param *param)
{
size_t sz;
@@ -354,7 +359,8 @@ with the public symbol name
...
Note that the base name of the symbol was kept intact, as this is conducive to
-the macros used for versioning symbols. That is our next step, mapping this new
+the macros used for versioning symbols and we have annotated the function as an
+implementation of versioned symbol. That is our next step, mapping this new
symbol name to the initial symbol name at version node 2.0. Immediately after
the function, we add this line of code
@@ -374,7 +380,7 @@ name, with a different suffix, and implement it appropriately
.. code-block:: c
- struct rte_acl_ctx *
+ struct rte_acl_ctx * __vsym
rte_acl_create_v21(const struct rte_acl_param *param, int debug);
{
struct rte_acl_ctx *ctx = rte_acl_create_v20(param);
@@ -423,7 +429,7 @@ defined, we add this
.. code-block:: c
- struct rte_acl_ctx *
+ struct rte_acl_ctx * __vsym
rte_acl_create_v21(const struct rte_acl_param *param, int debug)
{
...
diff --git a/lib/librte_distributor/rte_distributor.c b/lib/librte_distributor/rte_distributor.c
index 7df97df92..2cc32ddba 100644
--- a/lib/librte_distributor/rte_distributor.c
+++ b/lib/librte_distributor/rte_distributor.c
@@ -32,7 +32,7 @@ EAL_REGISTER_TAILQ(rte_dist_burst_tailq)
/**** Burst Packet APIs called by workers ****/
-void
+void __vsym
rte_distributor_request_pkt_v1705(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **oldpkt,
unsigned int count)
@@ -89,7 +89,7 @@ MAP_STATIC_SYMBOL(void rte_distributor_request_pkt(struct rte_distributor *d,
unsigned int count),
rte_distributor_request_pkt_v1705);
-int
+int __vsym
rte_distributor_poll_pkt_v1705(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **pkts)
{
@@ -134,7 +134,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_poll_pkt(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **pkts),
rte_distributor_poll_pkt_v1705);
-int
+int __vsym
rte_distributor_get_pkt_v1705(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **pkts,
struct rte_mbuf **oldpkt, unsigned int return_count)
@@ -169,7 +169,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_get_pkt(struct rte_distributor *d,
struct rte_mbuf **oldpkt, unsigned int return_count),
rte_distributor_get_pkt_v1705);
-int
+int __vsym
rte_distributor_return_pkt_v1705(struct rte_distributor *d,
unsigned int worker_id, struct rte_mbuf **oldpkt, int num)
{
@@ -359,7 +359,7 @@ release(struct rte_distributor *d, unsigned int wkr)
/* process a set of packets to distribute them to workers */
-int
+int __vsym
rte_distributor_process_v1705(struct rte_distributor *d,
struct rte_mbuf **mbufs, unsigned int num_mbufs)
{
@@ -506,7 +506,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_process(struct rte_distributor *d,
rte_distributor_process_v1705);
/* return to the caller, packets returned from workers */
-int
+int __vsym
rte_distributor_returned_pkts_v1705(struct rte_distributor *d,
struct rte_mbuf **mbufs, unsigned int max_mbufs)
{
@@ -556,7 +556,7 @@ total_outstanding(const struct rte_distributor *d)
* Flush the distributor, so that there are no outstanding packets in flight or
* queued up.
*/
-int
+int __vsym
rte_distributor_flush_v1705(struct rte_distributor *d)
{
unsigned int flushed;
@@ -591,7 +591,7 @@ MAP_STATIC_SYMBOL(int rte_distributor_flush(struct rte_distributor *d),
rte_distributor_flush_v1705);
/* clears the internal returns array in the distributor */
-void
+void __vsym
rte_distributor_clear_returns_v1705(struct rte_distributor *d)
{
unsigned int wkr;
@@ -613,7 +613,7 @@ MAP_STATIC_SYMBOL(void rte_distributor_clear_returns(struct rte_distributor *d),
rte_distributor_clear_returns_v1705);
/* creates a distributor instance */
-struct rte_distributor *
+struct rte_distributor * __vsym
rte_distributor_create_v1705(const char *name,
unsigned int socket_id,
unsigned int num_workers,
diff --git a/lib/librte_distributor/rte_distributor_v20.c b/lib/librte_distributor/rte_distributor_v20.c
index db6c49258..7a6fddf55 100644
--- a/lib/librte_distributor/rte_distributor_v20.c
+++ b/lib/librte_distributor/rte_distributor_v20.c
@@ -27,7 +27,7 @@ EAL_REGISTER_TAILQ(rte_distributor_tailq)
/**** APIs called by workers ****/
-void
+void __vsym
rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
@@ -43,7 +43,7 @@ rte_distributor_request_pkt_v20(struct rte_distributor_v20 *d,
}
VERSION_SYMBOL(rte_distributor_request_pkt, _v20, 2.0);
-struct rte_mbuf *
+struct rte_mbuf * __vsym
rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
unsigned worker_id)
{
@@ -59,7 +59,7 @@ rte_distributor_poll_pkt_v20(struct rte_distributor_v20 *d,
}
VERSION_SYMBOL(rte_distributor_poll_pkt, _v20, 2.0);
-struct rte_mbuf *
+struct rte_mbuf * __vsym
rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
@@ -71,7 +71,7 @@ rte_distributor_get_pkt_v20(struct rte_distributor_v20 *d,
}
VERSION_SYMBOL(rte_distributor_get_pkt, _v20, 2.0);
-int
+int __vsym
rte_distributor_return_pkt_v20(struct rte_distributor_v20 *d,
unsigned worker_id, struct rte_mbuf *oldpkt)
{
@@ -204,7 +204,7 @@ process_returns(struct rte_distributor_v20 *d)
}
/* process a set of packets to distribute them to workers */
-int
+int __vsym
rte_distributor_process_v20(struct rte_distributor_v20 *d,
struct rte_mbuf **mbufs, unsigned num_mbufs)
{
@@ -321,7 +321,7 @@ rte_distributor_process_v20(struct rte_distributor_v20 *d,
VERSION_SYMBOL(rte_distributor_process, _v20, 2.0);
/* return to the caller, packets returned from workers */
-int
+int __vsym
rte_distributor_returned_pkts_v20(struct rte_distributor_v20 *d,
struct rte_mbuf **mbufs, unsigned max_mbufs)
{
@@ -359,7 +359,7 @@ total_outstanding(const struct rte_distributor_v20 *d)
/* flush the distributor, so that there are no outstanding packets in flight or
* queued up. */
-int
+int __vsym
rte_distributor_flush_v20(struct rte_distributor_v20 *d)
{
const unsigned flushed = total_outstanding(d);
@@ -372,7 +372,7 @@ rte_distributor_flush_v20(struct rte_distributor_v20 *d)
VERSION_SYMBOL(rte_distributor_flush, _v20, 2.0);
/* clears the internal returns array in the distributor */
-void
+void __vsym
rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
{
d->returns.start = d->returns.count = 0;
@@ -383,7 +383,7 @@ rte_distributor_clear_returns_v20(struct rte_distributor_v20 *d)
VERSION_SYMBOL(rte_distributor_clear_returns, _v20, 2.0);
/* creates a distributor instance */
-struct rte_distributor_v20 *
+struct rte_distributor_v20 * __vsym
rte_distributor_create_v20(const char *name,
unsigned socket_id,
unsigned num_workers)
diff --git a/lib/librte_eal/common/include/rte_function_versioning.h b/lib/librte_eal/common/include/rte_function_versioning.h
index 55e88ffae..c924351d5 100644
--- a/lib/librte_eal/common/include/rte_function_versioning.h
+++ b/lib/librte_eal/common/include/rte_function_versioning.h
@@ -42,16 +42,23 @@
/*
* VERSION_SYMBOL
* Creates a symbol version table entry binding symbol <b>@DPDK_<n> to the internal
- * function name <b>_<e>
+ * function name <b><e>
*/
#define VERSION_SYMBOL(b, e, n) __asm__(".symver " RTE_STR(b) RTE_STR(e) ", " RTE_STR(b) "@DPDK_" RTE_STR(n))
/*
* BIND_DEFAULT_SYMBOL
* Creates a symbol version entry instructing the linker to bind references to
- * symbol <b> to the internal symbol <b>_<e>
+ * symbol <b> to the internal symbol <b><e>
*/
#define BIND_DEFAULT_SYMBOL(b, e, n) __asm__(".symver " RTE_STR(b) RTE_STR(e) ", " RTE_STR(b) "@@DPDK_" RTE_STR(n))
+
+/*
+ * __vsym
+ * Annotation to be used in declaration of the internal symbol <b><e> to signal
+ * that it is being used as an implementation of a particular version of symbol
+ * <b>.
+ */
#define __vsym __attribute__((used))
/*
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index c96395e26..106916dc8 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -90,7 +90,7 @@ depth_to_range(uint8_t depth)
/*
* Find an existing lpm table and return a pointer to it.
*/
-struct rte_lpm_v20 *
+struct rte_lpm_v20 * __vsym
rte_lpm_find_existing_v20(const char *name)
{
struct rte_lpm_v20 *l = NULL;
@@ -116,7 +116,7 @@ rte_lpm_find_existing_v20(const char *name)
}
VERSION_SYMBOL(rte_lpm_find_existing, _v20, 2.0);
-struct rte_lpm *
+struct rte_lpm * __vsym
rte_lpm_find_existing_v1604(const char *name)
{
struct rte_lpm *l = NULL;
@@ -147,7 +147,7 @@ MAP_STATIC_SYMBOL(struct rte_lpm *rte_lpm_find_existing(const char *name),
/*
* Allocates memory for LPM object
*/
-struct rte_lpm_v20 *
+struct rte_lpm_v20 * __vsym
rte_lpm_create_v20(const char *name, int socket_id, int max_rules,
__rte_unused int flags)
{
@@ -220,7 +220,7 @@ rte_lpm_create_v20(const char *name, int socket_id, int max_rules,
}
VERSION_SYMBOL(rte_lpm_create, _v20, 2.0);
-struct rte_lpm *
+struct rte_lpm * __vsym
rte_lpm_create_v1604(const char *name, int socket_id,
const struct rte_lpm_config *config)
{
@@ -329,7 +329,7 @@ MAP_STATIC_SYMBOL(
/*
* Deallocates memory for given LPM table.
*/
-void
+void __vsym
rte_lpm_free_v20(struct rte_lpm_v20 *lpm)
{
struct rte_lpm_list *lpm_list;
@@ -358,7 +358,7 @@ rte_lpm_free_v20(struct rte_lpm_v20 *lpm)
}
VERSION_SYMBOL(rte_lpm_free, _v20, 2.0);
-void
+void __vsym
rte_lpm_free_v1604(struct rte_lpm *lpm)
{
struct rte_lpm_list *lpm_list;
@@ -1177,7 +1177,7 @@ add_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
/*
* Add a route
*/
-int
+int __vsym
rte_lpm_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
uint8_t next_hop)
{
@@ -1218,7 +1218,7 @@ rte_lpm_add_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
}
VERSION_SYMBOL(rte_lpm_add, _v20, 2.0);
-int
+int __vsym
rte_lpm_add_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t next_hop)
{
@@ -1264,7 +1264,7 @@ MAP_STATIC_SYMBOL(int rte_lpm_add(struct rte_lpm *lpm, uint32_t ip,
/*
* Look for a rule in the high-level rules table
*/
-int
+int __vsym
rte_lpm_is_rule_present_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth,
uint8_t *next_hop)
{
@@ -1291,7 +1291,7 @@ uint8_t *next_hop)
}
VERSION_SYMBOL(rte_lpm_is_rule_present, _v20, 2.0);
-int
+int __vsym
rte_lpm_is_rule_present_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t *next_hop)
{
@@ -1844,7 +1844,7 @@ delete_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked,
/*
* Deletes a rule
*/
-int
+int __vsym
rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
{
int32_t rule_to_delete_index, sub_rule_index;
@@ -1898,7 +1898,7 @@ rte_lpm_delete_v20(struct rte_lpm_v20 *lpm, uint32_t ip, uint8_t depth)
}
VERSION_SYMBOL(rte_lpm_delete, _v20, 2.0);
-int
+int __vsym
rte_lpm_delete_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
{
int32_t rule_to_delete_index, sub_rule_index;
@@ -1957,7 +1957,7 @@ MAP_STATIC_SYMBOL(int rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip,
/*
* Delete all rules from the LPM table.
*/
-void
+void __vsym
rte_lpm_delete_all_v20(struct rte_lpm_v20 *lpm)
{
/* Zero rule information. */
@@ -1974,7 +1974,7 @@ rte_lpm_delete_all_v20(struct rte_lpm_v20 *lpm)
}
VERSION_SYMBOL(rte_lpm_delete_all, _v20, 2.0);
-void
+void __vsym
rte_lpm_delete_all_v1604(struct rte_lpm *lpm)
{
/* Zero rule information. */
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index e20f82460..0d161dc32 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -812,7 +812,7 @@ add_step(struct rte_lpm6 *lpm, struct rte_lpm6_tbl_entry *tbl,
/*
* Add a route
*/
-int
+int __vsym
rte_lpm6_add_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint8_t next_hop)
{
@@ -862,7 +862,7 @@ simulate_add(struct rte_lpm6 *lpm, const uint8_t *masked_ip, uint8_t depth)
return 0;
}
-int
+int __vsym
rte_lpm6_add_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint32_t next_hop)
{
@@ -955,7 +955,7 @@ lookup_step(const struct rte_lpm6 *lpm, const struct rte_lpm6_tbl_entry *tbl,
/*
* Looks up an IP
*/
-int
+int __vsym
rte_lpm6_lookup_v20(const struct rte_lpm6 *lpm, uint8_t *ip, uint8_t *next_hop)
{
uint32_t next_hop32 = 0;
@@ -973,7 +973,7 @@ rte_lpm6_lookup_v20(const struct rte_lpm6 *lpm, uint8_t *ip, uint8_t *next_hop)
}
VERSION_SYMBOL(rte_lpm6_lookup, _v20, 2.0);
-int
+int __vsym
rte_lpm6_lookup_v1705(const struct rte_lpm6 *lpm, uint8_t *ip,
uint32_t *next_hop)
{
@@ -1008,7 +1008,7 @@ MAP_STATIC_SYMBOL(int rte_lpm6_lookup(const struct rte_lpm6 *lpm, uint8_t *ip,
/*
* Looks up a group of IP addresses
*/
-int
+int __vsym
rte_lpm6_lookup_bulk_func_v20(const struct rte_lpm6 *lpm,
uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
int16_t * next_hops, unsigned n)
@@ -1049,7 +1049,7 @@ rte_lpm6_lookup_bulk_func_v20(const struct rte_lpm6 *lpm,
}
VERSION_SYMBOL(rte_lpm6_lookup_bulk_func, _v20, 2.0);
-int
+int __vsym
rte_lpm6_lookup_bulk_func_v1705(const struct rte_lpm6 *lpm,
uint8_t ips[][RTE_LPM6_IPV6_ADDR_SIZE],
int32_t *next_hops, unsigned int n)
@@ -1099,7 +1099,7 @@ MAP_STATIC_SYMBOL(int rte_lpm6_lookup_bulk_func(const struct rte_lpm6 *lpm,
/*
* Look for a rule in the high-level rules table
*/
-int
+int __vsym
rte_lpm6_is_rule_present_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint8_t *next_hop)
{
@@ -1119,7 +1119,7 @@ rte_lpm6_is_rule_present_v20(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
}
VERSION_SYMBOL(rte_lpm6_is_rule_present, _v20, 2.0);
-int
+int __vsym
rte_lpm6_is_rule_present_v1705(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint32_t *next_hop)
{
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 3834c9473..381a9f43f 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -131,7 +131,7 @@ rte_timer_data_dealloc(uint32_t id)
return 0;
}
-void
+void __vsym
rte_timer_subsystem_init_v20(void)
{
unsigned lcore_id;
@@ -153,7 +153,7 @@ VERSION_SYMBOL(rte_timer_subsystem_init, _v20, 2.0);
* secondary processes should be empty, the zeroth entry can be shared by
* multiple processes.
*/
-int
+int __vsym
rte_timer_subsystem_init_v1905(void)
{
const struct rte_memzone *mz;
@@ -551,7 +551,7 @@ __rte_timer_reset(struct rte_timer *tim, uint64_t expire,
}
/* Reset and start the timer associated with the timer handle tim */
-int
+int __vsym
rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
enum rte_timer_type type, unsigned int tim_lcore,
rte_timer_cb_t fct, void *arg)
@@ -574,7 +574,7 @@ rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
}
VERSION_SYMBOL(rte_timer_reset, _v20, 2.0);
-int
+int __vsym
rte_timer_reset_v1905(struct rte_timer *tim, uint64_t ticks,
enum rte_timer_type type, unsigned int tim_lcore,
rte_timer_cb_t fct, void *arg)
@@ -657,14 +657,14 @@ __rte_timer_stop(struct rte_timer *tim, int local_is_locked,
}
/* Stop the timer associated with the timer handle tim */
-int
+int __vsym
rte_timer_stop_v20(struct rte_timer *tim)
{
return __rte_timer_stop(tim, 0, &default_timer_data);
}
VERSION_SYMBOL(rte_timer_stop, _v20, 2.0);
-int
+int __vsym
rte_timer_stop_v1905(struct rte_timer *tim)
{
return rte_timer_alt_stop(default_data_id, tim);
@@ -817,14 +817,14 @@ __rte_timer_manage(struct rte_timer_data *timer_data)
priv_timer[lcore_id].running_tim = NULL;
}
-void
+void __vsym
rte_timer_manage_v20(void)
{
__rte_timer_manage(&default_timer_data);
}
VERSION_SYMBOL(rte_timer_manage, _v20, 2.0);
-int
+int __vsym
rte_timer_manage_v1905(void)
{
struct rte_timer_data *timer_data;
@@ -1074,14 +1074,14 @@ __rte_timer_dump_stats(struct rte_timer_data *timer_data __rte_unused, FILE *f)
#endif
}
-void
+void __vsym
rte_timer_dump_stats_v20(FILE *f)
{
__rte_timer_dump_stats(&default_timer_data, f);
}
VERSION_SYMBOL(rte_timer_dump_stats, _v20, 2.0);
-int
+int __vsym
rte_timer_dump_stats_v1905(FILE *f)
{
return rte_timer_alt_dump_stats(default_data_id, f);
--
2.17.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH] ethdev: remove deprecated port count function
2019-10-28 10:49 4% [dpdk-dev] [PATCH] ethdev: remove deprecated port count function Thomas Monjalon
2019-10-28 11:05 0% ` David Marchand
2019-10-28 11:38 0% ` Andrew Rybchenko
@ 2019-10-28 13:03 0% ` Neil Horman
2019-10-31 18:52 0% ` Ferruh Yigit
2 siblings, 1 reply; 200+ results
From: Neil Horman @ 2019-10-28 13:03 UTC (permalink / raw)
To: Thomas Monjalon
Cc: John McNamara, Marko Kovacevic, Ferruh Yigit, Andrew Rybchenko, dev
On Mon, Oct 28, 2019 at 11:49:34AM +0100, Thomas Monjalon wrote:
> The function rte_eth_dev_count() was marked as deprecated in DPDK 18.05
> in commit d9a42a69febf ("ethdev: deprecate port count function").
> It was planned to be removed after 19.11 LTS release,
> but given we must not break ABI between 19.11 and 20.11,
> it is removed now.
>
> Note the ABI version is not dumped in this commit
> because other changes already did.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> doc/guides/rel_notes/deprecation.rst | 5 -----
> doc/guides/rel_notes/release_19_11.rst | 5 +++++
> lib/librte_ethdev/rte_ethdev.c | 6 ------
> lib/librte_ethdev/rte_ethdev.h | 15 ---------------
> lib/librte_ethdev/rte_ethdev_version.map | 1 -
> 5 files changed, 5 insertions(+), 27 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 4249aab833..c10dc301b2 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -48,11 +48,6 @@ Deprecation Notices
> structure would be made internal (or removed if all dependencies are cleared)
> in future releases.
>
> -* ethdev: The function ``rte_eth_dev_count`` will be removed in DPDK 20.02.
> - It is replaced by the function ``rte_eth_dev_count_avail``.
> - If the intent is to iterate over ports, ``RTE_ETH_FOREACH_*`` macros
> - are better port iterators.
> -
> * ethdev: the legacy filter API, including
> ``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as well
> as filter types MACVLAN, ETHERTYPE, FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR,
> diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
> index ae8e7b2f09..fdba8af04a 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -333,6 +333,11 @@ API Changes
> * ethdev: changed ``rte_eth_dev_owner_delete`` return value from ``void`` to
> ``int`` to provide a way to report various error conditions.
>
> +* ethdev: The deprecated function ``rte_eth_dev_count`` was removed.
> + The function ``rte_eth_dev_count_avail`` is a drop-in replacement.
> + If the intent is to iterate over ports, ``RTE_ETH_FOREACH_*`` macros
> + are better port iterators.
> +
> * event: The function ``rte_event_eth_tx_adapter_enqueue`` takes an additional
> input as ``flags``. Flag ``RTE_EVENT_ETH_TX_ADAPTER_ENQUEUE_SAME_DEST`` which
> has been introduced in this release is used when used when all the packets
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 7743205d38..809da09cfc 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -772,12 +772,6 @@ rte_eth_dev_get_sec_ctx(uint16_t port_id)
> return rte_eth_devices[port_id].security_ctx;
> }
>
> -uint16_t
> -rte_eth_dev_count(void)
> -{
> - return rte_eth_dev_count_avail();
> -}
> -
> uint16_t
> rte_eth_dev_count_avail(void)
> {
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index c36c1b631f..98b1db8a6e 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1653,21 +1653,6 @@ __rte_experimental
> int rte_eth_dev_owner_get(const uint16_t port_id,
> struct rte_eth_dev_owner *owner);
>
> -/**
> - * Get the total number of Ethernet devices that have been successfully
> - * initialized by the matching Ethernet driver during the PCI probing phase
> - * and that are available for applications to use. These devices must be
> - * accessed by using the ``RTE_ETH_FOREACH_DEV()`` macro to deal with
> - * non-contiguous ranges of devices.
> - * These non-contiguous ranges can be created by calls to hotplug functions or
> - * by some PMDs.
> - *
> - * @return
> - * - The total number of usable Ethernet devices.
> - */
> -__rte_deprecated
> -uint16_t rte_eth_dev_count(void);
> -
> /**
> * Get the number of ports which are usable for the application.
> *
> diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
> index e59d51648f..4b31668a55 100644
> --- a/lib/librte_ethdev/rte_ethdev_version.map
> +++ b/lib/librte_ethdev/rte_ethdev_version.map
> @@ -12,7 +12,6 @@ DPDK_2.2 {
> rte_eth_dev_callback_unregister;
> rte_eth_dev_close;
> rte_eth_dev_configure;
> - rte_eth_dev_count;
> rte_eth_dev_default_mac_addr_set;
> rte_eth_dev_filter_supported;
> rte_eth_dev_flow_ctrl_get;
> --
> 2.23.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: remove deprecated port count function
2019-10-28 10:49 4% [dpdk-dev] [PATCH] ethdev: remove deprecated port count function Thomas Monjalon
2019-10-28 11:05 0% ` David Marchand
@ 2019-10-28 11:38 0% ` Andrew Rybchenko
2019-10-29 8:43 0% ` Jerin Jacob
2019-10-28 13:03 0% ` Neil Horman
2 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-10-28 11:38 UTC (permalink / raw)
To: Thomas Monjalon, Neil Horman, John McNamara, Marko Kovacevic,
Ferruh Yigit
Cc: dev
On 10/28/19 1:49 PM, Thomas Monjalon wrote:
> The function rte_eth_dev_count() was marked as deprecated in DPDK 18.05
> in commit d9a42a69febf ("ethdev: deprecate port count function").
> It was planned to be removed after 19.11 LTS release,
> but given we must not break ABI between 19.11 and 20.11,
> it is removed now.
>
> Note the ABI version is not dumped in this commit
> because other changes already did.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: remove deprecated port count function
2019-10-28 10:49 4% [dpdk-dev] [PATCH] ethdev: remove deprecated port count function Thomas Monjalon
@ 2019-10-28 11:05 0% ` David Marchand
2019-10-28 11:38 0% ` Andrew Rybchenko
2019-10-28 13:03 0% ` Neil Horman
2 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-10-28 11:05 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Neil Horman, John McNamara, Marko Kovacevic, Ferruh Yigit,
Andrew Rybchenko, dev
On Mon, Oct 28, 2019 at 11:50 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> The function rte_eth_dev_count() was marked as deprecated in DPDK 18.05
> in commit d9a42a69febf ("ethdev: deprecate port count function").
> It was planned to be removed after 19.11 LTS release,
> but given we must not break ABI between 19.11 and 20.11,
> it is removed now.
>
> Note the ABI version is not dumped in this commit
> because other changes already did.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> doc/guides/rel_notes/deprecation.rst | 5 -----
> doc/guides/rel_notes/release_19_11.rst | 5 +++++
> lib/librte_ethdev/rte_ethdev.c | 6 ------
> lib/librte_ethdev/rte_ethdev.h | 15 ---------------
> lib/librte_ethdev/rte_ethdev_version.map | 1 -
> 5 files changed, 5 insertions(+), 27 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 4249aab833..c10dc301b2 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -48,11 +48,6 @@ Deprecation Notices
> structure would be made internal (or removed if all dependencies are cleared)
> in future releases.
>
> -* ethdev: The function ``rte_eth_dev_count`` will be removed in DPDK 20.02.
> - It is replaced by the function ``rte_eth_dev_count_avail``.
> - If the intent is to iterate over ports, ``RTE_ETH_FOREACH_*`` macros
> - are better port iterators.
> -
> * ethdev: the legacy filter API, including
> ``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as well
> as filter types MACVLAN, ETHERTYPE, FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR,
> diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
> index ae8e7b2f09..fdba8af04a 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -333,6 +333,11 @@ API Changes
> * ethdev: changed ``rte_eth_dev_owner_delete`` return value from ``void`` to
> ``int`` to provide a way to report various error conditions.
>
> +* ethdev: The deprecated function ``rte_eth_dev_count`` was removed.
> + The function ``rte_eth_dev_count_avail`` is a drop-in replacement.
> + If the intent is to iterate over ports, ``RTE_ETH_FOREACH_*`` macros
> + are better port iterators.
> +
> * event: The function ``rte_event_eth_tx_adapter_enqueue`` takes an additional
> input as ``flags``. Flag ``RTE_EVENT_ETH_TX_ADAPTER_ENQUEUE_SAME_DEST`` which
> has been introduced in this release is used when used when all the packets
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 7743205d38..809da09cfc 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -772,12 +772,6 @@ rte_eth_dev_get_sec_ctx(uint16_t port_id)
> return rte_eth_devices[port_id].security_ctx;
> }
>
> -uint16_t
> -rte_eth_dev_count(void)
> -{
> - return rte_eth_dev_count_avail();
> -}
> -
> uint16_t
> rte_eth_dev_count_avail(void)
> {
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index c36c1b631f..98b1db8a6e 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1653,21 +1653,6 @@ __rte_experimental
> int rte_eth_dev_owner_get(const uint16_t port_id,
> struct rte_eth_dev_owner *owner);
>
> -/**
> - * Get the total number of Ethernet devices that have been successfully
> - * initialized by the matching Ethernet driver during the PCI probing phase
> - * and that are available for applications to use. These devices must be
> - * accessed by using the ``RTE_ETH_FOREACH_DEV()`` macro to deal with
> - * non-contiguous ranges of devices.
> - * These non-contiguous ranges can be created by calls to hotplug functions or
> - * by some PMDs.
> - *
> - * @return
> - * - The total number of usable Ethernet devices.
> - */
> -__rte_deprecated
> -uint16_t rte_eth_dev_count(void);
> -
> /**
> * Get the number of ports which are usable for the application.
> *
> diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
> index e59d51648f..4b31668a55 100644
> --- a/lib/librte_ethdev/rte_ethdev_version.map
> +++ b/lib/librte_ethdev/rte_ethdev_version.map
> @@ -12,7 +12,6 @@ DPDK_2.2 {
> rte_eth_dev_callback_unregister;
> rte_eth_dev_close;
> rte_eth_dev_configure;
> - rte_eth_dev_count;
> rte_eth_dev_default_mac_addr_set;
> rte_eth_dev_filter_supported;
> rte_eth_dev_flow_ctrl_get;
> --
> 2.23.0
>
Reviewed-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] ethdev: remove deprecated port count function
@ 2019-10-28 10:49 4% Thomas Monjalon
2019-10-28 11:05 0% ` David Marchand
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Thomas Monjalon @ 2019-10-28 10:49 UTC (permalink / raw)
To: Neil Horman, John McNamara, Marko Kovacevic, Ferruh Yigit,
Andrew Rybchenko
Cc: dev
The function rte_eth_dev_count() was marked as deprecated in DPDK 18.05
in commit d9a42a69febf ("ethdev: deprecate port count function").
It was planned to be removed after 19.11 LTS release,
but given we must not break ABI between 19.11 and 20.11,
it is removed now.
Note the ABI version is not dumped in this commit
because other changes already did.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
doc/guides/rel_notes/deprecation.rst | 5 -----
doc/guides/rel_notes/release_19_11.rst | 5 +++++
lib/librte_ethdev/rte_ethdev.c | 6 ------
lib/librte_ethdev/rte_ethdev.h | 15 ---------------
lib/librte_ethdev/rte_ethdev_version.map | 1 -
5 files changed, 5 insertions(+), 27 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 4249aab833..c10dc301b2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -48,11 +48,6 @@ Deprecation Notices
structure would be made internal (or removed if all dependencies are cleared)
in future releases.
-* ethdev: The function ``rte_eth_dev_count`` will be removed in DPDK 20.02.
- It is replaced by the function ``rte_eth_dev_count_avail``.
- If the intent is to iterate over ports, ``RTE_ETH_FOREACH_*`` macros
- are better port iterators.
-
* ethdev: the legacy filter API, including
``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as well
as filter types MACVLAN, ETHERTYPE, FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR,
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index ae8e7b2f09..fdba8af04a 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -333,6 +333,11 @@ API Changes
* ethdev: changed ``rte_eth_dev_owner_delete`` return value from ``void`` to
``int`` to provide a way to report various error conditions.
+* ethdev: The deprecated function ``rte_eth_dev_count`` was removed.
+ The function ``rte_eth_dev_count_avail`` is a drop-in replacement.
+ If the intent is to iterate over ports, ``RTE_ETH_FOREACH_*`` macros
+ are better port iterators.
+
* event: The function ``rte_event_eth_tx_adapter_enqueue`` takes an additional
input as ``flags``. Flag ``RTE_EVENT_ETH_TX_ADAPTER_ENQUEUE_SAME_DEST`` which
has been introduced in this release is used when used when all the packets
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 7743205d38..809da09cfc 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -772,12 +772,6 @@ rte_eth_dev_get_sec_ctx(uint16_t port_id)
return rte_eth_devices[port_id].security_ctx;
}
-uint16_t
-rte_eth_dev_count(void)
-{
- return rte_eth_dev_count_avail();
-}
-
uint16_t
rte_eth_dev_count_avail(void)
{
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index c36c1b631f..98b1db8a6e 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1653,21 +1653,6 @@ __rte_experimental
int rte_eth_dev_owner_get(const uint16_t port_id,
struct rte_eth_dev_owner *owner);
-/**
- * Get the total number of Ethernet devices that have been successfully
- * initialized by the matching Ethernet driver during the PCI probing phase
- * and that are available for applications to use. These devices must be
- * accessed by using the ``RTE_ETH_FOREACH_DEV()`` macro to deal with
- * non-contiguous ranges of devices.
- * These non-contiguous ranges can be created by calls to hotplug functions or
- * by some PMDs.
- *
- * @return
- * - The total number of usable Ethernet devices.
- */
-__rte_deprecated
-uint16_t rte_eth_dev_count(void);
-
/**
* Get the number of ports which are usable for the application.
*
diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
index e59d51648f..4b31668a55 100644
--- a/lib/librte_ethdev/rte_ethdev_version.map
+++ b/lib/librte_ethdev/rte_ethdev_version.map
@@ -12,7 +12,6 @@ DPDK_2.2 {
rte_eth_dev_callback_unregister;
rte_eth_dev_close;
rte_eth_dev_configure;
- rte_eth_dev_count;
rte_eth_dev_default_mac_addr_set;
rte_eth_dev_filter_supported;
rte_eth_dev_flow_ctrl_get;
--
2.23.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 2/4] doc: changes to abi policy introducing major abi versions
@ 2019-10-28 10:02 5% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-10-28 10:02 UTC (permalink / raw)
To: Ray Kinsella
Cc: dev, stephen, bruce.richardson, ferruh.yigit, konstantin.ananyev,
jerinj, olivier.matz, nhorman, maxime.coquelin, john.mcnamara,
marko.kovacevic, hemant.agrawal, ktraynor, aconole
25/10/2019 11:10, Ray Kinsella:
> Hi Thomas,
>
> QQ - So is there really a 'no png' rule, because we have lots of them in the documentation?
Yes, really.
> root@rkinsell-MOBL2:.../rkinsell/dpdk# find doc/ -name "*.png" | wc -l
> 61
> root@rkinsell-MOBL2:.../rkinsell/dpdk# find doc/ -name "*.svg" | wc -l
> 116
That's because some of the initial PNGs were not converted.
> I am looking at recreating the images as SVG, but if it comes down to it - would they be ok to go as PNGs?
You already did it as SVG, thanks.
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH] ethdev: bump library version
2019-10-27 6:14 3% [dpdk-dev] [PATCH] ethdev: bump library version David Marchand
2019-10-27 9:02 3% ` Thomas Monjalon
@ 2019-10-28 8:26 0% ` Andrew Rybchenko
1 sibling, 0 replies; 200+ results
From: Andrew Rybchenko @ 2019-10-28 8:26 UTC (permalink / raw)
To: David Marchand, dev; +Cc: Thomas Monjalon, Ferruh Yigit
On 10/27/19 9:14 AM, David Marchand wrote:
> Let's stick to the current model of per library ABI version until the
> new model is in place.
>
> Fixes: 4f25d7d2252f ("ethdev: add return code to device info get function")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
Thanks.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [dpdk-announce] release candidate 19.11-rc1
@ 2019-10-27 23:34 3% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-10-27 23:34 UTC (permalink / raw)
To: announce
A new DPDK release candidate is ready for testing:
https://git.dpdk.org/dpdk/tag/?id=v19.11-rc1
There are 1045 patches accumulated in the master branch
since the last release. It is more than enough to have a new tag.
Note that this -rc1 is exceptionnally not feature-complete.
We are expecting more major features in the upcoming -rc2 (in 2 weeks).
The release notes so far:
http://doc.dpdk.org/guides/rel_notes/release_19_11.html
Please think about updating the release notes when you add a feature.
Highlights of 19.11-rc1, grouped by category:
General:
- prepare for 1 year without ABI breakage
- dynamic mbuf
- eBPF arm64 JIT
Networking:
- Hisilicon hns3 driver
- NXP PFE driver
- virtio packed ring optimizations
Cryptography:
- session-less asymmetric crypto
- Marvell Nitrox driver
- Marvell OCTEON TX2 crypto driver
- IPsec SAD API
Applications:
- IOAT example
- several examples are removed
We will close this release cycle before the end of November.
DPDK 19.11-rc2 is expected on 8th of November.
Thank you everyone
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3 00/12] EAL and PCI ABI changes for 19.11
2019-10-27 6:26 7% ` David Marchand
@ 2019-10-27 9:56 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-10-27 9:56 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Burakov, Anatoly, Thomas Monjalon, Kevin Traynor
On Sun, Oct 27, 2019 at 7:26 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Sat, Oct 26, 2019 at 9:18 PM David Marchand
> <david.marchand@redhat.com> wrote:
> >
> > On Fri, Oct 25, 2019 at 3:56 PM David Marchand
> > <david.marchand@redhat.com> wrote:
> > >
> > > Let's prepare for the ABI freeze.
> > >
> > > The first patches are about changes that had been announced before.
> > >
> > > The malloc_heap structure from the memory subsystem can be hidden.
> > > The PCI library had some forgotten deprecated APIs that are removed with
> > > this series.
> > >
> > > rte_logs could be hidden, but I left it exposed for now.
> > > I added an accessor to rte_logs.file, and added a deprecation notice
> > > announcing its removal from the public ABI.
> > >
> > > Changelog since v2:
> > > - dropped patch 8 and added a deprecation notice on rte_logs instead,
> > >
> > > Changelog since v1:
> > > - I went a step further, hiding rte_config after de-inlining non critical
> > > functions
> > >
> > >
> > > --
> > > David Marchand
> > >
> > > David Marchand (11):
> > > eal: remove deprecated CPU flags check function
> > > eal: remove deprecated malloc virt2phys function
> > > mem: hide internal heap header
> > > net/bonding: use non deprecated PCI API
> > > pci: remove deprecated functions
> > > log: add log stream accessor
> > > test/mem: remove dependency on EAL internals
> > > eal: deinline lcore APIs
> > > eal: factorize lcore role code
> > > eal: make the global configuration private
> > > doc: announce global logs struct removal from ABI
> > >
> > > Stephen Hemminger (1):
> > > eal: make lcore config private
> >
> > Thanks for the reviews/acks.
> > Series applied.
>
> I held back before pushing as I caught an issue on ethdev abiver.
> Since the ABI changes are not in place, we should still bump it and
> the same would apply on eal and pci libraries in this series.
Discussed with Thomas, updated the release notes and bumped the eal
and pci libraries.
And pushed to master.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3 1/2] eal: split compat header file
@ 2019-10-27 9:49 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-10-27 9:49 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, Andrzej Ostruszka, Neil Horman, bluca
07/10/2019 17:45, Bruce Richardson:
> The compat.h header file provided macros for two purposes:
> 1. it provided the macros for marking functions as rte_experimental
> 2. it provided the macros for doing function versioning
[...]
> lib/librte_eal/common/include/rte_compat.h | 70 ----------------
> .../common/include/rte_function_versioning.h | 79 +++++++++++++++++++
I take this opportunity to add (while merging) the files in MAINTAINERS,
in the section "ABI versioning" of Neil Horman,
so it is clear what are the pieces of ABI code.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] ethdev: bump library version
2019-10-27 9:02 3% ` Thomas Monjalon
@ 2019-10-27 9:43 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-10-27 9:43 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Ferruh Yigit, Andrew Rybchenko
On Sun, Oct 27, 2019 at 10:02 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 27/10/2019 07:14, David Marchand:
> > Let's stick to the current model of per library ABI version until the
> > new model is in place.
> >
> > Fixes: 4f25d7d2252f ("ethdev: add return code to device info get function")
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
>
> In order to make it more obvious, it would be nice to explain that
> the ABI has changed and it is reflected in the release notes
> but not in the compiled version number.
Ok, done.
>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
Applied, thanks.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: bump library version
2019-10-27 6:14 3% [dpdk-dev] [PATCH] ethdev: bump library version David Marchand
@ 2019-10-27 9:02 3% ` Thomas Monjalon
2019-10-27 9:43 0% ` David Marchand
2019-10-28 8:26 0% ` Andrew Rybchenko
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-10-27 9:02 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Ferruh Yigit, Andrew Rybchenko
27/10/2019 07:14, David Marchand:
> Let's stick to the current model of per library ABI version until the
> new model is in place.
>
> Fixes: 4f25d7d2252f ("ethdev: add return code to device info get function")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
In order to make it more obvious, it would be nice to explain that
the ABI has changed and it is reflected in the release notes
but not in the compiled version number.
Acked-by: Thomas Monjalon <thomas@monjalon.net>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC] ethdev: add new fields for max LRO session size
@ 2019-10-27 9:04 3% ` Matan Azrad
2019-10-29 12:25 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Matan Azrad @ 2019-10-27 9:04 UTC (permalink / raw)
To: Andrew Rybchenko, Ferruh Yigit, Thomas Monjalon
Cc: dev, Konstantin Ananyev, Olivier Matz
Hi All
From: Andrew Rybchenko
> On 10/18/19 7:35 PM, Ferruh Yigit wrote:
> > On 10/2/2019 2:58 PM, Thomas Monjalon wrote:
> >> 24/09/2019 14:03, Matan Azrad:
> >>> From: Ferruh Yigit
> >>>> On 9/15/2019 8:48 AM, Matan Azrad wrote:
> >>>>> Hi Ferruh
> >>>>>
> >>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
> >>>>>> On 8/29/2019 8:47 AM, Matan Azrad wrote:
> >>>>>>> It may be needed by the user to limit the LRO session packet size.
> >>>>>>> In order to allow the above limitation, add new Rx configuration
> >>>>>>> for the maximum LRO session size.
> >>>>>>>
> >>>>>>> In addition, Add a new capability to expose the maximum LRO
> >>>>>>> session size supported by the port.
> >>>>>>>
> >>>>>>> Signed-off-by: Matan Azrad <matan@mellanox.com>
> >>>>>> Hi Matan,
> >>>>>>
> >>>>>> Is there any existing user of this new field?
> >>>>> All the LRO users need it due to the next reasons:
> >>>>>
> >>>>> 1. If scatter is enabled - The dpdk user can limit the LRO session
> >>>>> size created
> >>>> by the HW by this field, if no field like that - there is no way to limit it.
> >>>>> 2. No scatter - the dpdk user may want to limit the LRO packet
> >>>>> size in order
> >>>> to save enough tail-room in the mbuf for its own usage.
> >>>>> 3. The limitation of max_rx_pkt_len is not enough - doesn't make
> >>>>> sense to
> >>>> limit LRO traffic as single packet.
> >>>> So should there be more complement patches to this RFC? To update
> >>>> the users of the field with the new field.
> >>>
> >>> We already exposed it as ABI breakage in the last deprecation notice.
> >>> We probably cannot complete it for 19.11 version, hopefully for 20.02 it
> will be completed.
> >> We won't break the ABI in 20.02.
> >> What should be done in 19.11?
> >>
> > The ask was to add code that uses new added fields, this patch only
> > adds new field to two public ethdev struct.
> >
> > @Thomas, @Andrew, if this patch doesn't goes it on this release it
> > will have to wait a year. I would like to see the implementation but
> > it is not there, what is your comment?
>
> I don't mind to accept it in 19.11 modulo better description of what is LRO
> session length/size.
Thanks,
We can create the patch for ethdev for 19.11-RC2.
Also PMD implementation to use it for RC2.
Is it OK? (We need to break ABI as described in the deprecation notice)
Matan
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3 00/12] EAL and PCI ABI changes for 19.11
2019-10-26 19:18 4% ` [dpdk-dev] [PATCH v3 00/12] EAL and PCI ABI changes for 19.11 David Marchand
@ 2019-10-27 6:26 7% ` David Marchand
2019-10-27 9:56 4% ` David Marchand
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-10-27 6:26 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Burakov, Anatoly, Thomas Monjalon, Kevin Traynor
On Sat, Oct 26, 2019 at 9:18 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Fri, Oct 25, 2019 at 3:56 PM David Marchand
> <david.marchand@redhat.com> wrote:
> >
> > Let's prepare for the ABI freeze.
> >
> > The first patches are about changes that had been announced before.
> >
> > The malloc_heap structure from the memory subsystem can be hidden.
> > The PCI library had some forgotten deprecated APIs that are removed with
> > this series.
> >
> > rte_logs could be hidden, but I left it exposed for now.
> > I added an accessor to rte_logs.file, and added a deprecation notice
> > announcing its removal from the public ABI.
> >
> > Changelog since v2:
> > - dropped patch 8 and added a deprecation notice on rte_logs instead,
> >
> > Changelog since v1:
> > - I went a step further, hiding rte_config after de-inlining non critical
> > functions
> >
> >
> > --
> > David Marchand
> >
> > David Marchand (11):
> > eal: remove deprecated CPU flags check function
> > eal: remove deprecated malloc virt2phys function
> > mem: hide internal heap header
> > net/bonding: use non deprecated PCI API
> > pci: remove deprecated functions
> > log: add log stream accessor
> > test/mem: remove dependency on EAL internals
> > eal: deinline lcore APIs
> > eal: factorize lcore role code
> > eal: make the global configuration private
> > doc: announce global logs struct removal from ABI
> >
> > Stephen Hemminger (1):
> > eal: make lcore config private
>
> Thanks for the reviews/acks.
> Series applied.
I held back before pushing as I caught an issue on ethdev abiver.
Since the ABI changes are not in place, we should still bump it and
the same would apply on eal and pci libraries in this series.
Waiting a bit if anyone is looking at this, else I will go with this for rc1.
Thanks.
--
David Marchand
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [PATCH] ethdev: bump library version
@ 2019-10-27 6:14 3% David Marchand
2019-10-27 9:02 3% ` Thomas Monjalon
2019-10-28 8:26 0% ` Andrew Rybchenko
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2019-10-27 6:14 UTC (permalink / raw)
To: dev; +Cc: Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko
Let's stick to the current model of per library ABI version until the
new model is in place.
Fixes: 4f25d7d2252f ("ethdev: add return code to device info get function")
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
lib/librte_ethdev/Makefile | 2 +-
lib/librte_ethdev/meson.build | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile
index 60bcc22..0efcdfa 100644
--- a/lib/librte_ethdev/Makefile
+++ b/lib/librte_ethdev/Makefile
@@ -16,7 +16,7 @@ LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_meter
EXPORT_MAP := rte_ethdev_version.map
-LIBABIVER := 12
+LIBABIVER := 13
SRCS-y += ethdev_private.c
SRCS-y += rte_ethdev.c
diff --git a/lib/librte_ethdev/meson.build b/lib/librte_ethdev/meson.build
index f75d428..c22cf81 100644
--- a/lib/librte_ethdev/meson.build
+++ b/lib/librte_ethdev/meson.build
@@ -2,7 +2,7 @@
# Copyright(c) 2017 Intel Corporation
name = 'ethdev'
-version = 12
+version = 13
allow_experimental_apis = true
sources = files('ethdev_private.c',
'ethdev_profile.c',
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3 00/12] EAL and PCI ABI changes for 19.11
@ 2019-10-26 19:18 4% ` David Marchand
2019-10-27 6:26 7% ` David Marchand
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2019-10-26 19:18 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Burakov, Anatoly, Thomas Monjalon, Kevin Traynor
On Fri, Oct 25, 2019 at 3:56 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> Let's prepare for the ABI freeze.
>
> The first patches are about changes that had been announced before.
>
> The malloc_heap structure from the memory subsystem can be hidden.
> The PCI library had some forgotten deprecated APIs that are removed with
> this series.
>
> rte_logs could be hidden, but I left it exposed for now.
> I added an accessor to rte_logs.file, and added a deprecation notice
> announcing its removal from the public ABI.
>
> Changelog since v2:
> - dropped patch 8 and added a deprecation notice on rte_logs instead,
>
> Changelog since v1:
> - I went a step further, hiding rte_config after de-inlining non critical
> functions
>
>
> --
> David Marchand
>
> David Marchand (11):
> eal: remove deprecated CPU flags check function
> eal: remove deprecated malloc virt2phys function
> mem: hide internal heap header
> net/bonding: use non deprecated PCI API
> pci: remove deprecated functions
> log: add log stream accessor
> test/mem: remove dependency on EAL internals
> eal: deinline lcore APIs
> eal: factorize lcore role code
> eal: make the global configuration private
> doc: announce global logs struct removal from ABI
>
> Stephen Hemminger (1):
> eal: make lcore config private
Thanks for the reviews/acks.
Series applied.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3 12/12] doc: announce global logs struct removal from ABI
@ 2019-10-26 18:48 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-10-26 18:48 UTC (permalink / raw)
To: Kevin Traynor
Cc: dev, Stephen Hemminger, Burakov, Anatoly, Thomas Monjalon,
Neil Horman, John McNamara, Marko Kovacevic
On Sat, Oct 26, 2019 at 8:14 PM Kevin Traynor <ktraynor@redhat.com> wrote:
>
> On 25/10/2019 14:56, David Marchand wrote:
> > New accessor has been introduced to provide the hidden information.
> > This symbol can now be kept internal.
> > > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
> > doc/guides/rel_notes/deprecation.rst | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> > index cf7744e..3aa1634 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -34,6 +34,10 @@ Deprecation Notices
> >
> > + ``rte_eal_devargs_type_count``
> >
> > +* eal: The ``rte_logs`` struct and global symbol will be made private to
> > + remove it from the externally visible ABI and allow it to be updated in the
> > + future.
> > +
> > * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
> > have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
> > functions. The due date for the removal targets DPDK 20.02.
> >
>
> Acked-by: Kevin Traynor <ktraynor@redhat.com>
Thanks Kevin for catching that contrail vrouter relies on rte_logs.
Something to study by 20.11.
--
David Marchand
^ permalink raw reply [relevance 4%]
Results 7201-7400 of ~18000 next (older) | prev (newer) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2019-07-24 8:20 [dpdk-dev] [PATCH v4 0/1] fbarray: get fbarrays from containerized secondary yasufum.o
2019-11-01 9:04 ` [dpdk-dev] [PATCH v6 0/1] fbarray: fix duplicated fbarray file in secondary yasufum.o
2019-11-01 9:04 ` [dpdk-dev] [PATCH v6 1/1] " yasufum.o
2019-11-04 10:20 ` Burakov, Anatoly
2019-11-05 10:13 3% ` David Marchand
2019-11-05 11:31 0% ` Burakov, Anatoly
2019-11-05 11:41 0% ` Ananyev, Konstantin
2019-11-06 10:37 0% ` Burakov, Anatoly
2019-11-08 3:19 3% ` Yasufumi Ogawa
2019-08-11 16:06 [dpdk-dev] [PATCH v3 0/2] failsafe: add xstats Stephen Hemminger
2019-09-19 13:17 ` [dpdk-dev] [PATCH v5 " Stephen Hemminger
2019-09-19 13:17 ` [dpdk-dev] [PATCH v5 1/2] ethdev: expose basic xstats for driver use Stephen Hemminger
2019-09-26 12:46 ` Andrew Rybchenko
2019-10-31 16:40 0% ` Stephen Hemminger
2019-08-15 15:06 [dpdk-dev] [RFC] ethdev: configure SR-IOV VF from host Thomas Monjalon
2019-10-29 18:50 3% ` [dpdk-dev] [PATCH v2 0/3] " Thomas Monjalon
2019-10-30 4:08 0% ` Jerin Jacob
2019-10-30 7:22 0% ` Shahaf Shuler
2019-10-30 15:07 0% ` Ilya Maximets
2019-08-29 7:47 [dpdk-dev] [RFC] ethdev: add new fields for max LRO session size Matan Azrad
2019-09-16 15:37 ` Ferruh Yigit
2019-09-24 12:03 ` Matan Azrad
2019-10-02 13:58 ` Thomas Monjalon
2019-10-18 16:35 ` Ferruh Yigit
2019-10-22 12:56 ` Andrew Rybchenko
2019-10-27 9:04 3% ` Matan Azrad
2019-10-29 12:25 0% ` Ferruh Yigit
2019-09-11 17:09 [dpdk-dev] [PATCH v5 00/12] lib: add RIB and FIB liraries Vladimir Medvedkin
2019-11-01 15:21 2% ` [dpdk-dev] [PATCH v6 " Vladimir Medvedkin
2019-09-26 6:28 [dpdk-dev] [PATCH 00/13] add hairpin feature Ori Kam
2019-10-30 23:53 ` [dpdk-dev] [PATCH v7 00/14] " Ori Kam
2019-10-30 23:53 ` [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue Ori Kam
2019-11-05 11:24 ` Ferruh Yigit
2019-11-05 11:36 ` Ori Kam
2019-11-05 11:49 3% ` Andrew Rybchenko
2019-11-05 12:00 0% ` Ori Kam
2019-11-05 12:05 0% ` Ferruh Yigit
2019-11-05 12:12 0% ` Andrew Rybchenko
2019-11-05 12:23 0% ` Ferruh Yigit
2019-11-05 12:27 0% ` Andrew Rybchenko
2019-11-05 12:51 0% ` Thomas Monjalon
2019-11-05 12:53 0% ` Andrew Rybchenko
2019-11-05 13:02 0% ` Thomas Monjalon
2019-11-05 13:23 3% ` Ori Kam
2019-11-05 13:27 0% ` Thomas Monjalon
2019-11-05 13:34 0% ` Andrew Rybchenko
2019-11-05 13:41 0% ` Andrew Rybchenko
2019-09-27 16:54 [dpdk-dev] [PATCH v6 0/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-10-24 0:43 ` [dpdk-dev] [PATCH v6 2/4] " Thomas Monjalon
2019-10-25 9:10 ` Ray Kinsella
2019-10-28 10:02 5% ` Thomas Monjalon
2019-09-27 19:49 [dpdk-dev] [PATCH 0/2] Improve function versioning meson support Bruce Richardson
2019-10-07 15:45 ` [dpdk-dev] [PATCH v3 " Bruce Richardson
2019-10-07 15:45 ` [dpdk-dev] [PATCH v3 1/2] eal: split compat header file Bruce Richardson
2019-10-27 9:49 4% ` Thomas Monjalon
2019-10-15 5:30 [dpdk-dev] [PATCH] eal: add option --iso-cmem for external custom memory Ajit Khaparde
2019-10-17 15:45 ` Burakov, Anatoly
2019-10-18 10:54 ` Rajesh Ravi
2019-10-18 16:53 ` Burakov, Anatoly
2019-10-21 15:46 ` Rajesh Ravi
2019-10-22 7:56 ` Rajesh Ravi
2019-10-24 11:43 ` Burakov, Anatoly
2019-10-25 12:53 ` Rajesh Ravi
2019-10-25 15:02 ` Burakov, Anatoly
2019-10-30 19:50 ` Rajesh Ravi
2019-11-04 10:25 ` Burakov, Anatoly
2019-11-05 11:41 4% ` Burakov, Anatoly
2019-11-05 14:10 0% ` Rajesh Ravi
2019-10-15 7:51 [dpdk-dev] [PATCH v4 0/4] get Rx/Tx packet burst mode information Haiyue Wang
2019-10-25 15:45 ` [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting " Thomas Monjalon
2019-10-25 16:02 ` Jerin Jacob
2019-10-25 22:27 ` Thomas Monjalon
2019-10-26 6:58 ` Jerin Jacob
2019-10-26 9:37 ` Wang, Haiyue
2019-10-29 3:37 ` Jerin Jacob
2019-10-29 4:44 ` Wang, Haiyue
2019-10-29 5:19 ` Jerin Jacob
2019-10-29 5:42 ` Wang, Haiyue
2019-10-29 5:47 ` Jerin Jacob
2019-10-29 6:00 ` Wang, Haiyue
2019-10-29 8:34 ` Jerin Jacob
2019-10-29 11:26 ` Wang, Haiyue
2019-10-29 12:56 ` Jerin Jacob
2019-10-29 13:51 ` Wang, Haiyue
2019-10-29 14:08 ` Jerin Jacob
2019-10-29 15:42 ` Wang, Haiyue
2019-10-29 15:59 3% ` Jerin Jacob
2019-10-29 16:16 0% ` Wang, Haiyue
2019-10-29 16:59 ` Ferruh Yigit
2019-10-30 8:14 ` Wang, Haiyue
2019-10-31 10:46 ` Jerin Jacob
2019-10-31 11:16 ` Wang, Haiyue
2019-10-31 14:58 3% ` Ferruh Yigit
2019-10-31 15:07 0% ` Wang, Haiyue
2019-10-31 15:29 0% ` Ferruh Yigit
2019-10-31 15:54 0% ` Wang, Haiyue
2019-11-04 11:30 ` Thomas Monjalon
2019-11-04 12:07 ` Ray Kinsella
2019-11-04 13:09 3% ` Thomas Monjalon
2019-11-04 13:48 4% ` Ray Kinsella
2019-11-04 14:17 0% ` Wang, Haiyue
2019-10-17 14:31 [dpdk-dev] [PATCH v4 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
2019-10-24 9:46 ` [dpdk-dev] [PATCH v5 " Anatoly Burakov
2019-10-24 9:46 ` [dpdk-dev] [PATCH v5 01/10] config: change ABI versioning to global Anatoly Burakov
2019-11-05 11:05 4% ` David Marchand
2019-11-05 13:50 4% ` Bruce Richardson
2019-10-24 9:46 ` [dpdk-dev] [PATCH v5 02/10] buildtools: add script for updating symbols abi version Anatoly Burakov
2019-11-06 15:38 8% ` David Marchand
2019-11-06 16:54 8% ` [dpdk-dev] [PATCH v6 00/10] Implement the new ABI policy and add helper scripts Anatoly Burakov
2019-11-08 16:25 8% ` [dpdk-dev] [PATCH v7 " Anatoly Burakov
2019-11-08 16:25 7% ` [dpdk-dev] [PATCH v7 01/10] config: change ABI versioning to global Anatoly Burakov
2019-11-08 16:25 15% ` [dpdk-dev] [PATCH v7 02/10] buildtools: add script for updating symbols abi version Anatoly Burakov
2019-11-08 16:25 23% ` [dpdk-dev] [PATCH v7 03/10] buildtools: add ABI update shell script Anatoly Burakov
2019-11-08 16:25 4% ` [dpdk-dev] [PATCH v7 04/10] timer: remove deprecated code Anatoly Burakov
2019-11-08 16:25 2% ` [dpdk-dev] [PATCH v7 05/10] lpm: " Anatoly Burakov
2019-11-08 16:25 4% ` [dpdk-dev] [PATCH v7 06/10] distributor: " Anatoly Burakov
2019-11-08 16:25 6% ` [dpdk-dev] [PATCH v7 07/10] distributor: rename v2.0 ABI to _single suffix Anatoly Burakov
2019-11-08 16:25 3% ` [dpdk-dev] [PATCH v7 08/10] drivers/octeontx: add missing public symbol Anatoly Burakov
2019-11-08 16:25 2% ` [dpdk-dev] [PATCH v7 09/10] build: change ABI version to 20.0 Anatoly Burakov
2019-11-08 16:25 23% ` [dpdk-dev] [PATCH v7 10/10] buildtools: add ABI versioning check script Anatoly Burakov
2019-11-06 16:54 7% ` [dpdk-dev] [PATCH v6 01/10] config: change ABI versioning to global Anatoly Burakov
2019-11-06 16:54 15% ` [dpdk-dev] [PATCH v6 02/10] buildtools: add script for updating symbols abi version Anatoly Burakov
2019-11-06 16:54 23% ` [dpdk-dev] [PATCH v6 03/10] buildtools: add ABI update shell script Anatoly Burakov
2019-11-06 16:54 4% ` [dpdk-dev] [PATCH v6 04/10] timer: remove deprecated code Anatoly Burakov
2019-11-06 16:54 2% ` [dpdk-dev] [PATCH v6 05/10] lpm: " Anatoly Burakov
2019-11-06 16:54 4% ` [dpdk-dev] [PATCH v6 06/10] distributor: " Anatoly Burakov
2019-11-06 16:54 6% ` [dpdk-dev] [PATCH v6 07/10] distributor: rename v2.0 ABI to _single suffix Anatoly Burakov
2019-11-06 16:54 3% ` [dpdk-dev] [PATCH v6 08/10] drivers/octeontx: add missing public symbol Anatoly Burakov
2019-11-06 16:54 2% ` [dpdk-dev] [PATCH v6 09/10] build: change ABI version to 20.0 Anatoly Burakov
2019-11-06 16:54 23% ` [dpdk-dev] [PATCH v6 10/10] buildtools: add ABI versioning check script Anatoly Burakov
2019-10-22 9:32 [dpdk-dev] [PATCH 0/8] EAL and PCI ABI changes for 19.11 David Marchand
2019-10-25 13:55 ` [dpdk-dev] [PATCH v3 00/12] " David Marchand
2019-10-25 13:56 ` [dpdk-dev] [PATCH v3 12/12] doc: announce global logs struct removal from ABI David Marchand
2019-10-26 18:14 ` Kevin Traynor
2019-10-26 18:48 4% ` David Marchand
2019-10-26 19:18 4% ` [dpdk-dev] [PATCH v3 00/12] EAL and PCI ABI changes for 19.11 David Marchand
2019-10-27 6:26 7% ` David Marchand
2019-10-27 9:56 4% ` David Marchand
2019-10-22 11:54 [dpdk-dev] [PATCH v4 00/10] Add an option to use LTO for DPDK build Andrzej Ostruszka
2019-10-28 14:21 ` [dpdk-dev] [PATCH v5 00/11] " Andrzej Ostruszka
2019-10-28 14:21 2% ` [dpdk-dev] [PATCH v5 01/11] build: annotate versioned symbols with __vsym macro Andrzej Ostruszka
2019-10-29 10:49 0% ` Neil Horman
2019-10-29 14:12 ` [dpdk-dev] [PATCH v6 00/12] Add an option to use LTO for DPDK build Andrzej Ostruszka
2019-10-29 14:12 2% ` [dpdk-dev] [PATCH v6 02/12] build: annotate versioned symbols with __vsym macro Andrzej Ostruszka
2019-11-07 15:03 ` [dpdk-dev] [PATCH v7 00/12] Add an option to use LTO for DPDK build Andrzej Ostruszka
2019-11-07 15:03 3% ` [dpdk-dev] [PATCH v7 01/12] doc: fix description of versioning macros Andrzej Ostruszka
2019-11-07 15:03 2% ` [dpdk-dev] [PATCH v7 02/12] build: annotate versioned symbols with __vsym macro Andrzej Ostruszka
2019-10-22 17:44 [dpdk-dev] [RFC PATCH 1/9] security: introduce CPU Crypto action type and API Ananyev, Konstantin
2019-10-23 10:05 ` Akhil Goyal
2019-10-30 14:23 0% ` Ananyev, Konstantin
2019-11-01 13:53 0% ` Akhil Goyal
2019-10-24 13:08 [dpdk-dev] [PATCH v3] ethdev: extend flow metadata Viacheslav Ovsiienko
2019-10-27 18:40 ` [dpdk-dev] [PATCH v4] " Viacheslav Ovsiienko
2019-10-29 16:22 3% ` Andrew Rybchenko
2019-10-29 17:19 2% ` Slava Ovsiienko
2019-10-29 18:30 0% ` Thomas Monjalon
2019-10-29 18:35 0% ` Slava Ovsiienko
2019-10-30 6:28 0% ` Andrew Rybchenko
2019-10-30 7:35 3% ` Andrew Rybchenko
2019-10-30 8:59 0% ` Slava Ovsiienko
2019-10-30 9:20 0% ` Andrew Rybchenko
2019-10-30 10:05 0% ` Slava Ovsiienko
2019-10-30 10:03 0% ` Slava Ovsiienko
2019-10-25 6:20 [dpdk-dev] [PATCH 1/2] security: add anti replay window size Hemant Agrawal
2019-10-30 6:57 ` [dpdk-dev] [PATCH v2 " Hemant Agrawal
2019-10-30 6:57 5% ` [dpdk-dev] [PATCH v2 2/2] ipsec: remove redundant replay_win_sz Hemant Agrawal
2019-10-30 8:57 ` [dpdk-dev] [PATCH v3 1/2] security: add anti replay window size Hemant Agrawal
2019-10-30 8:57 5% ` [dpdk-dev] [PATCH v3 2/2] ipsec: remove redundant replay_win_sz Hemant Agrawal
2019-10-30 13:08 0% ` Ananyev, Konstantin
2019-10-31 4:54 5% ` [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size Hemant Agrawal
2019-10-31 4:54 5% ` [dpdk-dev] [PATCH v4 2/3] ipsec: remove redundant replay_win_sz Hemant Agrawal
2019-10-31 6:29 0% ` [dpdk-dev] [PATCH v4 1/3] security: add anti replay window size Anoob Joseph
2019-10-31 7:30 0% ` Hemant Agrawal
2019-10-31 10:20 0% ` Ananyev, Konstantin
2019-10-31 13:15 5% ` [dpdk-dev] [PATCH v5 " Hemant Agrawal
2019-10-31 13:15 5% ` [dpdk-dev] [PATCH v5 2/3] ipsec: remove redundant replay_win_sz Hemant Agrawal
2019-11-05 22:01 0% ` Akhil Goyal
2019-11-06 5:16 0% ` Hemant Agrawal
2019-11-01 6:16 0% ` [dpdk-dev] [EXT] [PATCH v5 1/3] security: add anti replay window size Anoob Joseph
2019-11-06 6:54 5% ` [dpdk-dev] [PATCH v6 " Hemant Agrawal
2019-11-06 6:54 4% ` [dpdk-dev] [PATCH v6 2/3] ipsec: remove redundant replay_win_sz Hemant Agrawal
2019-11-06 7:00 0% ` Akhil Goyal
2019-11-06 13:31 0% ` Ananyev, Konstantin
2019-11-06 13:40 0% ` Akhil Goyal
2019-11-06 14:27 0% ` Ananyev, Konstantin
2019-11-06 14:29 0% ` Akhil Goyal
2019-10-25 16:28 [dpdk-dev] [PATCH v7 0/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-10-25 16:28 ` [dpdk-dev] [PATCH v7 1/4] doc: separate versioning.rst into version and policy Ray Kinsella
2019-10-31 15:02 0% ` Mcnamara, John
2019-11-05 15:11 0% ` Ray Kinsella
2019-10-25 16:28 ` [dpdk-dev] [PATCH v7 2/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-10-31 15:06 9% ` Mcnamara, John
2019-11-05 15:11 5% ` Ray Kinsella
2019-10-25 16:28 ` [dpdk-dev] [PATCH v7 3/4] doc: updates to versioning guide for " Ray Kinsella
2019-10-31 15:07 4% ` Mcnamara, John
2019-10-25 16:28 ` [dpdk-dev] [PATCH v7 4/4] doc: add maintainer for abi policy Ray Kinsella
2019-10-31 15:07 4% ` Mcnamara, John
2019-10-27 6:14 3% [dpdk-dev] [PATCH] ethdev: bump library version David Marchand
2019-10-27 9:02 3% ` Thomas Monjalon
2019-10-27 9:43 0% ` David Marchand
2019-10-28 8:26 0% ` Andrew Rybchenko
2019-10-27 23:34 3% [dpdk-dev] [dpdk-announce] release candidate 19.11-rc1 Thomas Monjalon
2019-10-28 10:49 4% [dpdk-dev] [PATCH] ethdev: remove deprecated port count function Thomas Monjalon
2019-10-28 11:05 0% ` David Marchand
2019-10-28 11:38 0% ` Andrew Rybchenko
2019-10-29 8:43 0% ` Jerin Jacob
2019-10-28 13:03 0% ` Neil Horman
2019-10-31 18:52 0% ` Ferruh Yigit
2019-10-31 17:11 [dpdk-dev] [PATCH v1 1/3] net/ice: remove the specific burst mode bit set Haiyue Wang
2019-10-31 17:11 ` [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information Haiyue Wang
2019-11-01 22:46 ` Thomas Monjalon
2019-11-02 5:29 ` Wang, Haiyue
2019-11-02 6:55 4% ` Liu, Yu Y
2019-11-02 8:38 0% ` Slava Ovsiienko
2019-11-02 19:21 0% ` Damjan Marion (damarion)
2019-11-03 7:50 0% ` Slava Ovsiienko
2019-11-05 15:12 0% ` Ferruh Yigit
2019-11-05 15:54 0% ` Stephen Hemminger
2019-11-03 20:46 0% ` Ray Kinsella
2019-11-03 2:34 0% ` Wang, Haiyue
2019-11-03 3:03 0% ` Wang, Haiyue
2019-11-03 8:59 0% ` Slava Ovsiienko
2019-11-03 11:38 3% ` Wang, Haiyue
2019-11-03 19:31 0% ` Slava Ovsiienko
2019-11-04 1:01 0% ` Wang, Haiyue
2019-11-02 18:31 0% ` Thomas Monjalon
2019-10-31 18:43 4% [dpdk-dev] DPDK Release Status Meeting 31/10/2019 Ferruh Yigit
2019-11-01 13:36 3% [dpdk-dev] [PATCH v5 0/5] Some fixes for hinic PMD driver Xiaoyun wang
2019-11-07 9:29 0% ` Ferruh Yigit
2019-11-05 8:40 [dpdk-dev] [PATCH 0/3] support API to set max LRO packet size Dekel Peled
2019-11-05 8:40 3% ` [dpdk-dev] [PATCH 1/3] ethdev: " Dekel Peled
2019-11-06 11:34 ` [dpdk-dev] [PATCH v2 0/3] " Dekel Peled
2019-11-06 11:34 3% ` [dpdk-dev] [PATCH v2 1/3] ethdev: " Dekel Peled
2019-11-06 14:28 ` [dpdk-dev] [PATCH v3 0/3] " Dekel Peled
2019-11-06 14:28 3% ` [dpdk-dev] [PATCH v3 1/3] ethdev: " Dekel Peled
2019-11-07 12:35 ` [dpdk-dev] [PATCH v4 0/3] " Dekel Peled
2019-11-07 12:35 3% ` [dpdk-dev] [PATCH v4 1/3] ethdev: " Dekel Peled
2019-11-07 20:15 ` Ferruh Yigit
2019-11-08 6:54 ` Matan Azrad
2019-11-08 9:19 3% ` Ferruh Yigit
2019-11-08 10:10 0% ` Matan Azrad
2019-11-08 11:37 0% ` Ferruh Yigit
2019-11-08 11:56 0% ` Matan Azrad
2019-11-08 12:51 0% ` Ferruh Yigit
2019-11-08 16:11 0% ` Dekel Peled
2019-11-08 16:53 0% ` Ferruh Yigit
2019-11-08 13:11 0% ` Ananyev, Konstantin
2019-11-08 14:10 0% ` Dekel Peled
2019-11-08 14:52 0% ` Ananyev, Konstantin
2019-11-08 16:08 0% ` Dekel Peled
2019-11-08 16:28 0% ` Ananyev, Konstantin
2019-11-08 16:42 ` [dpdk-dev] [PATCH v5 0/3] " Dekel Peled
2019-11-08 16:42 4% ` [dpdk-dev] [PATCH v5 1/3] ethdev: " Dekel Peled
2019-11-08 23:07 4% ` [dpdk-dev] [PATCH v6] ethdev: add " Thomas Monjalon
2019-11-05 15:15 2% [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps Anatoly Burakov
2019-11-05 17:15 0% ` Burakov, Anatoly
2019-11-06 13:58 3% ` David Marchand
2019-11-06 15:27 0% ` Rajesh Ravi
2019-11-06 21:53 0% ` David Marchand
2019-11-06 22:12 0% ` Thomas Monjalon
2019-11-07 6:35 0% ` Rajesh Ravi
2019-11-07 15:35 0% ` David Marchand
2019-11-05 15:24 10% [dpdk-dev] [PATCH v8 0/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-11-05 15:24 18% ` [dpdk-dev] [PATCH v8 1/4] doc: separate versioning.rst into version and policy Ray Kinsella
2019-11-05 17:37 0% ` Stephen Hemminger
2019-11-06 16:11 0% ` Mcnamara, John
2019-11-05 15:24 23% ` [dpdk-dev] [PATCH v8 2/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-11-05 17:37 5% ` Stephen Hemminger
2019-11-06 0:11 11% ` Thomas Monjalon
2019-11-06 8:49 11% ` Ray Kinsella
2019-11-06 9:06 10% ` Thomas Monjalon
2019-11-06 9:21 5% ` David Marchand
2019-11-06 9:22 9% ` Ray Kinsella
2019-11-06 21:07 10% ` Thomas Monjalon
2019-11-08 14:09 5% ` Ray Kinsella
2019-11-06 16:12 5% ` Mcnamara, John
2019-11-05 15:24 35% ` [dpdk-dev] [PATCH v8 3/4] doc: updates to versioning guide for " Ray Kinsella
2019-11-05 17:37 4% ` Stephen Hemminger
2019-11-06 16:13 4% ` Mcnamara, John
2019-11-05 15:24 13% ` [dpdk-dev] [PATCH v8 4/4] doc: add maintainer for abi policy Ray Kinsella
2019-11-06 16:13 4% ` Mcnamara, John
2019-11-07 15:01 4% [dpdk-dev] DPDK Release Status Meeting 7/11/2019 Ferruh Yigit
2019-11-07 22:15 4% [dpdk-dev] [PATCH] ethdev: reserve space in main structs for extension Thomas Monjalon
2019-11-08 3:41 0% ` Stephen Hemminger
2019-11-08 9:40 0% ` Thomas Monjalon
2019-11-08 9:57 0% ` Ferruh Yigit
2019-11-08 10:52 0% ` Andrew Rybchenko
2019-11-08 12:46 10% [dpdk-dev] [PATCH v9 0/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-11-08 12:46 18% ` [dpdk-dev] [PATCH v9 1/4] doc: separate versioning.rst into version and policy Ray Kinsella
2019-11-08 12:46 23% ` [dpdk-dev] [PATCH v9 2/4] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-11-08 17:11 5% ` Thomas Monjalon
2019-11-08 17:12 5% ` Ray Kinsella
2019-11-08 17:38 5% ` Thomas Monjalon
2019-11-08 12:46 35% ` [dpdk-dev] [PATCH v9 3/4] doc: updates to versioning guide for " Ray Kinsella
2019-11-08 12:46 13% ` [dpdk-dev] [PATCH v9 4/4] doc: add maintainer for abi policy Ray Kinsella
2019-11-08 17:18 4% ` Thomas Monjalon
2019-11-08 16:56 4% [dpdk-dev] [PATCH] eventdev: reserve space in main structs for extension jerinj
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).