Re: [dpdk-dev] [PATCH] net/ice: refine RSS configure
Hi Qi,
Replies inline.
> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, March 25, 2021 8:43 PM
> To: Guo, Jia ; Ding, Xuan
> Cc: dev@dpdk.org; Yang, Qiming ; Noonan, Gordon
> ; Varshney, Shashank1
> ; Zhang, Qi Z
> Subject: [PATCH] net/ice: refine RSS configure
>
> The ICE_RSS_ANY_HEADERS will try to enable outer RSS for
> non-tunnel case and inner RSS for tunnel case. This confuse
> user.
>
> As we already have ICE_RSS_INNER_HEADER for tunnel case,
> So, replace ICE_RSS_ANY_HEADERS with ICE_RSS_OUTER_HEADERS
> for all exist flow which only specified the outer pattern.
>
> To enable inner RSS for any tunnel cases, a separated rule
> should be enabled.
>
> The patch also remove some unncessary condition check for GTPU
Here ' unncessary ' is a typo, should be 'unnecessary'.
> in base code, as we already can support outer RSS for GTPU.
>
> Signed-off-by: Qi Zhang
> ---
> drivers/net/ice/base/ice_flow.c | 14
> drivers/net/ice/ice_ethdev.c| 4 ++--
> drivers/net/ice/ice_hash.c | 38 -
> 3 files changed, 21 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/net/ice/base/ice_flow.c b/drivers/net/ice/base/ice_flow.c
> index d123206fc6..bceb257d61 100644
> --- a/drivers/net/ice/base/ice_flow.c
> +++ b/drivers/net/ice/base/ice_flow.c
> @@ -3678,13 +3678,6 @@ ice_add_rss_cfg_sync(struct ice_hw *hw, u16
> vsi_handle,
> if (status)
> goto exit;
>
> - /* Don't do RSS for GTPU Outer */
> - if (segs_cnt == ICE_FLOW_SEG_SINGLE &&
> - segs[segs_cnt - 1].hdrs & ICE_FLOW_SEG_HDR_GTPU) {
> - status = ICE_SUCCESS;
> - goto exit;
> - }
> -
> /* Search for a flow profile that has matching headers, hash fields
>* and has the input VSI associated to it. If found, no further
>* operations required and exit.
> @@ -3847,13 +3840,6 @@ ice_rem_rss_cfg_sync(struct ice_hw *hw, u16
> vsi_handle,
> if (status)
> goto out;
>
> - /* Don't do RSS for GTPU Outer */
> - if (segs_cnt == ICE_FLOW_SEG_SINGLE &&
> - segs[segs_cnt - 1].hdrs & ICE_FLOW_SEG_HDR_GTPU) {
> - status = ICE_SUCCESS;
> - goto out;
> - }
> -
> prof = ice_flow_find_prof_conds(hw, blk, ICE_FLOW_RX, segs, segs_cnt,
> vsi_handle,
> ICE_FLOW_FIND_PROF_CHK_FLDS);
> diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
> index 3e85e5f629..4ccf31cb41 100644
> --- a/drivers/net/ice/ice_ethdev.c
> +++ b/drivers/net/ice/ice_ethdev.c
> @@ -2348,7 +2348,7 @@ hash_cfg_reset(struct ice_rss_hash_cfg *cfg)
> cfg->hash_flds = 0;
> cfg->addl_hdrs = 0;
> cfg->symm = 0;
> - cfg->hdr_type = ICE_RSS_ANY_HEADERS;
> + cfg->hdr_type = ICE_RSS_OUTER_HEADERS;
> }
>
> static int
> @@ -2833,7 +2833,7 @@ ice_rss_hash_set(struct ice_pf *pf, uint64_t rss_hf)
> __func__, ret);
>
> cfg.symm = 0;
> - cfg.hdr_type = ICE_RSS_ANY_HEADERS;
> + cfg.hdr_type = ICE_RSS_OUTER_HEADERS;
> /* Configure RSS for IPv4 with src/dst addr as input set */
> if (rss_hf & ETH_RSS_IPV4) {
> cfg.addl_hdrs = ICE_FLOW_SEG_HDR_IPV4 |
> ICE_FLOW_SEG_HDR_IPV_OTHER;
> diff --git a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c
> index 58a0c18d09..7d7e7052da 100644
> --- a/drivers/net/ice/ice_hash.c
> +++ b/drivers/net/ice/ice_hash.c
> @@ -110,7 +110,7 @@ struct ice_rss_hash_cfg ipv4_tmplt = {
> ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
> ICE_FLOW_SEG_HDR_IPV_OTHER,
> ICE_FLOW_HASH_ETH | ICE_FLOW_HASH_IPV4,
> - ICE_RSS_ANY_HEADERS,
> + ICE_RSS_OUTER_HEADERS,
> 0
> };
>
> @@ -118,7 +118,7 @@ struct ice_rss_hash_cfg ipv4_udp_tmplt = {
> ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
> ICE_FLOW_SEG_HDR_IPV_OTHER | ICE_FLOW_SEG_HDR_UDP,
> ICE_FLOW_HASH_ETH | ICE_HASH_UDP_IPV4 | ICE_IPV4_PROT,
> - ICE_RSS_ANY_HEADERS,
> + ICE_RSS_OUTER_HEADERS,
> 0
> };
>
> @@ -126,7 +126,7 @@ struct ice_rss_hash_cfg ipv4_tcp_tmplt = {
> ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
> ICE_FLOW_SEG_HDR_IPV_OTHER | ICE_FLOW_SEG_HDR_TCP,
> ICE_FLOW_HASH_ETH | ICE_HASH_TCP_IPV4 | ICE_IPV4_PROT,
> - ICE_RSS_ANY_HEADERS,
> + ICE_RSS_OUTER_HEADERS,
> 0
> };
>
> @@ -134,7 +134,7 @@ struct ice_rss_hash_cfg ipv4_sctp_tmplt = {
> ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
> ICE_FLOW_SEG_HDR_IPV_OTHER | ICE_FLOW_SEG_HDR_SCTP,
> ICE_FLOW_HASH_ETH | ICE_HASH_SCTP_IPV4 | ICE_IPV4_PROT,
> - ICE_RSS_ANY_HEADERS,
> + ICE_RSS_OUTER_HEADERS,
> 0
> };
>
> @@ -142,7 +142,7 @@ struct ice_rss_hash_cfg ipv6_tmplt = {
> ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV6 |
> ICE_FLOW_SEG_HDR_IPV_OTHER,
> ICE_FLOW_HASH_ETH | ICE_FLOW_HASH_IPV6,
> - ICE_RSS_ANY_HEADERS,
> + ICE_RSS_O
[dpdk-dev] [PATCH v2 0/3] fix segment fault in avx512
Fix no memory segment fault of iavf, ice, i40e. v2: - Drop the duplicate code. Wenzhuo Lu (3): net/iavf: fix segment fault in AVX512 net/ice: fix segment fault in AVX512 net/i40e: fix segment fault in AVX512 drivers/net/i40e/i40e_rxtx_vec_avx2.c | 117 +-- drivers/net/i40e/i40e_rxtx_vec_avx512.c | 5 +- drivers/net/i40e/i40e_rxtx_vec_common.h | 199 +++ drivers/net/iavf/iavf_rxtx_vec_avx2.c | 120 +-- drivers/net/iavf/iavf_rxtx_vec_avx512.c | 5 +- drivers/net/iavf/iavf_rxtx_vec_common.h | 201 drivers/net/ice/ice_rxtx_vec_avx2.c | 120 +-- drivers/net/ice/ice_rxtx_vec_avx512.c | 5 +- drivers/net/ice/ice_rxtx_vec_common.h | 201 9 files changed, 619 insertions(+), 354 deletions(-) -- 1.9.3
[dpdk-dev] [PATCH v2 1/3] net/iavf: fix segment fault in AVX512
Fix segment fault when failing to get the memory from the pool.
Fixes: 31737f2b66fb ("net/iavf: enable AVX512 for legacy Rx")
Cc: sta...@dpdk.org
Reported-by: David Coyle
Signed-off-by: Wenzhuo Lu
---
drivers/net/iavf/iavf_rxtx_vec_avx2.c | 120 +--
drivers/net/iavf/iavf_rxtx_vec_avx512.c | 5 +-
drivers/net/iavf/iavf_rxtx_vec_common.h | 201
3 files changed, 207 insertions(+), 119 deletions(-)
diff --git a/drivers/net/iavf/iavf_rxtx_vec_avx2.c
b/drivers/net/iavf/iavf_rxtx_vec_avx2.c
index cdb5139..2c2b139 100644
--- a/drivers/net/iavf/iavf_rxtx_vec_avx2.c
+++ b/drivers/net/iavf/iavf_rxtx_vec_avx2.c
@@ -10,126 +10,10 @@
#pragma GCC diagnostic ignored "-Wcast-qual"
#endif
-static inline void
+static __rte_always_inline void
iavf_rxq_rearm(struct iavf_rx_queue *rxq)
{
- int i;
- uint16_t rx_id;
- volatile union iavf_rx_desc *rxdp;
- struct rte_mbuf **rxp = &rxq->sw_ring[rxq->rxrearm_start];
-
- rxdp = rxq->rx_ring + rxq->rxrearm_start;
-
- /* Pull 'n' more MBUFs into the software ring */
- if (rte_mempool_get_bulk(rxq->mp,
-(void *)rxp,
-IAVF_RXQ_REARM_THRESH) < 0) {
- if (rxq->rxrearm_nb + IAVF_RXQ_REARM_THRESH >=
- rxq->nb_rx_desc) {
- __m128i dma_addr0;
-
- dma_addr0 = _mm_setzero_si128();
- for (i = 0; i < IAVF_VPMD_DESCS_PER_LOOP; i++) {
- rxp[i] = &rxq->fake_mbuf;
- _mm_store_si128((__m128i *)&rxdp[i].read,
- dma_addr0);
- }
- }
- rte_eth_devices[rxq->port_id].data->rx_mbuf_alloc_failed +=
- IAVF_RXQ_REARM_THRESH;
- return;
- }
-
-#ifndef RTE_LIBRTE_IAVF_16BYTE_RX_DESC
- struct rte_mbuf *mb0, *mb1;
- __m128i dma_addr0, dma_addr1;
- __m128i hdr_room = _mm_set_epi64x(RTE_PKTMBUF_HEADROOM,
- RTE_PKTMBUF_HEADROOM);
- /* Initialize the mbufs in vector, process 2 mbufs in one loop */
- for (i = 0; i < IAVF_RXQ_REARM_THRESH; i += 2, rxp += 2) {
- __m128i vaddr0, vaddr1;
-
- mb0 = rxp[0];
- mb1 = rxp[1];
-
- /* load buf_addr(lo 64bit) and buf_iova(hi 64bit) */
- RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, buf_iova) !=
- offsetof(struct rte_mbuf, buf_addr) + 8);
- vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr);
- vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr);
-
- /* convert pa to dma_addr hdr/data */
- dma_addr0 = _mm_unpackhi_epi64(vaddr0, vaddr0);
- dma_addr1 = _mm_unpackhi_epi64(vaddr1, vaddr1);
-
- /* add headroom to pa values */
- dma_addr0 = _mm_add_epi64(dma_addr0, hdr_room);
- dma_addr1 = _mm_add_epi64(dma_addr1, hdr_room);
-
- /* flush desc with pa dma_addr */
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr0);
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr1);
- }
-#else
- struct rte_mbuf *mb0, *mb1, *mb2, *mb3;
- __m256i dma_addr0_1, dma_addr2_3;
- __m256i hdr_room = _mm256_set1_epi64x(RTE_PKTMBUF_HEADROOM);
- /* Initialize the mbufs in vector, process 4 mbufs in one loop */
- for (i = 0; i < IAVF_RXQ_REARM_THRESH;
- i += 4, rxp += 4, rxdp += 4) {
- __m128i vaddr0, vaddr1, vaddr2, vaddr3;
- __m256i vaddr0_1, vaddr2_3;
-
- mb0 = rxp[0];
- mb1 = rxp[1];
- mb2 = rxp[2];
- mb3 = rxp[3];
-
- /* load buf_addr(lo 64bit) and buf_iova(hi 64bit) */
- RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, buf_iova) !=
- offsetof(struct rte_mbuf, buf_addr) + 8);
- vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr);
- vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr);
- vaddr2 = _mm_loadu_si128((__m128i *)&mb2->buf_addr);
- vaddr3 = _mm_loadu_si128((__m128i *)&mb3->buf_addr);
-
- /**
-* merge 0 & 1, by casting 0 to 256-bit and inserting 1
-* into the high lanes. Similarly for 2 & 3
-*/
- vaddr0_1 =
- _mm256_inserti128_si256(_mm256_castsi128_si256(vaddr0),
- vaddr1, 1);
- vaddr2_3 =
- _mm256_inserti128_si256(_mm256_castsi128_si256(vaddr2),
- vaddr3, 1);
-
- /* convert pa to dma_addr hdr/data */
- dma_addr0_1 = _mm256_unpackhi_epi64(vaddr0_1, vad
[dpdk-dev] [PATCH v2 2/3] net/ice: fix segment fault in AVX512
Fix segment fault when failing to get the memory from the pool.
Fixes: 7f85d5ebcfe1 ("net/ice: add AVX512 vector path")
Cc: sta...@dpdk.org
Reported-by: David Coyle
Signed-off-by: Wenzhuo Lu
---
drivers/net/ice/ice_rxtx_vec_avx2.c | 120 +---
drivers/net/ice/ice_rxtx_vec_avx512.c | 5 +-
drivers/net/ice/ice_rxtx_vec_common.h | 201 ++
3 files changed, 207 insertions(+), 119 deletions(-)
diff --git a/drivers/net/ice/ice_rxtx_vec_avx2.c
b/drivers/net/ice/ice_rxtx_vec_avx2.c
index 1cc5490..8d3cf3e 100644
--- a/drivers/net/ice/ice_rxtx_vec_avx2.c
+++ b/drivers/net/ice/ice_rxtx_vec_avx2.c
@@ -10,126 +10,10 @@
#pragma GCC diagnostic ignored "-Wcast-qual"
#endif
-static inline void
+static __rte_always_inline void
ice_rxq_rearm(struct ice_rx_queue *rxq)
{
- int i;
- uint16_t rx_id;
- volatile union ice_rx_flex_desc *rxdp;
- struct ice_rx_entry *rxep = &rxq->sw_ring[rxq->rxrearm_start];
-
- rxdp = rxq->rx_ring + rxq->rxrearm_start;
-
- /* Pull 'n' more MBUFs into the software ring */
- if (rte_mempool_get_bulk(rxq->mp,
-(void *)rxep,
-ICE_RXQ_REARM_THRESH) < 0) {
- if (rxq->rxrearm_nb + ICE_RXQ_REARM_THRESH >=
- rxq->nb_rx_desc) {
- __m128i dma_addr0;
-
- dma_addr0 = _mm_setzero_si128();
- for (i = 0; i < ICE_DESCS_PER_LOOP; i++) {
- rxep[i].mbuf = &rxq->fake_mbuf;
- _mm_store_si128((__m128i *)&rxdp[i].read,
- dma_addr0);
- }
- }
- rte_eth_devices[rxq->port_id].data->rx_mbuf_alloc_failed +=
- ICE_RXQ_REARM_THRESH;
- return;
- }
-
-#ifndef RTE_LIBRTE_ICE_16BYTE_RX_DESC
- struct rte_mbuf *mb0, *mb1;
- __m128i dma_addr0, dma_addr1;
- __m128i hdr_room = _mm_set_epi64x(RTE_PKTMBUF_HEADROOM,
- RTE_PKTMBUF_HEADROOM);
- /* Initialize the mbufs in vector, process 2 mbufs in one loop */
- for (i = 0; i < ICE_RXQ_REARM_THRESH; i += 2, rxep += 2) {
- __m128i vaddr0, vaddr1;
-
- mb0 = rxep[0].mbuf;
- mb1 = rxep[1].mbuf;
-
- /* load buf_addr(lo 64bit) and buf_iova(hi 64bit) */
- RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, buf_iova) !=
- offsetof(struct rte_mbuf, buf_addr) + 8);
- vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr);
- vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr);
-
- /* convert pa to dma_addr hdr/data */
- dma_addr0 = _mm_unpackhi_epi64(vaddr0, vaddr0);
- dma_addr1 = _mm_unpackhi_epi64(vaddr1, vaddr1);
-
- /* add headroom to pa values */
- dma_addr0 = _mm_add_epi64(dma_addr0, hdr_room);
- dma_addr1 = _mm_add_epi64(dma_addr1, hdr_room);
-
- /* flush desc with pa dma_addr */
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr0);
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr1);
- }
-#else
- struct rte_mbuf *mb0, *mb1, *mb2, *mb3;
- __m256i dma_addr0_1, dma_addr2_3;
- __m256i hdr_room = _mm256_set1_epi64x(RTE_PKTMBUF_HEADROOM);
- /* Initialize the mbufs in vector, process 4 mbufs in one loop */
- for (i = 0; i < ICE_RXQ_REARM_THRESH;
- i += 4, rxep += 4, rxdp += 4) {
- __m128i vaddr0, vaddr1, vaddr2, vaddr3;
- __m256i vaddr0_1, vaddr2_3;
-
- mb0 = rxep[0].mbuf;
- mb1 = rxep[1].mbuf;
- mb2 = rxep[2].mbuf;
- mb3 = rxep[3].mbuf;
-
- /* load buf_addr(lo 64bit) and buf_iova(hi 64bit) */
- RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, buf_iova) !=
- offsetof(struct rte_mbuf, buf_addr) + 8);
- vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr);
- vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr);
- vaddr2 = _mm_loadu_si128((__m128i *)&mb2->buf_addr);
- vaddr3 = _mm_loadu_si128((__m128i *)&mb3->buf_addr);
-
- /**
-* merge 0 & 1, by casting 0 to 256-bit and inserting 1
-* into the high lanes. Similarly for 2 & 3
-*/
- vaddr0_1 =
- _mm256_inserti128_si256(_mm256_castsi128_si256(vaddr0),
- vaddr1, 1);
- vaddr2_3 =
- _mm256_inserti128_si256(_mm256_castsi128_si256(vaddr2),
- vaddr3, 1);
-
- /* convert pa to dma_addr hdr/data */
- dma_addr0_1 = _mm256_unpack
[dpdk-dev] [PATCH v2 3/3] net/i40e: fix segment fault in AVX512
Fix segment fault when failing to get the memory from the pool.
Fixes: e6a6a138919f ("net/i40e: add AVX512 vector path")
Cc: sta...@dpdk.org
Reported-by: David Coyle
Signed-off-by: Wenzhuo Lu
---
drivers/net/i40e/i40e_rxtx_vec_avx2.c | 117 +--
drivers/net/i40e/i40e_rxtx_vec_avx512.c | 5 +-
drivers/net/i40e/i40e_rxtx_vec_common.h | 199
3 files changed, 205 insertions(+), 116 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx_vec_avx2.c
b/drivers/net/i40e/i40e_rxtx_vec_avx2.c
index 15abd9d..133e2fb 100644
--- a/drivers/net/i40e/i40e_rxtx_vec_avx2.c
+++ b/drivers/net/i40e/i40e_rxtx_vec_avx2.c
@@ -18,123 +18,10 @@
#pragma GCC diagnostic ignored "-Wcast-qual"
#endif
-static inline void
+static __rte_always_inline void
i40e_rxq_rearm(struct i40e_rx_queue *rxq)
{
- int i;
- uint16_t rx_id;
- volatile union i40e_rx_desc *rxdp;
- struct i40e_rx_entry *rxep = &rxq->sw_ring[rxq->rxrearm_start];
-
- rxdp = rxq->rx_ring + rxq->rxrearm_start;
-
- /* Pull 'n' more MBUFs into the software ring */
- if (rte_mempool_get_bulk(rxq->mp,
-(void *)rxep,
-RTE_I40E_RXQ_REARM_THRESH) < 0) {
- if (rxq->rxrearm_nb + RTE_I40E_RXQ_REARM_THRESH >=
- rxq->nb_rx_desc) {
- __m128i dma_addr0;
- dma_addr0 = _mm_setzero_si128();
- for (i = 0; i < RTE_I40E_DESCS_PER_LOOP; i++) {
- rxep[i].mbuf = &rxq->fake_mbuf;
- _mm_store_si128((__m128i *)&rxdp[i].read,
- dma_addr0);
- }
- }
- rte_eth_devices[rxq->port_id].data->rx_mbuf_alloc_failed +=
- RTE_I40E_RXQ_REARM_THRESH;
- return;
- }
-
-#ifndef RTE_LIBRTE_I40E_16BYTE_RX_DESC
- struct rte_mbuf *mb0, *mb1;
- __m128i dma_addr0, dma_addr1;
- __m128i hdr_room = _mm_set_epi64x(RTE_PKTMBUF_HEADROOM,
- RTE_PKTMBUF_HEADROOM);
- /* Initialize the mbufs in vector, process 2 mbufs in one loop */
- for (i = 0; i < RTE_I40E_RXQ_REARM_THRESH; i += 2, rxep += 2) {
- __m128i vaddr0, vaddr1;
-
- mb0 = rxep[0].mbuf;
- mb1 = rxep[1].mbuf;
-
- /* load buf_addr(lo 64bit) and buf_iova(hi 64bit) */
- RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, buf_iova) !=
- offsetof(struct rte_mbuf, buf_addr) + 8);
- vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr);
- vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr);
-
- /* convert pa to dma_addr hdr/data */
- dma_addr0 = _mm_unpackhi_epi64(vaddr0, vaddr0);
- dma_addr1 = _mm_unpackhi_epi64(vaddr1, vaddr1);
-
- /* add headroom to pa values */
- dma_addr0 = _mm_add_epi64(dma_addr0, hdr_room);
- dma_addr1 = _mm_add_epi64(dma_addr1, hdr_room);
-
- /* flush desc with pa dma_addr */
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr0);
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr1);
- }
-#else
- struct rte_mbuf *mb0, *mb1, *mb2, *mb3;
- __m256i dma_addr0_1, dma_addr2_3;
- __m256i hdr_room = _mm256_set1_epi64x(RTE_PKTMBUF_HEADROOM);
- /* Initialize the mbufs in vector, process 4 mbufs in one loop */
- for (i = 0; i < RTE_I40E_RXQ_REARM_THRESH;
- i += 4, rxep += 4, rxdp += 4) {
- __m128i vaddr0, vaddr1, vaddr2, vaddr3;
- __m256i vaddr0_1, vaddr2_3;
-
- mb0 = rxep[0].mbuf;
- mb1 = rxep[1].mbuf;
- mb2 = rxep[2].mbuf;
- mb3 = rxep[3].mbuf;
-
- /* load buf_addr(lo 64bit) and buf_iova(hi 64bit) */
- RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, buf_iova) !=
- offsetof(struct rte_mbuf, buf_addr) + 8);
- vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr);
- vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr);
- vaddr2 = _mm_loadu_si128((__m128i *)&mb2->buf_addr);
- vaddr3 = _mm_loadu_si128((__m128i *)&mb3->buf_addr);
-
- /*
-* merge 0 & 1, by casting 0 to 256-bit and inserting 1
-* into the high lanes. Similarly for 2 & 3
-*/
- vaddr0_1 = _mm256_inserti128_si256(
- _mm256_castsi128_si256(vaddr0), vaddr1, 1);
- vaddr2_3 = _mm256_inserti128_si256(
- _mm256_castsi128_si256(vaddr2), vaddr3, 1);
-
- /* convert pa to dma_addr hdr/data */
- dma_addr0_1 = _mm256_unpackhi_epi64(vaddr0_1, vaddr0_1);
-
Re: [dpdk-dev] [PATCH v2 3/3] net/ice: support FDIR for IP fragment packet
Hi, Jeff
> -Original Message-
> From: Guo, Jia
> Sent: Wednesday, March 24, 2021 9:54 PM
> To: Yang, Qiming ; Zhang, Qi Z
>
> Cc: Xu, Ting ; dev@dpdk.org; Guo, Jia
> Subject: [PATCH v2 3/3] net/ice: support FDIR for IP fragment packet
>
> New FDIR parsing are added to handle the fragmented IPv4/IPv6 packet.
>
> Signed-off-by: Jeff Guo
> ---
> drivers/net/ice/ice_fdir_filter.c | 96 +++
> 1 file changed, 85 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ice/ice_fdir_filter.c
> b/drivers/net/ice/ice_fdir_filter.c
> index 3af5812660..3504d3c6c2 100644
> --- a/drivers/net/ice/ice_fdir_filter.c
> +++ b/drivers/net/ice/ice_fdir_filter.c
> @@ -24,7 +24,7 @@
> #define ICE_FDIR_INSET_ETH_IPV4 (\
> ICE_FDIR_INSET_ETH | \
> ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | ICE_INSET_IPV4_TOS | \
> - ICE_INSET_IPV4_TTL | ICE_INSET_IPV4_PROTO)
> + ICE_INSET_IPV4_TTL | ICE_INSET_IPV4_PROTO | ICE_INSET_IPV4_PKID)
>
> #define ICE_FDIR_INSET_ETH_IPV4_UDP (\
> ICE_FDIR_INSET_ETH_IPV4 | \
> @@ -41,7 +41,8 @@
> #define ICE_FDIR_INSET_ETH_IPV6 (\
> ICE_INSET_DMAC | \
> ICE_INSET_IPV6_SRC | ICE_INSET_IPV6_DST | ICE_INSET_IPV6_TC | \
> - ICE_INSET_IPV6_HOP_LIMIT | ICE_INSET_IPV6_NEXT_HDR)
> + ICE_INSET_IPV6_HOP_LIMIT | ICE_INSET_IPV6_NEXT_HDR | \
> + ICE_INSET_IPV6_PKID)
>
> #define ICE_FDIR_INSET_ETH_IPV6_UDP (\
> ICE_FDIR_INSET_ETH_IPV6 | \
> @@ -56,7 +57,8 @@
> ICE_INSET_SCTP_SRC_PORT | ICE_INSET_SCTP_DST_PORT)
>
> #define ICE_FDIR_INSET_IPV4 (\
> - ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST)
> + ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | \
> + ICE_INSET_IPV4_PKID)
>
> #define ICE_FDIR_INSET_IPV4_TCP (\
> ICE_FDIR_INSET_IPV4 | \
> @@ -72,7 +74,8 @@
>
> #define ICE_FDIR_INSET_ETH_IPV4_VXLAN (\
> ICE_FDIR_INSET_ETH | \
> - ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST)
> + ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | \
> + ICE_INSET_IPV4_PKID)
>
> #define ICE_FDIR_INSET_IPV4_GTPU (\
> ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | ICE_INSET_GTPU_TEID)
> @@ -95,6 +98,7 @@ static struct ice_pattern_match_item
> ice_fdir_pattern_list[] = {
> {pattern_eth_ipv4_tcp,
> ICE_FDIR_INSET_ETH_IPV4_TCP,ICE_INSET_NONE,
> ICE_INSET_NONE},
> {pattern_eth_ipv4_sctp,
> ICE_FDIR_INSET_ETH_IPV4_SCTP, ICE_INSET_NONE,
> ICE_INSET_NONE},
> {pattern_eth_ipv6,
> ICE_FDIR_INSET_ETH_IPV6,ICE_INSET_NONE,
> ICE_INSET_NONE},
> + {pattern_eth_ipv6_frag_ext,
> ICE_FDIR_INSET_ETH_IPV6,ICE_INSET_NONE,
> ICE_INSET_NONE},
> {pattern_eth_ipv6_udp,
> ICE_FDIR_INSET_ETH_IPV6_UDP,ICE_INSET_NONE,
> ICE_INSET_NONE},
> {pattern_eth_ipv6_tcp,
> ICE_FDIR_INSET_ETH_IPV6_TCP,ICE_INSET_NONE,
> ICE_INSET_NONE},
> {pattern_eth_ipv6_sctp,
> ICE_FDIR_INSET_ETH_IPV6_SCTP, ICE_INSET_NONE,
> ICE_INSET_NONE},
> @@ -882,11 +886,13 @@ ice_fdir_input_set_parse(uint64_t inset, enum
> ice_flow_field *field)
> {ICE_INSET_IPV4_TOS, ICE_FLOW_FIELD_IDX_IPV4_DSCP},
> {ICE_INSET_IPV4_TTL, ICE_FLOW_FIELD_IDX_IPV4_TTL},
> {ICE_INSET_IPV4_PROTO, ICE_FLOW_FIELD_IDX_IPV4_PROT},
> + {ICE_INSET_IPV4_PKID, ICE_FLOW_FIELD_IDX_IPV4_ID},
> {ICE_INSET_IPV6_SRC, ICE_FLOW_FIELD_IDX_IPV6_SA},
> {ICE_INSET_IPV6_DST, ICE_FLOW_FIELD_IDX_IPV6_DA},
> {ICE_INSET_IPV6_TC, ICE_FLOW_FIELD_IDX_IPV6_DSCP},
> {ICE_INSET_IPV6_NEXT_HDR,
> ICE_FLOW_FIELD_IDX_IPV6_PROT},
> {ICE_INSET_IPV6_HOP_LIMIT, ICE_FLOW_FIELD_IDX_IPV6_TTL},
> + {ICE_INSET_IPV6_PKID, ICE_FLOW_FIELD_IDX_IPV6_ID},
> {ICE_INSET_TCP_SRC_PORT,
> ICE_FLOW_FIELD_IDX_TCP_SRC_PORT},
> {ICE_INSET_TCP_DST_PORT,
> ICE_FLOW_FIELD_IDX_TCP_DST_PORT},
> {ICE_INSET_UDP_SRC_PORT,
> ICE_FLOW_FIELD_IDX_UDP_SRC_PORT}, @@ -935,6 +941,10 @@
> ice_fdir_input_set_hdrs(enum ice_fltr_ptype flow, struct ice_flow_seg_info
> *seg)
> ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV4 |
> ICE_FLOW_SEG_HDR_IPV_OTHER);
> break;
> + case ICE_FLTR_PTYPE_FRAG_IPV4:
> + ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV4 |
> + ICE_FLOW_SEG_HDR_IPV_FRAG);
> + break;
> case ICE_FLTR_PTYPE_NONF_IPV6_UDP:
> ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_UDP |
> ICE_FLOW_SEG_HDR_IPV6 |
> @@ -951,6 +961,10 @@ ice_fdir_input_set_hdrs(enum ice_fltr_ptype flow,
> struct ice_flow_seg_info *seg)
> ICE_FLOW_SEG_HDR_IPV_OTHER);
> break;
> case ICE_FLTR_PTYPE_NONF_IPV6_OTHER:
> + ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV6 |
> + ICE_FLOW_SEG_HDR_IPV_FRAG);
> +
Re: [dpdk-dev] [PATCH] net/ice: refine RSS configure
> -Original Message-
> From: Ding, Xuan
> Sent: Tuesday, March 30, 2021 11:00 AM
> To: Zhang, Qi Z ; Guo, Jia
> Cc: dev@dpdk.org; Yang, Qiming ; Noonan, Gordon
> ; Varshney, Shashank1
>
> Subject: RE: [PATCH] net/ice: refine RSS configure
>
> Hi Qi,
>
> Replies inline.
>
> > -Original Message-
> > From: Zhang, Qi Z
> > Sent: Thursday, March 25, 2021 8:43 PM
> > To: Guo, Jia ; Ding, Xuan
> > Cc: dev@dpdk.org; Yang, Qiming ; Noonan,
> Gordon
> > ; Varshney, Shashank1
> > ; Zhang, Qi Z
> > Subject: [PATCH] net/ice: refine RSS configure
> >
> > The ICE_RSS_ANY_HEADERS will try to enable outer RSS for non-tunnel
> > case and inner RSS for tunnel case. This confuse user.
> >
> > As we already have ICE_RSS_INNER_HEADER for tunnel case, So, replace
> > ICE_RSS_ANY_HEADERS with ICE_RSS_OUTER_HEADERS for all exist flow
> > which only specified the outer pattern.
> >
> > To enable inner RSS for any tunnel cases, a separated rule should be
> > enabled.
> >
> > The patch also remove some unncessary condition check for GTPU
>
> Here ' unncessary ' is a typo, should be 'unnecessary'.
>
> > in base code, as we already can support outer RSS for GTPU.
> >
> > Signed-off-by: Qi Zhang
> > ---
> > drivers/net/ice/base/ice_flow.c | 14
> > drivers/net/ice/ice_ethdev.c| 4 ++--
> > drivers/net/ice/ice_hash.c | 38 -
> > 3 files changed, 21 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/net/ice/base/ice_flow.c
> > b/drivers/net/ice/base/ice_flow.c index d123206fc6..bceb257d61 100644
> > --- a/drivers/net/ice/base/ice_flow.c
> > +++ b/drivers/net/ice/base/ice_flow.c
> > @@ -3678,13 +3678,6 @@ ice_add_rss_cfg_sync(struct ice_hw *hw, u16
> > vsi_handle, if (status) goto exit;
> >
> > -/* Don't do RSS for GTPU Outer */
> > -if (segs_cnt == ICE_FLOW_SEG_SINGLE &&
> > -segs[segs_cnt - 1].hdrs & ICE_FLOW_SEG_HDR_GTPU) {
> > -status = ICE_SUCCESS;
> > -goto exit;
> > -}
> > -
> > /* Search for a flow profile that has matching headers, hash fields
> > * and has the input VSI associated to it. If found, no further
> > * operations required and exit.
> > @@ -3847,13 +3840,6 @@ ice_rem_rss_cfg_sync(struct ice_hw *hw, u16
> > vsi_handle, if (status) goto out;
> >
> > -/* Don't do RSS for GTPU Outer */
> > -if (segs_cnt == ICE_FLOW_SEG_SINGLE &&
> > -segs[segs_cnt - 1].hdrs & ICE_FLOW_SEG_HDR_GTPU) {
> > -status = ICE_SUCCESS;
> > -goto out;
> > -}
> > -
> > prof = ice_flow_find_prof_conds(hw, blk, ICE_FLOW_RX, segs, segs_cnt,
> > vsi_handle, ICE_FLOW_FIND_PROF_CHK_FLDS); diff --git
> > a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c index
> > 3e85e5f629..4ccf31cb41 100644
> > --- a/drivers/net/ice/ice_ethdev.c
> > +++ b/drivers/net/ice/ice_ethdev.c
> > @@ -2348,7 +2348,7 @@ hash_cfg_reset(struct ice_rss_hash_cfg *cfg)
> > cfg->hash_flds = 0; cfg->addl_hdrs = 0; cfg->symm = 0;
> > -cfg->hdr_type = ICE_RSS_ANY_HEADERS;
> > +cfg->hdr_type = ICE_RSS_OUTER_HEADERS;
> > }
> >
> > static int
> > @@ -2833,7 +2833,7 @@ ice_rss_hash_set(struct ice_pf *pf, uint64_t
> rss_hf)
> > __func__, ret);
> >
> > cfg.symm = 0;
> > -cfg.hdr_type = ICE_RSS_ANY_HEADERS;
> > +cfg.hdr_type = ICE_RSS_OUTER_HEADERS;
> > /* Configure RSS for IPv4 with src/dst addr as input set */ if
> > (rss_hf & ETH_RSS_IPV4) { cfg.addl_hdrs = ICE_FLOW_SEG_HDR_IPV4 |
> > ICE_FLOW_SEG_HDR_IPV_OTHER; diff --git a/drivers/net/ice/ice_hash.c
> > b/drivers/net/ice/ice_hash.c index 58a0c18d09..7d7e7052da 100644
> > --- a/drivers/net/ice/ice_hash.c
> > +++ b/drivers/net/ice/ice_hash.c
> > @@ -110,7 +110,7 @@ struct ice_rss_hash_cfg ipv4_tmplt = {
> > ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
> > ICE_FLOW_SEG_HDR_IPV_OTHER, ICE_FLOW_HASH_ETH |
> ICE_FLOW_HASH_IPV4,
> > -ICE_RSS_ANY_HEADERS,
> > +ICE_RSS_OUTER_HEADERS,
> > 0
> > };
> >
> > @@ -118,7 +118,7 @@ struct ice_rss_hash_cfg ipv4_udp_tmplt = {
> > ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
> > ICE_FLOW_SEG_HDR_IPV_OTHER | ICE_FLOW_SEG_HDR_UDP,
> ICE_FLOW_HASH_ETH
> > | ICE_HASH_UDP_IPV4 | ICE_IPV4_PROT, -ICE_RSS_ANY_HEADERS,
> > +ICE_RSS_OUTER_HEADERS,
> > 0
> > };
> >
> > @@ -126,7 +126,7 @@ struct ice_rss_hash_cfg ipv4_tcp_tmplt = {
> > ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
> > ICE_FLOW_SEG_HDR_IPV_OTHER | ICE_FLOW_SEG_HDR_TCP,
> ICE_FLOW_HASH_ETH
> > | ICE_HASH_TCP_IPV4 | ICE_IPV4_PROT, -ICE_RSS_ANY_HEADERS,
> > +ICE_RSS_OUTER_HEADERS,
> > 0
> > };
> >
> > @@ -134,7 +134,7 @@ struct ice_rss_hash_cfg ipv4_sctp_tmplt = {
> > ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
> > ICE_FLOW_SEG_HDR_IPV_OTHER | ICE_FLOW_SEG_HDR_SCTP,
> ICE_FLOW_HASH_ETH
> > | ICE_HASH_SCTP_IPV4 | ICE_IPV4_PROT, -ICE_RSS_ANY_HEADERS,
> > +ICE_RSS_OUTER_HEADERS,
> > 0
> > };
> >
> > @@ -142,7 +142,7 @@ struct ice_rss_hash_cfg ipv6_tmplt = {
> > ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV6 |
> > ICE_FLOW_SEG_HDR_IPV_OTHER, ICE_FLOW_HASH_ETH |
> ICE_FLOW_HASH_IPV6,
> > -ICE_RSS_ANY_HEADERS,
> >
Re: [dpdk-dev] [PATCH v1 0/2] Enhancements to crypto adapter forward mode
On Fri, Mar 26, 2021 at 2:43 PM Shijith Thotton wrote:
>
> This series proposes a new event device enqueue operation if crypto
> adapter forward mode is supported. Second patch in the series is the
> implementation of the same in PMD. Test application changes for the
> usage of new API is yet to add.
Please submit the new version with the test application change.
>
> v1:
> - Added crypto adapter forward mode support for octeontx2.
>
> Akhil Goyal (1):
> eventdev: introduce crypto adapter enqueue API
@Gujjar, Abhinandan S
Could you review the API changes?
>
> Shijith Thotton (1):
> event/octeontx2: support crypto adapter forward mode
>
> .../prog_guide/event_crypto_adapter.rst | 69 ++--
> drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 34 +---
> drivers/event/octeontx2/otx2_evdev.c | 5 +-
> .../event/octeontx2/otx2_evdev_crypto_adptr.c | 3 +-
> ...dptr_dp.h => otx2_evdev_crypto_adptr_rx.h} | 6 +-
> .../octeontx2/otx2_evdev_crypto_adptr_tx.h| 82 +++
> drivers/event/octeontx2/otx2_worker.h | 2 +-
> drivers/event/octeontx2/otx2_worker_dual.h| 2 +-
> lib/librte_eventdev/eventdev_trace_points.c | 3 +
> .../rte_event_crypto_adapter.h| 66 +++
> lib/librte_eventdev/rte_eventdev.c| 10 +++
> lib/librte_eventdev/rte_eventdev.h| 8 +-
> lib/librte_eventdev/rte_eventdev_trace_fp.h | 10 +++
> lib/librte_eventdev/version.map | 3 +
> 14 files changed, 259 insertions(+), 44 deletions(-)
> rename drivers/event/octeontx2/{otx2_evdev_crypto_adptr_dp.h =>
> otx2_evdev_crypto_adptr_rx.h} (93%)
> create mode 100644 drivers/event/octeontx2/otx2_evdev_crypto_adptr_tx.h
>
> --
> 2.25.1
>
Re: [dpdk-dev] [PATCH] net/ice: refine RSS configure
> -Original Message-
> From: Zhang, Qi Z
> Sent: Tuesday, March 30, 2021 11:30 AM
> To: Ding, Xuan ; Guo, Jia
> Cc: dev@dpdk.org; Yang, Qiming ; Noonan, Gordon
> ; Varshney, Shashank1
>
> Subject: RE: [PATCH] net/ice: refine RSS configure
>
>
>
> > -Original Message-
> > From: Ding, Xuan
> > Sent: Tuesday, March 30, 2021 11:00 AM
> > To: Zhang, Qi Z ; Guo, Jia
> > Cc: dev@dpdk.org; Yang, Qiming ; Noonan, Gordon
> > ; Varshney, Shashank1
> >
> > Subject: RE: [PATCH] net/ice: refine RSS configure
> >
> > Hi Qi,
> >
> > Replies inline.
> >
> > > -Original Message-
> > > From: Zhang, Qi Z
> > > Sent: Thursday, March 25, 2021 8:43 PM
> > > To: Guo, Jia ; Ding, Xuan
> > > Cc: dev@dpdk.org; Yang, Qiming ; Noonan,
> > Gordon
> > > ; Varshney, Shashank1
> > > ; Zhang, Qi Z
> > > Subject: [PATCH] net/ice: refine RSS configure
> > >
> > > The ICE_RSS_ANY_HEADERS will try to enable outer RSS for non-tunnel
> > > case and inner RSS for tunnel case. This confuse user.
> > >
> > > As we already have ICE_RSS_INNER_HEADER for tunnel case, So, replace
> > > ICE_RSS_ANY_HEADERS with ICE_RSS_OUTER_HEADERS for all exist flow
> > > which only specified the outer pattern.
> > >
> > > To enable inner RSS for any tunnel cases, a separated rule should be
> > > enabled.
> > >
> > > The patch also remove some unncessary condition check for GTPU
> >
> > Here ' unncessary ' is a typo, should be 'unnecessary'.
> >
> > > in base code, as we already can support outer RSS for GTPU.
> > >
> > > Signed-off-by: Qi Zhang
> > > ---
> > > drivers/net/ice/base/ice_flow.c | 14
> > > drivers/net/ice/ice_ethdev.c| 4 ++--
> > > drivers/net/ice/ice_hash.c | 38 -
> > > 3 files changed, 21 insertions(+), 35 deletions(-)
> > >
> > > diff --git a/drivers/net/ice/base/ice_flow.c
> > > b/drivers/net/ice/base/ice_flow.c index d123206fc6..bceb257d61 100644
> > > --- a/drivers/net/ice/base/ice_flow.c
> > > +++ b/drivers/net/ice/base/ice_flow.c
> > > @@ -3678,13 +3678,6 @@ ice_add_rss_cfg_sync(struct ice_hw *hw, u16
> > > vsi_handle, if (status) goto exit;
> > >
> > > -/* Don't do RSS for GTPU Outer */
> > > -if (segs_cnt == ICE_FLOW_SEG_SINGLE &&
> > > -segs[segs_cnt - 1].hdrs & ICE_FLOW_SEG_HDR_GTPU) {
> > > -status = ICE_SUCCESS;
> > > -goto exit;
> > > -}
> > > -
> > > /* Search for a flow profile that has matching headers, hash fields
> > > * and has the input VSI associated to it. If found, no further
> > > * operations required and exit.
> > > @@ -3847,13 +3840,6 @@ ice_rem_rss_cfg_sync(struct ice_hw *hw, u16
> > > vsi_handle, if (status) goto out;
> > >
> > > -/* Don't do RSS for GTPU Outer */
> > > -if (segs_cnt == ICE_FLOW_SEG_SINGLE &&
> > > -segs[segs_cnt - 1].hdrs & ICE_FLOW_SEG_HDR_GTPU) {
> > > -status = ICE_SUCCESS;
> > > -goto out;
> > > -}
> > > -
> > > prof = ice_flow_find_prof_conds(hw, blk, ICE_FLOW_RX, segs, segs_cnt,
> > > vsi_handle, ICE_FLOW_FIND_PROF_CHK_FLDS); diff --git
> > > a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c index
> > > 3e85e5f629..4ccf31cb41 100644
> > > --- a/drivers/net/ice/ice_ethdev.c
> > > +++ b/drivers/net/ice/ice_ethdev.c
> > > @@ -2348,7 +2348,7 @@ hash_cfg_reset(struct ice_rss_hash_cfg *cfg)
> > > cfg->hash_flds = 0; cfg->addl_hdrs = 0; cfg->symm = 0;
> > > -cfg->hdr_type = ICE_RSS_ANY_HEADERS;
> > > +cfg->hdr_type = ICE_RSS_OUTER_HEADERS;
> > > }
> > >
> > > static int
> > > @@ -2833,7 +2833,7 @@ ice_rss_hash_set(struct ice_pf *pf, uint64_t
> > rss_hf)
> > > __func__, ret);
> > >
> > > cfg.symm = 0;
> > > -cfg.hdr_type = ICE_RSS_ANY_HEADERS;
> > > +cfg.hdr_type = ICE_RSS_OUTER_HEADERS;
> > > /* Configure RSS for IPv4 with src/dst addr as input set */ if
> > > (rss_hf & ETH_RSS_IPV4) { cfg.addl_hdrs = ICE_FLOW_SEG_HDR_IPV4 |
> > > ICE_FLOW_SEG_HDR_IPV_OTHER; diff --git a/drivers/net/ice/ice_hash.c
> > > b/drivers/net/ice/ice_hash.c index 58a0c18d09..7d7e7052da 100644
> > > --- a/drivers/net/ice/ice_hash.c
> > > +++ b/drivers/net/ice/ice_hash.c
> > > @@ -110,7 +110,7 @@ struct ice_rss_hash_cfg ipv4_tmplt = {
> > > ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
> > > ICE_FLOW_SEG_HDR_IPV_OTHER, ICE_FLOW_HASH_ETH |
> > ICE_FLOW_HASH_IPV4,
> > > -ICE_RSS_ANY_HEADERS,
> > > +ICE_RSS_OUTER_HEADERS,
> > > 0
> > > };
> > >
> > > @@ -118,7 +118,7 @@ struct ice_rss_hash_cfg ipv4_udp_tmplt = {
> > > ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
> > > ICE_FLOW_SEG_HDR_IPV_OTHER | ICE_FLOW_SEG_HDR_UDP,
> > ICE_FLOW_HASH_ETH
> > > | ICE_HASH_UDP_IPV4 | ICE_IPV4_PROT, -ICE_RSS_ANY_HEADERS,
> > > +ICE_RSS_OUTER_HEADERS,
> > > 0
> > > };
> > >
> > > @@ -126,7 +126,7 @@ struct ice_rss_hash_cfg ipv4_tcp_tmplt = {
> > > ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
> > > ICE_FLOW_SEG_HDR_IPV_OTHER | ICE_FLOW_SEG_HDR_TCP,
> > ICE_FLOW_HASH_ETH
> > > | ICE_HASH_TCP_IPV4 | ICE_IPV4_PROT, -ICE_RSS_ANY_HEADERS,
> > > +ICE_RSS_OUTER_HEADERS,
> > > 0
> > > };
> > >
> > > @@ -134,7 +134
Re: [dpdk-dev] [PATCH v3] pflock: implementation of phase-fair reader writer locks
On Tue, 30 Mar 2021 00:18:40 + Honnappa Nagarahalli wrote: > > That won't work because the implementation of trylock requires > > compare/exchange of the whole structure as an atomic operation. > I meant, placing 'rd' and 'wr' on separate cache lines. It might help in the > reader-writer contention case. Except ARM default cache size is 128 which makes these locks rather large. The reader is the hot case and it doesn't look at the writer part.
Re: [dpdk-dev] [PATCH v1 0/2] Enhancements to crypto adapter forward mode
> -Original Message-
> From: Jerin Jacob
> Sent: Tuesday, March 30, 2021 9:34 AM
> To: Shijith Thotton
> Cc: dpdk-dev ; Thomas Monjalon
> ; Jerin Jacob ; Gujjar,
> Abhinandan S ; Hemant Agrawal
> ; Nipun Gupta ;
> sachin.sax...@oss.nxp.com; Anoob Joseph ; Matan
> Azrad ; Zhang, Roy Fan ;
> Gagandeep Singh ; Carrillo, Erik G
> ; Jayatheerthan, Jay
> ; Pavan Nikhilesh
> ; Van Haaren, Harry
> ; Akhil Goyal
> Subject: Re: [dpdk-dev] [PATCH v1 0/2] Enhancements to crypto adapter
> forward mode
>
> On Fri, Mar 26, 2021 at 2:43 PM Shijith Thotton
> wrote:
> >
> > This series proposes a new event device enqueue operation if crypto
> > adapter forward mode is supported. Second patch in the series is the
> > implementation of the same in PMD. Test application changes for the
> > usage of new API is yet to add.
>
> Please submit the new version with the test application change.
>
> >
> > v1:
> > - Added crypto adapter forward mode support for octeontx2.
> >
> > Akhil Goyal (1):
> > eventdev: introduce crypto adapter enqueue API
>
>
> @Gujjar, Abhinandan S
>
> Could you review the API changes?
Yes Jerin. I will review by this week end.
>
>
> >
> > Shijith Thotton (1):
> > event/octeontx2: support crypto adapter forward mode
> >
> > .../prog_guide/event_crypto_adapter.rst | 69 ++--
> > drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 34 +---
> > drivers/event/octeontx2/otx2_evdev.c | 5 +-
> > .../event/octeontx2/otx2_evdev_crypto_adptr.c | 3 +- ...dptr_dp.h
> > => otx2_evdev_crypto_adptr_rx.h} | 6 +-
> > .../octeontx2/otx2_evdev_crypto_adptr_tx.h| 82
> +++
> > drivers/event/octeontx2/otx2_worker.h | 2 +-
> > drivers/event/octeontx2/otx2_worker_dual.h| 2 +-
> > lib/librte_eventdev/eventdev_trace_points.c | 3 +
> > .../rte_event_crypto_adapter.h| 66 +++
> > lib/librte_eventdev/rte_eventdev.c| 10 +++
> > lib/librte_eventdev/rte_eventdev.h| 8 +-
> > lib/librte_eventdev/rte_eventdev_trace_fp.h | 10 +++
> > lib/librte_eventdev/version.map | 3 +
> > 14 files changed, 259 insertions(+), 44 deletions(-) rename
> > drivers/event/octeontx2/{otx2_evdev_crypto_adptr_dp.h =>
> > otx2_evdev_crypto_adptr_rx.h} (93%) create mode 100644
> > drivers/event/octeontx2/otx2_evdev_crypto_adptr_tx.h
> >
> > --
> > 2.25.1
> >
[dpdk-dev] [PATCH v4] pflock: add phase-fair reader writer locks
This is a new type of reader-writer lock that provides better fairness
guarantees which better suited for typical DPDK applications.
A pflock has two ticket pools, one for readers and one
for writers.
Phase fair reader writer locks ensure that neither reader nor writer will be
starved. Neither reader or writer are preferred, they execute in
alternating phases. All operations of the same type (reader or writer)
that acquire the lock are handled in FIFO order. Write
operations are exclusive, and multiple read operations can be run
together (until a write arrives).
A similar implementation is in Concurrency Kit package in FreeBSD.
For more information see:
"Reader-Writer Synchronization for Shared-Memory Multiprocessor
Real-Time Systems",
http://www.cs.unc.edu/~anderson/papers/ecrts09b.pdf
Signed-off-by: Stephen Hemminger
---
app/test/meson.build| 2 +
app/test/test_pflock.c | 193 +++
lib/librte_eal/arm/include/meson.build | 1 +
lib/librte_eal/arm/include/rte_pflock.h | 18 ++
lib/librte_eal/include/generic/rte_pflock.h | 202
lib/librte_eal/ppc/include/meson.build | 1 +
lib/librte_eal/ppc/include/rte_pflock.h | 17 ++
lib/librte_eal/x86/include/meson.build | 1 +
lib/librte_eal/x86/include/rte_pflock.h | 18 ++
9 files changed, 453 insertions(+)
create mode 100644 app/test/test_pflock.c
create mode 100644 lib/librte_eal/arm/include/rte_pflock.h
create mode 100644 lib/librte_eal/include/generic/rte_pflock.h
create mode 100644 lib/librte_eal/ppc/include/rte_pflock.h
create mode 100644 lib/librte_eal/x86/include/rte_pflock.h
diff --git a/app/test/meson.build b/app/test/meson.build
index 76eaaea45746..bd50818f82b0 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -90,6 +90,7 @@ test_sources = files('commands.c',
'test_mcslock.c',
'test_mp_secondary.c',
'test_per_lcore.c',
+ 'test_pflock.c',
'test_pmd_perf.c',
'test_power.c',
'test_power_cpufreq.c',
@@ -228,6 +229,7 @@ fast_tests = [
['meter_autotest', true],
['multiprocess_autotest', false],
['per_lcore_autotest', true],
+['pflock_autotest', true],
['prefetch_autotest', true],
['rcu_qsbr_autotest', true],
['red_autotest', true],
diff --git a/app/test/test_pflock.c b/app/test/test_pflock.c
new file mode 100644
index ..5e3c05767767
--- /dev/null
+++ b/app/test/test_pflock.c
@@ -0,0 +1,193 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Microsoft Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "test.h"
+
+/*
+ * phase fair lock test
+ * ===
+ * Provides UT for phase fair lock API.
+ * Main concern is on functional testing, but also provides some
+ * performance measurements.
+ * Obviously for proper testing need to be executed with more than one lcore.
+ */
+
+#define ITER_NUM 0x80
+
+#define TEST_SEC 5
+
+static rte_pflock_t sl;
+static rte_pflock_t sl_tab[RTE_MAX_LCORE];
+static uint32_t synchro;
+
+enum {
+ LC_TYPE_RDLOCK,
+ LC_TYPE_WRLOCK,
+};
+
+static int
+test_pflock_per_core(__rte_unused void *arg)
+{
+ rte_pflock_write_lock(&sl);
+ printf("Global write lock taken on core %u\n", rte_lcore_id());
+ rte_pflock_write_unlock(&sl);
+
+ rte_pflock_write_lock(&sl_tab[rte_lcore_id()]);
+ printf("Hello from core %u !\n", rte_lcore_id());
+ rte_pflock_write_unlock(&sl_tab[rte_lcore_id()]);
+
+ rte_pflock_read_lock(&sl);
+ printf("Global read lock taken on core %u\n", rte_lcore_id());
+ rte_delay_ms(100);
+ printf("Release global read lock on core %u\n", rte_lcore_id());
+ rte_pflock_read_unlock(&sl);
+
+ return 0;
+}
+
+static rte_pflock_t lk = RTE_PFLOCK_INITIALIZER;
+static volatile uint64_t pflock_data;
+static uint64_t time_count[RTE_MAX_LCORE] = {0};
+
+#define MAX_LOOP 1
+#define TEST_PFLOCK_DEBUG 0
+
+static int
+load_loop_fn(__rte_unused void *arg)
+{
+ uint64_t time_diff = 0, begin;
+ uint64_t hz = rte_get_timer_hz();
+ uint64_t lcount = 0;
+ const unsigned int lcore = rte_lcore_id();
+
+ /* wait synchro for workers */
+ if (lcore != rte_get_main_lcore())
+ rte_wait_until_equal_32(&synchro, 1, __ATOMIC_RELAXED);
+
+ begin = rte_rdtsc_precise();
+ while (lcount < MAX_LOOP) {
+ rte_pflock_write_lock(&lk);
+ ++pflock_data;
+ rte_pflock_write_unlock(&lk);
+
+ rte_pflock_read_lock(&lk);
+ if (TEST_PFLOCK_DEBUG && !(lcount % 100))
+ printf("Core [%u] pflock_data = %"PRIu64"\n",
+ lcore, pflock_data);
+ rte_pflock_re
[dpdk-dev] [Bug 666] [dpdk-21.05] unit_test_eal/test_kvargs: dpdk-20.11.0 use dpdk-21.05 lib to run kvargs_autotest failed.
https://bugs.dpdk.org/show_bug.cgi?id=666 lingwei (weix.l...@intel.com) changed: What|Removed |Added Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED --- Comment #2 from lingwei (weix.l...@intel.com) --- It's dpdk feature update, not a dpdk bug, so close it. -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [PATCH v4] pflock: add phase-fair reader writer locks
On Mon, 29 Mar 2021 22:00:47 -0700 Stephen Hemminger wrote: > This is a new type of reader-writer lock that provides better fairness > guarantees which better suited for typical DPDK applications. > A pflock has two ticket pools, one for readers and one > for writers. > > Phase fair reader writer locks ensure that neither reader nor writer will be > starved. Neither reader or writer are preferred, they execute in > alternating phases. All operations of the same type (reader or writer) > that acquire the lock are handled in FIFO order. Write > operations are exclusive, and multiple read operations can be run > together (until a write arrives). > > A similar implementation is in Concurrency Kit package in FreeBSD. > For more information see: >"Reader-Writer Synchronization for Shared-Memory Multiprocessor > Real-Time Systems", > http://www.cs.unc.edu/~anderson/papers/ecrts09b.pdf > > Signed-off-by: Stephen Hemminger v4 incorporates feedback, adds some comments and drops the trylock for now.
Re: [dpdk-dev] [PATCH] net/ice: refine RSS configure
> -Original Message-
> From: Ding, Xuan
> Sent: Tuesday, March 30, 2021 12:31 PM
> To: Zhang, Qi Z ; Guo, Jia
> Cc: dev@dpdk.org; Yang, Qiming ; Noonan, Gordon
> ; Varshney, Shashank1
>
> Subject: RE: [PATCH] net/ice: refine RSS configure
>
>
> > -Original Message-
> > From: Zhang, Qi Z
> > Sent: Tuesday, March 30, 2021 11:30 AM
> > To: Ding, Xuan ; Guo, Jia
> > Cc: dev@dpdk.org; Yang, Qiming ; Noonan,
> Gordon
> > ; Varshney, Shashank1
> >
> > Subject: RE: [PATCH] net/ice: refine RSS configure
> >
> >
> >
> > > -Original Message-
> > > From: Ding, Xuan
> > > Sent: Tuesday, March 30, 2021 11:00 AM
> > > To: Zhang, Qi Z ; Guo, Jia
> > > Cc: dev@dpdk.org; Yang, Qiming ; Noonan,
> > > Gordon ; Varshney, Shashank1
> > >
> > > Subject: RE: [PATCH] net/ice: refine RSS configure
> > >
> > > Hi Qi,
> > >
> > > Replies inline.
> > >
> > > > -Original Message-
> > > > From: Zhang, Qi Z
> > > > Sent: Thursday, March 25, 2021 8:43 PM
> > > > To: Guo, Jia ; Ding, Xuan
> > > > Cc: dev@dpdk.org; Yang, Qiming ; Noonan,
> > > Gordon
> > > > ; Varshney, Shashank1
> > > > ; Zhang, Qi Z
> > > > Subject: [PATCH] net/ice: refine RSS configure
> > > >
> > > > The ICE_RSS_ANY_HEADERS will try to enable outer RSS for
> > > > non-tunnel case and inner RSS for tunnel case. This confuse user.
> > > >
> > > > As we already have ICE_RSS_INNER_HEADER for tunnel case, So,
> > > > replace ICE_RSS_ANY_HEADERS with ICE_RSS_OUTER_HEADERS for all
> > > > exist flow which only specified the outer pattern.
> > > >
> > > > To enable inner RSS for any tunnel cases, a separated rule should
> > > > be enabled.
> > > >
> > > > The patch also remove some unncessary condition check for GTPU
> > >
> > > Here ' unncessary ' is a typo, should be 'unnecessary'.
> > >
> > > > in base code, as we already can support outer RSS for GTPU.
> > > >
> > > > Signed-off-by: Qi Zhang
> > > > ---
> > > > drivers/net/ice/base/ice_flow.c | 14
> > > > drivers/net/ice/ice_ethdev.c| 4 ++--
> > > > drivers/net/ice/ice_hash.c | 38 -
> > > > 3 files changed, 21 insertions(+), 35 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ice/base/ice_flow.c
> > > > b/drivers/net/ice/base/ice_flow.c index d123206fc6..bceb257d61
> > > > 100644
> > > > --- a/drivers/net/ice/base/ice_flow.c
> > > > +++ b/drivers/net/ice/base/ice_flow.c
> > > > @@ -3678,13 +3678,6 @@ ice_add_rss_cfg_sync(struct ice_hw *hw,
> u16
> > > > vsi_handle, if (status) goto exit;
> > > >
> > > > -/* Don't do RSS for GTPU Outer */ -if (segs_cnt ==
> > > > ICE_FLOW_SEG_SINGLE &&
> > > > -segs[segs_cnt - 1].hdrs & ICE_FLOW_SEG_HDR_GTPU) {
> > > > -status = ICE_SUCCESS;
> > > > -goto exit;
> > > > -}
> > > > -
> > > > /* Search for a flow profile that has matching headers, hash fields
> > > > * and has the input VSI associated to it. If found, no further
> > > > * operations required and exit.
> > > > @@ -3847,13 +3840,6 @@ ice_rem_rss_cfg_sync(struct ice_hw *hw,
> u16
> > > > vsi_handle, if (status) goto out;
> > > >
> > > > -/* Don't do RSS for GTPU Outer */ -if (segs_cnt ==
> > > > ICE_FLOW_SEG_SINGLE &&
> > > > -segs[segs_cnt - 1].hdrs & ICE_FLOW_SEG_HDR_GTPU) {
> > > > -status = ICE_SUCCESS;
> > > > -goto out;
> > > > -}
> > > > -
> > > > prof = ice_flow_find_prof_conds(hw, blk, ICE_FLOW_RX, segs,
> > > > segs_cnt, vsi_handle, ICE_FLOW_FIND_PROF_CHK_FLDS); diff --git
> > > > a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
> > > > index
> > > > 3e85e5f629..4ccf31cb41 100644
> > > > --- a/drivers/net/ice/ice_ethdev.c
> > > > +++ b/drivers/net/ice/ice_ethdev.c
> > > > @@ -2348,7 +2348,7 @@ hash_cfg_reset(struct ice_rss_hash_cfg *cfg)
> > > > cfg->hash_flds = 0; cfg->addl_hdrs = 0; cfg->symm = 0;
> > > > -cfg->hdr_type = ICE_RSS_ANY_HEADERS;
> > > > +cfg->hdr_type = ICE_RSS_OUTER_HEADERS;
> > > > }
> > > >
> > > > static int
> > > > @@ -2833,7 +2833,7 @@ ice_rss_hash_set(struct ice_pf *pf, uint64_t
> > > rss_hf)
> > > > __func__, ret);
> > > >
> > > > cfg.symm = 0;
> > > > -cfg.hdr_type = ICE_RSS_ANY_HEADERS;
> > > > +cfg.hdr_type = ICE_RSS_OUTER_HEADERS;
> > > > /* Configure RSS for IPv4 with src/dst addr as input set */ if
> > > > (rss_hf & ETH_RSS_IPV4) { cfg.addl_hdrs = ICE_FLOW_SEG_HDR_IPV4 |
> > > > ICE_FLOW_SEG_HDR_IPV_OTHER; diff --git
> > > > a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c index
> > > > 58a0c18d09..7d7e7052da 100644
> > > > --- a/drivers/net/ice/ice_hash.c
> > > > +++ b/drivers/net/ice/ice_hash.c
> > > > @@ -110,7 +110,7 @@ struct ice_rss_hash_cfg ipv4_tmplt = {
> > > > ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
> > > > ICE_FLOW_SEG_HDR_IPV_OTHER, ICE_FLOW_HASH_ETH |
> > > ICE_FLOW_HASH_IPV4,
> > > > -ICE_RSS_ANY_HEADERS,
> > > > +ICE_RSS_OUTER_HEADERS,
> > > > 0
> > > > };
> > > >
> > > > @@ -118,7 +118,7 @@ struct ice_rss_hash_cfg ipv4_udp_tmplt = {
> > > > ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
> > > > ICE_FL
[dpdk-dev] [PATCH v3 0/3] fix segment fault in avx512 code
Fix no memory segment fault of iavf, ice, i40e. v2: - Drop the duplicate code. v3: - Fix compile error on no-x86 platform. Wenzhuo Lu (3): net/iavf: fix segment fault in AVX512 net/ice: fix segment fault in AVX512 net/i40e: fix segment fault in AVX512 drivers/net/i40e/i40e_rxtx_vec_avx2.c | 117 +- drivers/net/i40e/i40e_rxtx_vec_avx512.c | 5 +- drivers/net/i40e/i40e_rxtx_vec_common.h | 201 +++ drivers/net/iavf/iavf_rxtx_vec_avx2.c | 120 +-- drivers/net/iavf/iavf_rxtx_vec_avx512.c | 5 +- drivers/net/iavf/iavf_rxtx_vec_common.h | 203 drivers/net/ice/ice_rxtx_vec_avx2.c | 120 +-- drivers/net/ice/ice_rxtx_vec_avx512.c | 5 +- drivers/net/ice/ice_rxtx_vec_common.h | 203 9 files changed, 625 insertions(+), 354 deletions(-) -- 1.9.3
[dpdk-dev] [PATCH v3 1/3] net/iavf: fix segment fault in AVX512
Fix segment fault when failing to get the memory from the pool.
Fixes: 31737f2b66fb ("net/iavf: enable AVX512 for legacy Rx")
Cc: sta...@dpdk.org
Reported-by: David Coyle
Signed-off-by: Wenzhuo Lu
---
drivers/net/iavf/iavf_rxtx_vec_avx2.c | 120 +--
drivers/net/iavf/iavf_rxtx_vec_avx512.c | 5 +-
drivers/net/iavf/iavf_rxtx_vec_common.h | 203
3 files changed, 209 insertions(+), 119 deletions(-)
diff --git a/drivers/net/iavf/iavf_rxtx_vec_avx2.c
b/drivers/net/iavf/iavf_rxtx_vec_avx2.c
index cdb5139..2c2b139 100644
--- a/drivers/net/iavf/iavf_rxtx_vec_avx2.c
+++ b/drivers/net/iavf/iavf_rxtx_vec_avx2.c
@@ -10,126 +10,10 @@
#pragma GCC diagnostic ignored "-Wcast-qual"
#endif
-static inline void
+static __rte_always_inline void
iavf_rxq_rearm(struct iavf_rx_queue *rxq)
{
- int i;
- uint16_t rx_id;
- volatile union iavf_rx_desc *rxdp;
- struct rte_mbuf **rxp = &rxq->sw_ring[rxq->rxrearm_start];
-
- rxdp = rxq->rx_ring + rxq->rxrearm_start;
-
- /* Pull 'n' more MBUFs into the software ring */
- if (rte_mempool_get_bulk(rxq->mp,
-(void *)rxp,
-IAVF_RXQ_REARM_THRESH) < 0) {
- if (rxq->rxrearm_nb + IAVF_RXQ_REARM_THRESH >=
- rxq->nb_rx_desc) {
- __m128i dma_addr0;
-
- dma_addr0 = _mm_setzero_si128();
- for (i = 0; i < IAVF_VPMD_DESCS_PER_LOOP; i++) {
- rxp[i] = &rxq->fake_mbuf;
- _mm_store_si128((__m128i *)&rxdp[i].read,
- dma_addr0);
- }
- }
- rte_eth_devices[rxq->port_id].data->rx_mbuf_alloc_failed +=
- IAVF_RXQ_REARM_THRESH;
- return;
- }
-
-#ifndef RTE_LIBRTE_IAVF_16BYTE_RX_DESC
- struct rte_mbuf *mb0, *mb1;
- __m128i dma_addr0, dma_addr1;
- __m128i hdr_room = _mm_set_epi64x(RTE_PKTMBUF_HEADROOM,
- RTE_PKTMBUF_HEADROOM);
- /* Initialize the mbufs in vector, process 2 mbufs in one loop */
- for (i = 0; i < IAVF_RXQ_REARM_THRESH; i += 2, rxp += 2) {
- __m128i vaddr0, vaddr1;
-
- mb0 = rxp[0];
- mb1 = rxp[1];
-
- /* load buf_addr(lo 64bit) and buf_iova(hi 64bit) */
- RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, buf_iova) !=
- offsetof(struct rte_mbuf, buf_addr) + 8);
- vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr);
- vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr);
-
- /* convert pa to dma_addr hdr/data */
- dma_addr0 = _mm_unpackhi_epi64(vaddr0, vaddr0);
- dma_addr1 = _mm_unpackhi_epi64(vaddr1, vaddr1);
-
- /* add headroom to pa values */
- dma_addr0 = _mm_add_epi64(dma_addr0, hdr_room);
- dma_addr1 = _mm_add_epi64(dma_addr1, hdr_room);
-
- /* flush desc with pa dma_addr */
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr0);
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr1);
- }
-#else
- struct rte_mbuf *mb0, *mb1, *mb2, *mb3;
- __m256i dma_addr0_1, dma_addr2_3;
- __m256i hdr_room = _mm256_set1_epi64x(RTE_PKTMBUF_HEADROOM);
- /* Initialize the mbufs in vector, process 4 mbufs in one loop */
- for (i = 0; i < IAVF_RXQ_REARM_THRESH;
- i += 4, rxp += 4, rxdp += 4) {
- __m128i vaddr0, vaddr1, vaddr2, vaddr3;
- __m256i vaddr0_1, vaddr2_3;
-
- mb0 = rxp[0];
- mb1 = rxp[1];
- mb2 = rxp[2];
- mb3 = rxp[3];
-
- /* load buf_addr(lo 64bit) and buf_iova(hi 64bit) */
- RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, buf_iova) !=
- offsetof(struct rte_mbuf, buf_addr) + 8);
- vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr);
- vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr);
- vaddr2 = _mm_loadu_si128((__m128i *)&mb2->buf_addr);
- vaddr3 = _mm_loadu_si128((__m128i *)&mb3->buf_addr);
-
- /**
-* merge 0 & 1, by casting 0 to 256-bit and inserting 1
-* into the high lanes. Similarly for 2 & 3
-*/
- vaddr0_1 =
- _mm256_inserti128_si256(_mm256_castsi128_si256(vaddr0),
- vaddr1, 1);
- vaddr2_3 =
- _mm256_inserti128_si256(_mm256_castsi128_si256(vaddr2),
- vaddr3, 1);
-
- /* convert pa to dma_addr hdr/data */
- dma_addr0_1 = _mm256_unpackhi_epi64(vaddr0_1, vad
[dpdk-dev] [PATCH v3 2/3] net/ice: fix segment fault in AVX512
Fix segment fault when failing to get the memory from the pool.
Fixes: 7f85d5ebcfe1 ("net/ice: add AVX512 vector path")
Cc: sta...@dpdk.org
Reported-by: David Coyle
Signed-off-by: Wenzhuo Lu
---
drivers/net/ice/ice_rxtx_vec_avx2.c | 120 +---
drivers/net/ice/ice_rxtx_vec_avx512.c | 5 +-
drivers/net/ice/ice_rxtx_vec_common.h | 203 ++
3 files changed, 209 insertions(+), 119 deletions(-)
diff --git a/drivers/net/ice/ice_rxtx_vec_avx2.c
b/drivers/net/ice/ice_rxtx_vec_avx2.c
index 1cc5490..8d3cf3e 100644
--- a/drivers/net/ice/ice_rxtx_vec_avx2.c
+++ b/drivers/net/ice/ice_rxtx_vec_avx2.c
@@ -10,126 +10,10 @@
#pragma GCC diagnostic ignored "-Wcast-qual"
#endif
-static inline void
+static __rte_always_inline void
ice_rxq_rearm(struct ice_rx_queue *rxq)
{
- int i;
- uint16_t rx_id;
- volatile union ice_rx_flex_desc *rxdp;
- struct ice_rx_entry *rxep = &rxq->sw_ring[rxq->rxrearm_start];
-
- rxdp = rxq->rx_ring + rxq->rxrearm_start;
-
- /* Pull 'n' more MBUFs into the software ring */
- if (rte_mempool_get_bulk(rxq->mp,
-(void *)rxep,
-ICE_RXQ_REARM_THRESH) < 0) {
- if (rxq->rxrearm_nb + ICE_RXQ_REARM_THRESH >=
- rxq->nb_rx_desc) {
- __m128i dma_addr0;
-
- dma_addr0 = _mm_setzero_si128();
- for (i = 0; i < ICE_DESCS_PER_LOOP; i++) {
- rxep[i].mbuf = &rxq->fake_mbuf;
- _mm_store_si128((__m128i *)&rxdp[i].read,
- dma_addr0);
- }
- }
- rte_eth_devices[rxq->port_id].data->rx_mbuf_alloc_failed +=
- ICE_RXQ_REARM_THRESH;
- return;
- }
-
-#ifndef RTE_LIBRTE_ICE_16BYTE_RX_DESC
- struct rte_mbuf *mb0, *mb1;
- __m128i dma_addr0, dma_addr1;
- __m128i hdr_room = _mm_set_epi64x(RTE_PKTMBUF_HEADROOM,
- RTE_PKTMBUF_HEADROOM);
- /* Initialize the mbufs in vector, process 2 mbufs in one loop */
- for (i = 0; i < ICE_RXQ_REARM_THRESH; i += 2, rxep += 2) {
- __m128i vaddr0, vaddr1;
-
- mb0 = rxep[0].mbuf;
- mb1 = rxep[1].mbuf;
-
- /* load buf_addr(lo 64bit) and buf_iova(hi 64bit) */
- RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, buf_iova) !=
- offsetof(struct rte_mbuf, buf_addr) + 8);
- vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr);
- vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr);
-
- /* convert pa to dma_addr hdr/data */
- dma_addr0 = _mm_unpackhi_epi64(vaddr0, vaddr0);
- dma_addr1 = _mm_unpackhi_epi64(vaddr1, vaddr1);
-
- /* add headroom to pa values */
- dma_addr0 = _mm_add_epi64(dma_addr0, hdr_room);
- dma_addr1 = _mm_add_epi64(dma_addr1, hdr_room);
-
- /* flush desc with pa dma_addr */
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr0);
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr1);
- }
-#else
- struct rte_mbuf *mb0, *mb1, *mb2, *mb3;
- __m256i dma_addr0_1, dma_addr2_3;
- __m256i hdr_room = _mm256_set1_epi64x(RTE_PKTMBUF_HEADROOM);
- /* Initialize the mbufs in vector, process 4 mbufs in one loop */
- for (i = 0; i < ICE_RXQ_REARM_THRESH;
- i += 4, rxep += 4, rxdp += 4) {
- __m128i vaddr0, vaddr1, vaddr2, vaddr3;
- __m256i vaddr0_1, vaddr2_3;
-
- mb0 = rxep[0].mbuf;
- mb1 = rxep[1].mbuf;
- mb2 = rxep[2].mbuf;
- mb3 = rxep[3].mbuf;
-
- /* load buf_addr(lo 64bit) and buf_iova(hi 64bit) */
- RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, buf_iova) !=
- offsetof(struct rte_mbuf, buf_addr) + 8);
- vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr);
- vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr);
- vaddr2 = _mm_loadu_si128((__m128i *)&mb2->buf_addr);
- vaddr3 = _mm_loadu_si128((__m128i *)&mb3->buf_addr);
-
- /**
-* merge 0 & 1, by casting 0 to 256-bit and inserting 1
-* into the high lanes. Similarly for 2 & 3
-*/
- vaddr0_1 =
- _mm256_inserti128_si256(_mm256_castsi128_si256(vaddr0),
- vaddr1, 1);
- vaddr2_3 =
- _mm256_inserti128_si256(_mm256_castsi128_si256(vaddr2),
- vaddr3, 1);
-
- /* convert pa to dma_addr hdr/data */
- dma_addr0_1 = _mm256_unpack
[dpdk-dev] [PATCH v3 3/3] net/i40e: fix segment fault in AVX512
Fix segment fault when failing to get the memory from the pool.
Fixes: e6a6a138919f ("net/i40e: add AVX512 vector path")
Cc: sta...@dpdk.org
Reported-by: David Coyle
Signed-off-by: Wenzhuo Lu
---
drivers/net/i40e/i40e_rxtx_vec_avx2.c | 117 +--
drivers/net/i40e/i40e_rxtx_vec_avx512.c | 5 +-
drivers/net/i40e/i40e_rxtx_vec_common.h | 201
3 files changed, 207 insertions(+), 116 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx_vec_avx2.c
b/drivers/net/i40e/i40e_rxtx_vec_avx2.c
index 15abd9d..133e2fb 100644
--- a/drivers/net/i40e/i40e_rxtx_vec_avx2.c
+++ b/drivers/net/i40e/i40e_rxtx_vec_avx2.c
@@ -18,123 +18,10 @@
#pragma GCC diagnostic ignored "-Wcast-qual"
#endif
-static inline void
+static __rte_always_inline void
i40e_rxq_rearm(struct i40e_rx_queue *rxq)
{
- int i;
- uint16_t rx_id;
- volatile union i40e_rx_desc *rxdp;
- struct i40e_rx_entry *rxep = &rxq->sw_ring[rxq->rxrearm_start];
-
- rxdp = rxq->rx_ring + rxq->rxrearm_start;
-
- /* Pull 'n' more MBUFs into the software ring */
- if (rte_mempool_get_bulk(rxq->mp,
-(void *)rxep,
-RTE_I40E_RXQ_REARM_THRESH) < 0) {
- if (rxq->rxrearm_nb + RTE_I40E_RXQ_REARM_THRESH >=
- rxq->nb_rx_desc) {
- __m128i dma_addr0;
- dma_addr0 = _mm_setzero_si128();
- for (i = 0; i < RTE_I40E_DESCS_PER_LOOP; i++) {
- rxep[i].mbuf = &rxq->fake_mbuf;
- _mm_store_si128((__m128i *)&rxdp[i].read,
- dma_addr0);
- }
- }
- rte_eth_devices[rxq->port_id].data->rx_mbuf_alloc_failed +=
- RTE_I40E_RXQ_REARM_THRESH;
- return;
- }
-
-#ifndef RTE_LIBRTE_I40E_16BYTE_RX_DESC
- struct rte_mbuf *mb0, *mb1;
- __m128i dma_addr0, dma_addr1;
- __m128i hdr_room = _mm_set_epi64x(RTE_PKTMBUF_HEADROOM,
- RTE_PKTMBUF_HEADROOM);
- /* Initialize the mbufs in vector, process 2 mbufs in one loop */
- for (i = 0; i < RTE_I40E_RXQ_REARM_THRESH; i += 2, rxep += 2) {
- __m128i vaddr0, vaddr1;
-
- mb0 = rxep[0].mbuf;
- mb1 = rxep[1].mbuf;
-
- /* load buf_addr(lo 64bit) and buf_iova(hi 64bit) */
- RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, buf_iova) !=
- offsetof(struct rte_mbuf, buf_addr) + 8);
- vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr);
- vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr);
-
- /* convert pa to dma_addr hdr/data */
- dma_addr0 = _mm_unpackhi_epi64(vaddr0, vaddr0);
- dma_addr1 = _mm_unpackhi_epi64(vaddr1, vaddr1);
-
- /* add headroom to pa values */
- dma_addr0 = _mm_add_epi64(dma_addr0, hdr_room);
- dma_addr1 = _mm_add_epi64(dma_addr1, hdr_room);
-
- /* flush desc with pa dma_addr */
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr0);
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr1);
- }
-#else
- struct rte_mbuf *mb0, *mb1, *mb2, *mb3;
- __m256i dma_addr0_1, dma_addr2_3;
- __m256i hdr_room = _mm256_set1_epi64x(RTE_PKTMBUF_HEADROOM);
- /* Initialize the mbufs in vector, process 4 mbufs in one loop */
- for (i = 0; i < RTE_I40E_RXQ_REARM_THRESH;
- i += 4, rxep += 4, rxdp += 4) {
- __m128i vaddr0, vaddr1, vaddr2, vaddr3;
- __m256i vaddr0_1, vaddr2_3;
-
- mb0 = rxep[0].mbuf;
- mb1 = rxep[1].mbuf;
- mb2 = rxep[2].mbuf;
- mb3 = rxep[3].mbuf;
-
- /* load buf_addr(lo 64bit) and buf_iova(hi 64bit) */
- RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, buf_iova) !=
- offsetof(struct rte_mbuf, buf_addr) + 8);
- vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr);
- vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr);
- vaddr2 = _mm_loadu_si128((__m128i *)&mb2->buf_addr);
- vaddr3 = _mm_loadu_si128((__m128i *)&mb3->buf_addr);
-
- /*
-* merge 0 & 1, by casting 0 to 256-bit and inserting 1
-* into the high lanes. Similarly for 2 & 3
-*/
- vaddr0_1 = _mm256_inserti128_si256(
- _mm256_castsi128_si256(vaddr0), vaddr1, 1);
- vaddr2_3 = _mm256_inserti128_si256(
- _mm256_castsi128_si256(vaddr2), vaddr3, 1);
-
- /* convert pa to dma_addr hdr/data */
- dma_addr0_1 = _mm256_unpackhi_epi64(vaddr0_1, vaddr0_1);
-
Re: [dpdk-dev] [PATCH v8] app/testpmd: support multi-process
在 2021/3/30 10:17, Li, Xiaoyun 写道: Hi -Original Message- From: Min Hu (Connor) Sent: Tuesday, March 30, 2021 09:48 To: dev@dpdk.org Cc: Yigit, Ferruh ; ajit.khapa...@broadcom.com; Li, Xiaoyun Subject: [PATCH v8] app/testpmd: support multi-process From: Lijun Ou This patch adds multi-process support for testpmd. The test cmd example as follows: the primary cmd: ./dpdk-testpmd -a xxx --proc-type=auto -l 0-1 -- -i \ --rxq=4 --txq=4 --num-procs=2 --proc-id=0 the secondary cmd: ./dpdk-testpmd -a xxx --proc-type=auto -l 2-3 -- -i \ --rxq=4 --txq=4 --num-procs=2 --proc-id=1 Signed-off-by: Min Hu (Connor) Signed-off-by: Lijun Ou --- v8: * Added warning info about queue numbers and process numbers. v7: * Fixed compiling error for unexpected unindent. v6: * Add rte flow description for multiple process. v5: * Fixed run_app.rst for multiple process description. * Fix compiling error. v4: * Fixed minimum vlaue of Rxq or Txq in doc. v3: * Fixed compiling error using gcc10.0. v2: * Added document for this patch. --- app/test-pmd/cmdline.c| 12 +++- app/test-pmd/config.c | 14 +++- app/test-pmd/parameters.c | 11 +++ app/test-pmd/testpmd.c| 127 ++ app/test-pmd/testpmd.h| 7 ++ doc/guides/testpmd_app_ug/run_app.rst | 101 +++ 6 files changed, 226 insertions(+), 46 deletions(-) 2.7.4 Many commands shouldn't be allowed but now only have a brief guide in doc. This can be done in the future I think. Overall, it looks good to me. Thanks xiaoyun. You are right, Maybe there are more things to do about supporting multiple process for testpmd. We will perfect it continuously in future. Acked-by: Xiaoyun Li
[dpdk-dev] [PATCH v5] build: alias default build as generic
The current machine='default' build name is not descriptive. The actual
default build is machine='native'. Add an alternative string which does
the same build and better describes what we're building:
machine='generic'. Leave machine='default' for backwards compatibility.
Signed-off-by: Juraj Linkeš
Reviewed-by: Honnappa Nagarahalli
Acked-by: Bruce Richardson
---
.ci/linux-build.sh| 2 +-
config/arm/meson.build| 7 ---
config/meson.build| 13 +++--
devtools/test-meson-builds.sh | 14 +++---
doc/guides/prog_guide/build-sdk-meson.rst | 4 ++--
meson_options.txt | 2 +-
6 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 91e43a975b..3cbeb193a1 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -77,7 +77,7 @@ else
OPTS="$OPTS -Dexamples=all"
fi
-OPTS="$OPTS -Dmachine=default"
+OPTS="$OPTS -Dmachine=generic"
OPTS="$OPTS --default-library=$DEF_LIB"
OPTS="$OPTS --buildtype=debugoptimized"
OPTS="$OPTS -Dcheck_includes=true"
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 00bc4610a3..aaed89bd5b 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation.
# Copyright(c) 2017 Cavium, Inc
+# Copyright(c) 2021 PANTHEON.tech s.r.o.
# common flags to all aarch64 builds, with lowest priority
flags_common = [
@@ -208,8 +209,8 @@ if dpdk_conf.get('RTE_ARCH_32')
else
# aarch64 build
if not meson.is_cross_build()
- if machine == 'default'
- # default build
+ if machine == 'generic'
+ # generic build
implementer_id = 'generic'
part_number = 'generic'
else
@@ -256,7 +257,7 @@ else
'(-Dmachine=generic) build.')
endif
- # use default flags with implementer flags
+ # use common flags with implementer flags
dpdk_flags = flags_common + implementer_config['flags'] +
part_number_config.get('flags', [])
# apply supported machine args
diff --git a/config/meson.build b/config/meson.build
index 66a2edcc47..3268cf6804 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -70,21 +70,22 @@ else
machine = get_option('machine')
endif
-# machine type 'default' is special, it defaults to the per arch agreed common
-# minimal baseline needed for DPDK.
+# machine type 'generic' is special, it selects the per arch agreed common
+# minimal baseline needed for DPDK. Machine type 'default' is also supported
+# with the same meaning for backwards compatibility.
# That might not be the most optimized, but the most portable version while
# still being able to support the CPU features required for DPDK.
# This can be bumped up by the DPDK project, but it can never be an
# invariant like 'native'
-if machine == 'default'
+if machine == 'default' or machine == 'generic'
if host_machine.cpu_family().startswith('x86')
- # matches the old pre-meson build systems default
+ # matches the old pre-meson build systems generic machine
machine = 'corei7'
elif host_machine.cpu_family().startswith('arm')
machine = 'armv7-a'
elif host_machine.cpu_family().startswith('aarch')
- # arm64 manages defaults in config/arm/meson.build
- machine = 'default'
+ # arm64 manages generic config in config/arm/meson.build
+ machine = 'generic'
elif host_machine.cpu_family().startswith('ppc')
machine = 'power8'
endif
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index c11ae87e0d..daf817ac3e 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -223,12 +223,12 @@ done
# test compilation with minimal x86 instruction set
# Set the install path for libraries to "lib" explicitly to prevent problems
# with pkg-config prefixes if installed in "lib/x86_64-linux-gnu" later.
-default_machine='nehalem'
-if ! check_cc_flags "-march=$default_machine" ; then
- default_machine='corei7'
+generic_machine='nehalem'
+if ! check_cc_flags "-march=$generic_machine" ; then
+ generic_machine='corei7'
fi
-build build-x86-default cc skipABI -Dcheck_includes=true \
- -Dlibdir=lib -Dmachine=$default_machine $use_shared
+build build-x86-generic cc skipABI -Dcheck_includes=true \
+ -Dlibdir=lib -Dmachine=$generic_machine $use_shared
# 32-bit with default compiler
if check_cc_flags '-m32' ; then
@@ -271,10 +271,10 @@ for f in $srcdir/config/ppc/ppc* ; do
build $targetdir $f ABI $use_shared
done
-# Test installation of the x86-default target, to be used for checking
+# Test installation o
Re: [dpdk-dev] [PATCH v8] app/testpmd: support multi-process
在 2021/3/30 11:11, Ajit Khaparde 写道: On Mon, Mar 29, 2021 at 6:48 PM Min Hu (Connor) wrote: From: Lijun Ou This patch adds multi-process support for testpmd. The test cmd example as follows: the primary cmd: ./dpdk-testpmd -a xxx --proc-type=auto -l 0-1 -- -i \ --rxq=4 --txq=4 --num-procs=2 --proc-id=0 the secondary cmd: ./dpdk-testpmd -a xxx --proc-type=auto -l 2-3 -- -i \ --rxq=4 --txq=4 --num-procs=2 --proc-id=1 Signed-off-by: Min Hu (Connor) Signed-off-by: Lijun Ou Some minor nits below. Otherwise looks fine to me. Acked-by: Ajit Khaparde Thanks Ajit. Hi, Ferruh, Should I send v9 to fix the grammar bugs in doc which Ajit point out or fix it in future? --- v8: * Added warning info about queue numbers and process numbers. :::snip +* ``--rxq=N`` + +Set the number of Rx queues per port to N. N is the sum of queues used by primary +and secondary process. Primary process and secondary process should have separate +queues, and each should occupy at least one queue. Where N should be the multiple +of number of processes. of the number of processes. + +* ``--txq=N`` + +Set the number of Tx queues per port to N. N is the sum of queues used by primary +and secondary process. Primary process and secondary process should have separate +queues, and each should occupy at least one queue. Where N should be the multiple +of number of processes. of the number of processes. + +* ``--num-procs=N`` + +The number of processes which will be used. + snip +The number of rings should be a multiple of the number of processes. If not, +redundant queues will exist after queues are allocated to processes. After RSS is +enabled, packet loss occurs when traffic is sent to all processes at the same time. +Some traffic enters redundant queues and cannot be forwarded. + +Most dev ops is supported in primary and secondary process. While secondary process Most dev ops are supported in the primary and secondary process. While +is not permitted to allocate or release shared memory, so some ops are not supported +as follows: +``dev_configure`` +``dev_start`` +``dev_stop`` +``rx_queue_setup`` +``tx_queue_setup`` +``rx_queue_release`` +``tx_queue_release`` snip:::
Re: [dpdk-dev] Questions about reporting auto-negotiation capability
29/03/2021 06:02, Huisong Li: > Hi, all > > 'speed_capa' in struct rte_eth_dev_info is defined as follows: > > uint32_t speed_capa; /**< Supported speeds bitmap (ETH_LINK_SPEED_). */ > > >Most PMD drivers use this field to report the speeds capability > supported by the device to the upper-layer app. > > But it seems that few NICs report their auto-negotiation capability > through this field. If NIC also uses it to report > > their auto-negotiation capability through this field, and should set it > to ETH_LINK_SPEED_AUTONEG(0) based on > > the definition of ETH_LINK_SPEED_xxx. In this case, it conflicts the > report of the speeds capability . > > > I don't know how to correctly report the auto-negotiation capability of > the device. Thanks for your reply. ETH_LINK_SPEED_AUTONEG is not for capabilities. Anyway, if it is set, it changes nothing (0) in the bitmap. I see mlx5 is wrongly using it. speed_capa is only for enumerating speeds.
Re: [dpdk-dev] [PATCH v2] app/testpmd: fix Tx/Rx descriptor query error log
Hi
> -Original Message-
> From: Min Hu (Connor)
> Sent: Monday, March 29, 2021 14:47
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Li, Xiaoyun
> Subject: [PATCH v2] app/testpmd: fix Tx/Rx descriptor query error log
>
> From: Hongbo Zheng
>
> This patch adds more err info for Tx/Rx descriptor query command.
>
> Fixes: fae9aa717d6c ("app/testpmd: support checking descriptor status")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Hongbo Zheng
> Signed-off-by: Min Hu (Connor)
> ---
> v2:
> * Fixed error log info and simply the commit info.
> ---
> app/test-pmd/cmdline.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> 14110eb..f44116b 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -16629,7 +16629,8 @@ cmd_show_rx_tx_desc_status_parsed(void
> *parsed_result,
> rc = rte_eth_rx_descriptor_status(res->cmd_pid, res-
> >cmd_qid,
>res->cmd_did);
> if (rc < 0) {
> - printf("Invalid queueid = %d\n", res->cmd_qid);
> + printf("Invalid input: queue id = %d, desc id = %d\n",
> +res->cmd_qid, res->cmd_did);
> return;
> }
> if (rc == RTE_ETH_RX_DESC_AVAIL)
> @@ -16642,7 +16643,8 @@ cmd_show_rx_tx_desc_status_parsed(void
> *parsed_result,
> rc = rte_eth_tx_descriptor_status(res->cmd_pid, res-
> >cmd_qid,
>res->cmd_did);
> if (rc < 0) {
> - printf("Invalid queueid = %d\n", res->cmd_qid);
> + printf("Invalid input: queue id = %d, desc id = %d\n",
> +res->cmd_qid, res->cmd_did);
> return;
> }
> if (rc == RTE_ETH_TX_DESC_FULL)
> --
> 2.7.4
Acked-by: Xiaoyun Li
Re: [dpdk-dev] Questions about reporting auto-negotiation capability
29/03/2021 09:03, Thomas Monjalon: > 29/03/2021 06:02, Huisong Li: > > 'speed_capa' in struct rte_eth_dev_info is defined as follows: > > > > uint32_t speed_capa; /**< Supported speeds bitmap (ETH_LINK_SPEED_). */ > > > > > >Most PMD drivers use this field to report the speeds capability > > supported by the device to the upper-layer app. > > > > But it seems that few NICs report their auto-negotiation capability > > through this field. If NIC also uses it to report > > their auto-negotiation capability through this field, and should set it > > to ETH_LINK_SPEED_AUTONEG(0) based on > > the definition of ETH_LINK_SPEED_xxx. In this case, it conflicts the > > report of the speeds capability . > > > > I don't know how to correctly report the auto-negotiation capability of > > the device. Thanks for your reply. > > ETH_LINK_SPEED_AUTONEG is not for capabilities. > Anyway, if it is set, it changes nothing (0) in the bitmap. > I see mlx5 is wrongly using it. > > speed_capa is only for enumerating speeds. I see some drivers are advertising ETH_LINK_SPEED_FIXED in speed_capa if the device cannot support autonegotiation. Should we add a note in doxygen?
[dpdk-dev] [PATCH] net/ixgbe: fix RSS RETA be reset after port start
If one calls ‘rte_eth_dev_rss_reta_update’ with ixgbe before starting
the device (but after setting everything else), then RSS RETA
configuration be zero after starting the device.
This patch gives a notification if the port not started.
Bugzilla ID: 664
Fixes: 249358424eab ("ixgbe: RSS RETA configuration")
Signed-off-by: Murphy Yang
---
drivers/net/ixgbe/ixgbe_ethdev.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 8a9a21e7c2..41068fe646 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -5015,11 +5015,19 @@ ixgbe_dev_rss_reta_update(struct rte_eth_dev *dev,
uint32_t reta, r;
uint16_t idx, shift;
struct ixgbe_adapter *adapter = dev->data->dev_private;
+ struct rte_eth_dev_data *dev_data = dev->data;
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
uint32_t reta_reg;
PMD_INIT_FUNC_TRACE();
+ if (!dev_data->dev_started) {
+ PMD_DRV_LOG(ERR,
+ "port %d must be started before configuration",
+dev_data->port_id);
+ return -EBUSY;
+ }
+
if (!ixgbe_rss_update_sp(hw->mac.type)) {
PMD_DRV_LOG(ERR, "RSS reta update is not supported on this "
"NIC.");
--
2.17.1
[dpdk-dev] [PATCH] drivers/net: remove useless autoneg capability
The flag ETH_LINK_SPEED_AUTONEG is 0, so it cannot be used in a capability bitmap. Having 0 in speed capability means all speeds are accepted. Signed-off-by: Thomas Monjalon --- drivers/net/bnxt/bnxt_ethdev.c | 2 -- drivers/net/mlx5/linux/mlx5_ethdev_os.c | 4 2 files changed, 6 deletions(-) diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c index f1dd40591f..a2debdbb64 100644 --- a/drivers/net/bnxt/bnxt_ethdev.c +++ b/drivers/net/bnxt/bnxt_ethdev.c @@ -889,8 +889,6 @@ uint32_t bnxt_get_speed_capabilities(struct bnxt *bp) if (bp->link_info->auto_mode == HWRM_PORT_PHY_QCFG_OUTPUT_AUTO_MODE_NONE) speed_capa |= ETH_LINK_SPEED_FIXED; - else - speed_capa |= ETH_LINK_SPEED_AUTONEG; return speed_capa; } diff --git a/drivers/net/mlx5/linux/mlx5_ethdev_os.c b/drivers/net/mlx5/linux/mlx5_ethdev_os.c index 0e8de9439e..58d56913ae 100644 --- a/drivers/net/mlx5/linux/mlx5_ethdev_os.c +++ b/drivers/net/mlx5/linux/mlx5_ethdev_os.c @@ -409,8 +409,6 @@ mlx5_link_update_unlocked_gset(struct rte_eth_dev *dev, else dev_link.link_speed = link_speed; priv->link_speed_capa = 0; - if (edata.supported & SUPPORTED_Autoneg) - priv->link_speed_capa |= ETH_LINK_SPEED_AUTONEG; if (edata.supported & (SUPPORTED_1000baseT_Full | SUPPORTED_1000baseKX_Full)) priv->link_speed_capa |= ETH_LINK_SPEED_1G; @@ -517,8 +515,6 @@ mlx5_link_update_unlocked_gs(struct rte_eth_dev *dev, sc = ecmd->link_mode_masks[0] | ((uint64_t)ecmd->link_mode_masks[1] << 32); priv->link_speed_capa = 0; - if (sc & MLX5_BITSHIFT(ETHTOOL_LINK_MODE_Autoneg_BIT)) - priv->link_speed_capa |= ETH_LINK_SPEED_AUTONEG; if (sc & (MLX5_BITSHIFT(ETHTOOL_LINK_MODE_1000baseT_Full_BIT) | MLX5_BITSHIFT(ETHTOOL_LINK_MODE_1000baseKX_Full_BIT))) priv->link_speed_capa |= ETH_LINK_SPEED_1G; -- 2.30.1
Re: [dpdk-dev] [PATCH v1 5/6] raw/ioat: add api to query remaining ring space
Tested-by: Sunil Pai G
Re: [dpdk-dev] [PATCH v7] app/testpmd: support multi-process
Hi
> -Original Message-
> From: Min Hu (Connor)
> Sent: Friday, March 26, 2021 16:53
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; ajit.khapa...@broadcom.com; Li,
> Xiaoyun
> Subject: [PATCH v7] app/testpmd: support multi-process
>
> From: Lijun Ou
>
> This patch adds multi-process support for testpmd.
> The test cmd example as follows:
> the primary cmd:
> ./dpdk-testpmd -a xxx --proc-type=auto -l 0-1 -- -i \
> --rxq=4 --txq=4 --num-procs=2 --proc-id=0
>
> the secondary cmd:
> ./dpdk-testpmd -a xxx --proc-type=auto -l 2-3 -- -i \
> --rxq=4 --txq=4 --num-procs=2 --proc-id=1
>
> Signed-off-by: Min Hu (Connor)
> Signed-off-by: Lijun Ou
> ---
> v7:
> * Fixed compiling error for unexpected unindent.
>
> v6:
> * Add rte flow description for multiple process.
>
> v5:
> * Fixed run_app.rst for multiple process description.
> * Fix compiling error.
>
> v4:
> * Fixed minimum vlaue of Rxq or Txq in doc.
>
> v3:
> * Fixed compiling error using gcc10.0.
>
> v2:
> * Added document for this patch.
> ---
> app/test-pmd/cmdline.c| 12 +++-
> app/test-pmd/config.c | 9 ++-
> app/test-pmd/parameters.c | 11 +++
> app/test-pmd/testpmd.c| 127
> ++
> app/test-pmd/testpmd.h| 7 ++
> doc/guides/testpmd_app_ug/run_app.rst | 99 ++
> 6 files changed, 219 insertions(+), 46 deletions(-)
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> 14110eb..287d7a0 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -71,8 +71,6 @@
Why not just restrict queue numbers to be multiple of processes here in
rss_fwd_config_setup()?
Or at least print a warning to tell users if it's not multiple, packet loss
will happen.
> setup_fwd_config_of_each_lcore(&cur_fwd_config);
> - rxp = 0; rxq = 0;
> + start = proc_id * nb_q / num_procs;
> + end = start + nb_q / num_procs;
> + rxp = 0;
> + rxq = start;
> for (sm_id = 0; sm_id < cur_fwd_config.nb_fwd_streams; sm_id++) {
> struct fwd_stream *fs;
>
> @@ -2861,6 +2866,8 @@ rss_fwd_config_setup(void)
> continue;
> rxp = 0;
> rxq++;
> + if (rxq >= end)
> + rxq = start;
> }
> }
>
> +* ``--txq=N``
> +
> +Set the number of Tx queues per port to N. N is the sum of queues used by
> primary
> +and secondary process. As primary process and secondary process should
> have separate
> +queues, and each should occupy at least one queue.where N should be no
> less than two.
Where N should be the multiple of number of processes.
BRs
Xiaoyun
> +
> 2.7.4
Re: [dpdk-dev] [PATCH] net/ixgbe: fix RSS RETA be reset after port start
> -Original Message-
> From: Yang, MurphyX
> Sent: Monday, March 29, 2021 15:20
> To: dev@dpdk.org
> Cc: Yang, Qiming ; Wang, Haiyue
> ; Guo, Jia
> ; Yang, SteveX ; Zhang, RobinX
> ;
> Yang, MurphyX
> Subject: [PATCH] net/ixgbe: fix RSS RETA be reset after port start
>
> If one calls ‘rte_eth_dev_rss_reta_update’ with ixgbe before starting
> the device (but after setting everything else), then RSS RETA
> configuration be zero after starting the device.
>
> This patch gives a notification if the port not started.
>
> Bugzilla ID: 664
> Fixes: 249358424eab ("ixgbe: RSS RETA configuration")
>
> Signed-off-by: Murphy Yang
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 8a9a21e7c2..41068fe646 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -5015,11 +5015,19 @@ ixgbe_dev_rss_reta_update(struct rte_eth_dev *dev,
> uint32_t reta, r;
> uint16_t idx, shift;
> struct ixgbe_adapter *adapter = dev->data->dev_private;
> + struct rte_eth_dev_data *dev_data = dev->data;
> struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> uint32_t reta_reg;
>
> PMD_INIT_FUNC_TRACE();
>
> + if (!dev_data->dev_started) {
> + PMD_DRV_LOG(ERR,
> + "port %d must be started before configuration",
> + dev_data->port_id);
> + return -EBUSY;
-EIO is better ? Since no started, no busy at all. ;-)
> --
> 2.17.1
Re: [dpdk-dev] [PATCH 0/2] adjusting mkey creations
Hi, > -Original Message- > From: Raslan Darawsheh > Sent: Thursday, March 25, 2021 10:53 AM > To: Michael Baum ; dev@dpdk.org > Cc: Matan Azrad ; Slava Ovsiienko > > Subject: RE: [PATCH 0/2] adjusting mkey creations > > Hi, > > > -Original Message- > > From: Michael Baum > > Sent: Thursday, March 18, 2021 11:56 AM > > To: dev@dpdk.org > > Cc: Matan Azrad ; Raslan Darawsheh > > ; Slava Ovsiienko > > Subject: [PATCH 0/2] adjusting mkey creations > > > > Adjusting mkey creations to use Verbs instead of DevX API. > > > > Michael Baum (2): > > net/mlx5: workaround ASO memory region creation > > net/mlx5: workaround counter memory region creation > > > > drivers/common/mlx5/linux/mlx5_common_verbs.c | 1 - > > drivers/common/mlx5/windows/mlx5_common_os.c | 23 +++--- > > drivers/net/mlx5/linux/mlx5_os.c | 10 --- > > drivers/net/mlx5/mlx5.c | 11 ++- > > drivers/net/mlx5/mlx5.h | 15 +--- > > drivers/net/mlx5/mlx5_flow.c | 27 ++- > > drivers/net/mlx5/mlx5_flow_age.c | 106 > > +++--- > > drivers/net/mlx5/windows/mlx5_os.c| 9 --- > > 8 files changed, 71 insertions(+), 131 deletions(-) > > > > -- > > 1.8.3.1 > > Series applied to next-net-mlx, > > Kindest regards, > Raslan Darawsheh Due to some regression which was found in these patches series we'll remove them from next-net-mlx, to have another version which has the fix for this issue. Kindest regards, Raslan Darawsheh
[dpdk-dev] [PATCH v2] net/ixgbe: fix RSS RETA be reset after port start
If one calls ‘rte_eth_dev_rss_reta_update’ with ixgbe before starting
the device (but after setting everything else), then RSS RETA
configuration be zero after starting the device.
This patch gives a notification if the port not started.
Bugzilla ID: 664
Fixes: 249358424eab ("ixgbe: RSS RETA configuration")
Signed-off-by: Murphy Yang
---
v2:
- tune the return value
drivers/net/ixgbe/ixgbe_ethdev.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 8a9a21e7c2..6aebf9c11e 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -5015,11 +5015,19 @@ ixgbe_dev_rss_reta_update(struct rte_eth_dev *dev,
uint32_t reta, r;
uint16_t idx, shift;
struct ixgbe_adapter *adapter = dev->data->dev_private;
+ struct rte_eth_dev_data *dev_data = dev->data;
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
uint32_t reta_reg;
PMD_INIT_FUNC_TRACE();
+ if (!dev_data->dev_started) {
+ PMD_DRV_LOG(ERR,
+ "port %d must be started before configuration",
+dev_data->port_id);
+ return -EIO;
+ }
+
if (!ixgbe_rss_update_sp(hw->mac.type)) {
PMD_DRV_LOG(ERR, "RSS reta update is not supported on this "
"NIC.");
--
2.17.1
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix RSS RETA be reset after port start
> -Original Message-
> From: Murphy Yang
> Sent: Monday, March 29, 2021 16:11
> To: dev@dpdk.org
> Cc: Yang, Qiming ; Wang, Haiyue
> ; Guo, Jia
> ; Yang, SteveX ; Zhang, RobinX
> ;
> Yang, MurphyX
> Subject: [PATCH v2] net/ixgbe: fix RSS RETA be reset after port start
>
> If one calls ‘rte_eth_dev_rss_reta_update’ with ixgbe before starting
> the device (but after setting everything else), then RSS RETA
> configuration be zero after starting the device.
>
> This patch gives a notification if the port not started.
>
> Bugzilla ID: 664
> Fixes: 249358424eab ("ixgbe: RSS RETA configuration")
>
> Signed-off-by: Murphy Yang
> ---
> v2:
> - tune the return value
>
> drivers/net/ixgbe/ixgbe_ethdev.c | 8
> 1 file changed, 8 insertions(+)
Acked-by: Haiyue Wang
> --
> 2.17.1
[dpdk-dev] [PATCH v3] net/ixgbe: fix RSS RETA be reset after port start
If one calls ‘rte_eth_dev_rss_reta_update’ with ixgbe before starting
the device (but after setting everything else), then RSS RETA
configuration be zero after starting the device.
This patch gives a notification if the port not started.
Bugzilla ID: 664
Fixes: 249358424eab ("ixgbe: RSS RETA configuration")
Signed-off-by: Murphy Yang
---
v3:
- modify the notify message
v2:
- tune the return value
drivers/net/ixgbe/ixgbe_ethdev.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 8a9a21e7c2..d8ef618e5f 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -5015,11 +5015,19 @@ ixgbe_dev_rss_reta_update(struct rte_eth_dev *dev,
uint32_t reta, r;
uint16_t idx, shift;
struct ixgbe_adapter *adapter = dev->data->dev_private;
+ struct rte_eth_dev_data *dev_data = dev->data;
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
uint32_t reta_reg;
PMD_INIT_FUNC_TRACE();
+ if (!dev_data->dev_started) {
+ PMD_DRV_LOG(ERR,
+ "port %d must be started before rss reta update",
+dev_data->port_id);
+ return -EIO;
+ }
+
if (!ixgbe_rss_update_sp(hw->mac.type)) {
PMD_DRV_LOG(ERR, "RSS reta update is not supported on this "
"NIC.");
--
2.17.1
Re: [dpdk-dev] [PATCH] ethdev: update qfi definition
Hi
> -Original Message-
> From: dev On Behalf Of Ferruh Yigit
> Subject: Re: [dpdk-dev] [PATCH] ethdev: update qfi definition
>
> On 3/23/2021 12:11 PM, Raslan Darawsheh wrote:
> > qfi field is 8 bits which represent single bit for
> > PPP (paging Policy Presence) single bit for RQI
> > (Reflective QoS Indicator) and 6 bits for qfi
> > (QoS Flow Identifier)
>
> Can you please put a reference for above information?
> >
> > This update the doxygen format and the mask for qfi
> > to properly identify the full 8 bits of the field.
> >
> > note: changing the default mask would cause different
> > patterns generated by testpmd.
> >
> > Fixes: 346553db5bd1 ("ethdev: add GTP extension header to flow API")
> > Cc: ying.a.w...@intel.com
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Raslan Darawsheh
> > ---
> > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 ++-
> > lib/librte_ethdev/rte_flow.h| 4 ++--
> > 2 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > index f59eb8a27d..dd39c4c3c2 100644
> > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > @@ -3742,7 +3742,8 @@ This section lists supported pattern items and their
> attributes, if any.
> > - ``gtp_psc``: match GTP PDU extension header with type 0x85.
> >
> > - ``pdu_type {unsigned}``: PDU type.
> > - - ``qfi {unsigned}``: QoS flow identifier.
> > +
> > + - ``qfi {unsigned}``: PPP, RQI and QoS flow identifier.
> >
> > - ``pppoes``, ``pppoed``: match PPPoE header.
> >
> > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > index 669e677e91..79106e0246 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -1392,14 +1392,14 @@ static const struct rte_flow_item_meta
> rte_flow_item_meta_mask = {
> >*/
> > struct rte_flow_item_gtp_psc {
> > uint8_t pdu_type; /**< PDU type. */
> > - uint8_t qfi; /**< QoS flow identifier. */
> > + uint8_t qfi; /**< PPP, RQI, QoS flow identifier. */
> > };
>
> By design requirement, rte_flow_item_* should start with the relevant protocol
> header.
>
> There is already a deprecation notice for using protocol header directly in
> the
> rte_flow_item* [1] and Adrew/Ivan already fixed a few of them [2].
>
> Your patch is not directly related on this, but since you are touching to the
> flow_item, would you mind create a protocol struct for it first, and use it in
> the "struct rte_flow_item_gtp_psc"?
> So the protocol related update can be done in the protocol header, instead of
> rte_flow struct.
>
+1
>
> [1]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.dpdk.
> org%2Fdpdk%2Ftree%2Fdoc%2Fguides%2Frel_notes%2Fdeprecation.rst%3Fh%3
> Dv21.02%23n99&data=04%7C01%7Corika%40nvidia.com%7C6391a4c0640
> f4592b70b08d8f058e322%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0
> %7C637523611870497932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat
> a=vU%2F5oO47zb9erTnZL1pl9j0nHCKzea3NJgOeo1FTW0Q%3D&reserved=
> 0
>
> [2]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.dpdk.
> org%2Fnext%2Fdpdk-next-
> net%2Fcommit%2F%3Fid%3D4a061a7bd70bfa023de23e8e654e&data=04%
> 7C01%7Corika%40nvidia.com%7C6391a4c0640f4592b70b08d8f058e322%7C43
> 083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637523611870497932%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WurlQ5VSLqFGVthfRj363xZsC
> No3xJuvxNQCFVcxdkk%3D&reserved=0
Re: [dpdk-dev] [PATCH] ethdev: update qfi definition
Hi,
> -Original Message-
> From: Ori Kam
> Sent: Monday, March 29, 2021 11:53 AM
> To: Ferruh Yigit ; Raslan Darawsheh
> ; dev@dpdk.org; Andrew Rybchenko
> ; Ivan Malov
> Cc: Slava Ovsiienko ; Shiri Kuzin
> ; ying.a.w...@intel.com; sta...@dpdk.org; NBU-
> Contact-Thomas Monjalon ; Olivier Matz
>
> Subject: RE: [dpdk-dev] [PATCH] ethdev: update qfi definition
>
> Hi
>
> > -Original Message-
> > From: dev On Behalf Of Ferruh Yigit
> > Subject: Re: [dpdk-dev] [PATCH] ethdev: update qfi definition
> >
> > On 3/23/2021 12:11 PM, Raslan Darawsheh wrote:
> > > qfi field is 8 bits which represent single bit for
> > > PPP (paging Policy Presence) single bit for RQI
> > > (Reflective QoS Indicator) and 6 bits for qfi
> > > (QoS Flow Identifier)
> >
> > Can you please put a reference for above information?
> > >
Sure, will send in V2,
> > > This update the doxygen format and the mask for qfi
> > > to properly identify the full 8 bits of the field.
> > >
> > > note: changing the default mask would cause different
> > > patterns generated by testpmd.
> > >
> > > Fixes: 346553db5bd1 ("ethdev: add GTP extension header to flow API")
> > > Cc: ying.a.w...@intel.com
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Raslan Darawsheh
> > > ---
> > > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 ++-
> > > lib/librte_ethdev/rte_flow.h| 4 ++--
> > > 2 files changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > > index f59eb8a27d..dd39c4c3c2 100644
> > > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > > @@ -3742,7 +3742,8 @@ This section lists supported pattern items and
> their
> > attributes, if any.
> > > - ``gtp_psc``: match GTP PDU extension header with type 0x85.
> > >
> > > - ``pdu_type {unsigned}``: PDU type.
> > > - - ``qfi {unsigned}``: QoS flow identifier.
> > > +
> > > + - ``qfi {unsigned}``: PPP, RQI and QoS flow identifier.
> > >
> > > - ``pppoes``, ``pppoed``: match PPPoE header.
> > >
> > > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > > index 669e677e91..79106e0246 100644
> > > --- a/lib/librte_ethdev/rte_flow.h
> > > +++ b/lib/librte_ethdev/rte_flow.h
> > > @@ -1392,14 +1392,14 @@ static const struct rte_flow_item_meta
> > rte_flow_item_meta_mask = {
> > >*/
> > > struct rte_flow_item_gtp_psc {
> > > uint8_t pdu_type; /**< PDU type. */
> > > - uint8_t qfi; /**< QoS flow identifier. */
> > > + uint8_t qfi; /**< PPP, RQI, QoS flow identifier. */
> > > };
> >
> > By design requirement, rte_flow_item_* should start with the relevant
> protocol
> > header.
> >
> > There is already a deprecation notice for using protocol header directly in
> the
> > rte_flow_item* [1] and Adrew/Ivan already fixed a few of them [2].
> >
> > Your patch is not directly related on this, but since you are touching to
> > the
> > flow_item, would you mind create a protocol struct for it first, and use it
> > in
> > the "struct rte_flow_item_gtp_psc"?
> > So the protocol related update can be done in the protocol header, instead
> of
> > rte_flow struct.
> >
> +1
Sure, I can create the new protocol and use it , and will send in V2. But,
wouldn't it cause any ABI breakage ?
>
> >
> > [1]
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.d
> pdk.
> >
> org%2Fdpdk%2Ftree%2Fdoc%2Fguides%2Frel_notes%2Fdeprecation.rst%3F
> h%3
> >
> Dv21.02%23n99&data=04%7C01%7Corika%40nvidia.com%7C6391a4c064
> 0
> >
> f4592b70b08d8f058e322%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0
> >
> %7C637523611870497932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> w
> >
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sda
> t
> >
> a=vU%2F5oO47zb9erTnZL1pl9j0nHCKzea3NJgOeo1FTW0Q%3D&reserve
> d=
> > 0
> >
> > [2]
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.d
> pdk.
> > org%2Fnext%2Fdpdk-next-
> >
> net%2Fcommit%2F%3Fid%3D4a061a7bd70bfa023de23e8e654e&data=0
> 4%
> >
> 7C01%7Corika%40nvidia.com%7C6391a4c0640f4592b70b08d8f058e322%7C43
> >
> 083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637523611870497932%7CU
> >
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik
> >
> 1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WurlQ5VSLqFGVthfRj363xZs
> C
> > No3xJuvxNQCFVcxdkk%3D&reserved=0
Re: [dpdk-dev] [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API
Hi All,
> -Original Message-
> From: Matan Azrad
> Subject: RE: [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API
>
> Hi Cristian
>
> Thank you for your important review!
> I agree with all your comments except one, please see inline.
>
> From: Dumitrescu, Cristian
> > Hi Li and Matan,
> >
> > Thank you for your proposal, some comments below.
> >
> > I am also adding Jerin and Hemant to this thread, as they also participated
> > in
> > the definition of the rte_mtr API in 2017. Also Ajit expressed some
> > interest in
> a
> > previous email.
> >
> > > -Original Message-
> > > From: Li Zhang
> > > Sent: Thursday, March 18, 2021 8:58 AM
> > > To: dek...@nvidia.com; or...@nvidia.com; viachesl...@nvidia.com;
> > > ma...@nvidia.com; shah...@nvidia.com; lir...@marvell.com; Singh,
> > > Jasvinder ; Thomas Monjalon
> > > ; Yigit, Ferruh ; Andrew
> > > Rybchenko ; Dumitrescu, Cristian
> > >
> > > Cc: dev@dpdk.org; rasl...@nvidia.com; ron...@nvidia.com
> > > Subject: [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API
> > >
> > > Currently, the flow meter policy does not support multiple actions per
> > > color; also the allowed action types per color are very limited.
> > > In addition, the policy cannot be pre-defined.
> > >
> > > Due to the growing in flow actions offload abilities there is a
> > > potential for the user to use variety of actions per color differently.
> > > This new meter policy API comes to allow this potential in the most
> > > ethdev common way using rte_flow action definition.
> > > A list of rte_flow actions will be provided by the user per color in
> > > order to create a meter policy.
> > > In addition, the API forces to pre-define the policy before the meters
> > > creation in order to allow sharing of single policy with multiple
> > > meters efficiently.
> > >
> > > meter_policy_id is added into struct rte_mtr_params.
> > > So that it can get the policy during the meters creation.
> > >
> > > Policy id 0 is default policy. Action per color as below:
> > > green - no action, yellow - no action, red - drop
> > >
> > > Allow coloring the packet using a new rte_flow_action_color as could
> > > be done by the old policy API,
> > >
> >
> > The proposal essentially is to define the meter policy based on rte_flow
> actions
> > rather than a reduced action set defined specifically just for meter object.
> This
> > makes sense to me.
> >
> > > The next API function were added:
> > > - rte_mtr_meter_policy_add
> > > - rte_mtr_meter_policy_delete
> > > - rte_mtr_meter_policy_update
> > > - rte_mtr_meter_policy_validate
> > > The next struct was changed:
> > > - rte_mtr_params
> > > - rte_mtr_capabilities
> > > The next API was deleted:
> > > - rte_mtr_policer_actions_update
> > >
> > > Signed-off-by: Li Zhang
> > > ---
> > > lib/librte_ethdev/rte_flow.h | 18
> > > lib/librte_ethdev/rte_mtr.c| 55 --
> > > lib/librte_ethdev/rte_mtr.h| 166 -
> > > lib/librte_ethdev/rte_mtr_driver.h | 45 ++--
> > > 4 files changed, 210 insertions(+), 74 deletions(-)
> > >
> > > diff --git a/lib/librte_ethdev/rte_flow.h
> > > b/lib/librte_ethdev/rte_flow.h index 669e677e91..5f38aa7fa4 100644
> > > --- a/lib/librte_ethdev/rte_flow.h
> > > +++ b/lib/librte_ethdev/rte_flow.h
> > > @@ -31,6 +31,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #ifdef __cplusplus
> > > extern "C" {
> > > @@ -2236,6 +2237,13 @@ enum rte_flow_action_type {
> > >* See struct rte_flow_action_modify_field.
> > >*/
> > > RTE_FLOW_ACTION_TYPE_MODIFY_FIELD,
> > > +
> > > + /**
> > > + * Color the packet to reflect the meter color result.
> > > + *
> > > + * See struct rte_flow_action_color.
> > > + */
> > > + RTE_FLOW_ACTION_TYPE_COlOR,
> >
> > Typo here, it should be RTE_FLOW_ACTION_TYPE_COLOR.
> >
Why do we need this action?
if it is to save the color it should be done by using mark/metadata
Or by the action of meter. For example you can see RTE_FLOW_ACTION_TYPE_SECURITY
Which if exist saves the session id to a dedicated mbuf field.
> > > };
> > >
> > > /**
[Snip]
> > I suggest you do not redundantly specify the value of the default policy ID
> > in
> the
> > comment. Replace by "Default policy ID."
> >
> > > + * Action per color as below:
> > > + * green - no action, yellow - no action, red - drop
> >
> > This does not make sense to me as the default policy. The default policy
> should
> > be "no change", i.e. green -> green (no change), yellow -> yellow (no
> > change),
> > red -> red (no change).
>
> Can you explain why it doesn't make sense to you?
>
> Meter with "no change" for all colors has no effect on the packets so it is
> redundant action which just costs performance and resources - probably never
> be used.
>
> The most common usage for meter is to drop all the packets come above the
> defined rate limit - so it makes sens
Re: [dpdk-dev] [PATCH v2 3/4] app/test-regex: support scattered mbuf input
Hi Mou, > -Original Message- > From: Suanming Mou > > This commits adds the scattered mbuf input support. > > Signed-off-by: Suanming Mou > --- > app/test-regex/main.c | 134 ++ > 1 file changed, 109 insertions(+), 25 deletions(-) > Acked-by: Ori Kam Best, Ori
Re: [dpdk-dev] [PATCH v2 1/4] common/mlx5: add user memory registration bits
Hi,
> -Original Message-
> From: Suanming Mou
> This commit adds the UMR capability bits.
>
> Signed-off-by: Suanming Mou
> ---
> drivers/common/mlx5/linux/meson.build | 2 ++
> drivers/common/mlx5/mlx5_devx_cmds.c | 5 +
> drivers/common/mlx5/mlx5_devx_cmds.h | 3 +++
> 3 files changed, 10 insertions(+)
>
> diff --git a/drivers/common/mlx5/linux/meson.build
> b/drivers/common/mlx5/linux/meson.build
> index 220de35420..5d6a861689 100644
> --- a/drivers/common/mlx5/linux/meson.build
> +++ b/drivers/common/mlx5/linux/meson.build
> @@ -186,6 +186,8 @@ has_sym_args = [
> 'mlx5dv_dr_action_create_aso' ],
> [ 'HAVE_INFINIBAND_VERBS_H', 'infiniband/verbs.h',
> 'INFINIBAND_VERBS_H' ],
> +[ 'HAVE_MLX5_UMR_IMKEY', 'infiniband/mlx5dv.h',
> +'MLX5_WQE_UMR_CTRL_FLAG_INLINE' ],
> ]
> config = configuration_data()
> foreach arg:has_sym_args
> diff --git a/drivers/common/mlx5/mlx5_devx_cmds.c
> b/drivers/common/mlx5/mlx5_devx_cmds.c
> index c90e020643..268bcd0d99 100644
> --- a/drivers/common/mlx5/mlx5_devx_cmds.c
> +++ b/drivers/common/mlx5/mlx5_devx_cmds.c
> @@ -266,6 +266,7 @@ mlx5_devx_cmd_mkey_create(void *ctx,
> MLX5_SET(mkc, mkc, qpn, 0xff);
> MLX5_SET(mkc, mkc, pd, attr->pd);
> MLX5_SET(mkc, mkc, mkey_7_0, attr->umem_id & 0xFF);
> + MLX5_SET(mkc, mkc, umr_en, attr->umr_en);
> MLX5_SET(mkc, mkc, translations_octword_size, translation_size);
> MLX5_SET(mkc, mkc, relaxed_ordering_write,
>attr->relaxed_ordering_write);
> @@ -752,6 +753,10 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
> mini_cqe_resp_flow_tag);
> attr->mini_cqe_resp_l3_l4_tag = MLX5_GET(cmd_hca_cap, hcattr,
>mini_cqe_resp_l3_l4_tag);
> + attr->umr_indirect_mkey_disabled =
> + MLX5_GET(cmd_hca_cap, hcattr,
> umr_indirect_mkey_disabled);
> + attr->umr_modify_entity_size_disabled =
> + MLX5_GET(cmd_hca_cap, hcattr,
> umr_modify_entity_size_disabled);
> if (attr->qos.sup) {
> MLX5_SET(query_hca_cap_in, in, op_mod,
>MLX5_GET_HCA_CAP_OP_MOD_QOS_CAP |
> diff --git a/drivers/common/mlx5/mlx5_devx_cmds.h
> b/drivers/common/mlx5/mlx5_devx_cmds.h
> index 2826c0b2c6..67b5f771c6 100644
> --- a/drivers/common/mlx5/mlx5_devx_cmds.h
> +++ b/drivers/common/mlx5/mlx5_devx_cmds.h
> @@ -31,6 +31,7 @@ struct mlx5_devx_mkey_attr {
> uint32_t pg_access:1;
> uint32_t relaxed_ordering_write:1;
> uint32_t relaxed_ordering_read:1;
> + uint32_t umr_en:1;
> struct mlx5_klm *klm_array;
> int klm_num;
> };
> @@ -151,6 +152,8 @@ struct mlx5_hca_attr {
> uint32_t log_max_mmo_dma:5;
> uint32_t log_max_mmo_compress:5;
> uint32_t log_max_mmo_decompress:5;
> + uint32_t umr_modify_entity_size_disabled:1;
> + uint32_t umr_indirect_mkey_disabled:1;
> };
>
> struct mlx5_devx_wq_attr {
> --
> 2.25.1
Acked-by: Ori Kam
Best,
Ori
Re: [dpdk-dev] [PATCH v2 2/4] regex/mlx5: add data path scattered mbuf process
Hi Mou, PSB one small comment, Please update and feel free to add my ack. > -Original Message- > From: Suanming Mou > > UMR WQE can convert multiple mkey's memory sapce to contiguous space. > Take advantage of the UMR WQE, scattered mbuf in one operation can be > converted to an indirect mkey. The RegEx which only accepts one mkey > can now process the whole scattered mbuf. > > The maximum scattered mbuf can be supported in one UMR WQE is now > defined as 64. Multiple operations scattered mbufs can be add to one > UMR WQE if there is enough space in the KLM array, since the operations > can address their own mbuf's content by the mkey's address and length. > However, one operation's scattered mbuf's can't be placed in two > different UMR WQE's KLM array, if the UMR WQE's KLM does not has enough > free space for one operation, a new UMR WQE will be required. > > In case the UMR WQE's indirect mkey will be over wrapped by the SQ's > WQE move, the meky's index used by the UMR WQE should be the index of > last the RegEX WQE in the operations. As one operation consumes one > WQE set, build the RegEx WQE by reverse helps address the mkey more > efficiently. Once the operations in one burst consumes multiple mkeys, > when the mkey KLM array is full, the reverse WQE set index will always > be the last of the new mkey's for the new UMR WQE. > > In GGA mode, the SQ WQE's memory layout becomes UMR/NOP and RegEx > WQE by > interleave. The UMR and RegEx WQE can be called as WQE set. The SQ's pi > and ci will also be increased as WQE set not as WQE. > > For operations don't have scattered mbuf, uses the mbuf's mkey directly, > the WQE set combination is NOP + RegEx. > For operations have scattered mubf but share the UMR WQE with others, > the WQE set combination is NOP + RegEx. > For operations complete the UMR WQE, the WQE set combination is UMR + > RegEx. > > Signed-off-by: Suanming Mou > --- > doc/guides/regexdevs/mlx5.rst| 5 + > doc/guides/rel_notes/release_21_05.rst | 4 + > doc/guides/tools/testregex.rst | 3 + > drivers/regex/mlx5/mlx5_regex.c | 9 + > drivers/regex/mlx5/mlx5_regex.h | 26 +- > drivers/regex/mlx5/mlx5_regex_control.c | 43 ++- > drivers/regex/mlx5/mlx5_regex_fastpath.c | 378 +-- > 7 files changed, 410 insertions(+), 58 deletions(-) > > diff --git a/doc/guides/regexdevs/mlx5.rst b/doc/guides/regexdevs/mlx5.rst > index faaa6ac11d..45a0b96980 100644 > --- a/doc/guides/regexdevs/mlx5.rst > +++ b/doc/guides/regexdevs/mlx5.rst > @@ -35,6 +35,11 @@ be specified as device parameter. The RegEx device can > be probed and used with > other Mellanox devices, by adding more options in the class. > For example: ``class=net:regex`` will probe both the net PMD and the RegEx > PMD. > > +Features > + > + > +- Multi segments mbuf support. > + > Supported NICs > -- > > diff --git a/doc/guides/rel_notes/release_21_05.rst > b/doc/guides/rel_notes/release_21_05.rst > index 3d4b061686..281d4aaa64 100644 > --- a/doc/guides/rel_notes/release_21_05.rst > +++ b/doc/guides/rel_notes/release_21_05.rst > @@ -113,6 +113,10 @@ New Features >* Added command to display Rx queue used descriptor count. > ``show port (port_id) rxq (queue_id) desc used count`` > > +* **Updated Mellanox RegEx PMD.** > + > + * Added support for multi segments mbuf. > + > > Removed Items > - > diff --git a/doc/guides/tools/testregex.rst b/doc/guides/tools/testregex.rst > index a59acd919f..cdb1ffd6ee 100644 > --- a/doc/guides/tools/testregex.rst > +++ b/doc/guides/tools/testregex.rst > @@ -68,6 +68,9 @@ Application Options > ``--nb_iter N`` >number of iteration to run > > +``--nb_segs N`` > + number of mbuf segment > + > ``--help`` >print application options I don't think this is part of this patch. It should belong to the app patch. > diff --git a/drivers/regex/mlx5/mlx5_regex.c > b/drivers/regex/mlx5/mlx5_regex.c > index ac5b205fa9..82c485e50c 100644 > --- a/drivers/regex/mlx5/mlx5_regex.c > +++ b/drivers/regex/mlx5/mlx5_regex.c > @@ -199,6 +199,13 @@ mlx5_regex_pci_probe(struct rte_pci_driver *pci_drv > __rte_unused, > } > priv->regexdev->dev_ops = &mlx5_regexdev_ops; > priv->regexdev->enqueue = mlx5_regexdev_enqueue; > +#ifdef HAVE_MLX5_UMR_IMKEY > + if (!attr.umr_indirect_mkey_disabled && > + !attr.umr_modify_entity_size_disabled) > + priv->has_umr = 1; > + if (priv->has_umr) > + priv->regexdev->enqueue = mlx5_regexdev_enqueue_gga; > +#endif > priv->regexdev->dequeue = mlx5_regexdev_dequeue; > priv->regexdev->device = (struct rte_device *)pci_dev; > priv->regexdev->data->dev_private = priv; > @@ -213,6 +220,8 @@ mlx5_regex_pci_probe(struct rte_pci_driver *pci_drv > __rte_unused, > rte_errno = ENOMEM; > goto error; > } > + DRV_LOG(INFO, "RegEx GGA is %s.", > + priv->has_umr
Re: [dpdk-dev] [PATCH v2 4/4] regex/mlx5: prevent wrong calculation of free sqs in umr mode
Hi
> -Original Message-
> From: Suanming Mou
>
> From: John Hurley
>
> A recent change adds support for scattered mbuf and UMR support for regex.
> Part of this commit makes the pi and ci counters of the regex_sq a quarter
> of the length in non umr mode, effectively moving them from 16 bits to
> 14. The new get_free method casts the difference in pi and ci to a 16 bit
> value when calculating the free send queues, accounting for any wrapping
> when pi has looped back to 0 but ci has not yet. However, the move to 14
> bits while still casting to 16 can now lead to corrupted, large values
> returned.
>
> Modify the get_free function to take in the has_umr flag and, accordingly,
> account for wrapping on either 14 or 16 bit pi/ci difference.
>
> Fixes: a20fe8e74dea ("regex/mlx5: add data path scattered mbuf process")
> Signed-off-by: John Hurley
> ---
> drivers/regex/mlx5/mlx5_regex_fastpath.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/regex/mlx5/mlx5_regex_fastpath.c
> b/drivers/regex/mlx5/mlx5_regex_fastpath.c
> index 4f9402c583..b57e7d7794 100644
> --- a/drivers/regex/mlx5/mlx5_regex_fastpath.c
> +++ b/drivers/regex/mlx5/mlx5_regex_fastpath.c
> @@ -192,8 +192,10 @@ send_doorbell(struct mlx5_regex_priv *priv, struct
> mlx5_regex_sq *sq)
> }
>
> static inline int
> -get_free(struct mlx5_regex_sq *sq) {
> - return (sq_size_get(sq) - (uint16_t)(sq->pi - sq->ci));
> +get_free(struct mlx5_regex_sq *sq, uint8_t has_umr) {
> + return (sq_size_get(sq) - ((sq->pi - sq->ci) &
> + (has_umr ? (MLX5_REGEX_MAX_WQE_INDEX >> 2) :
> + MLX5_REGEX_MAX_WQE_INDEX)));
> }
>
> static inline uint32_t
> @@ -385,7 +387,7 @@ mlx5_regexdev_enqueue_gga(struct rte_regexdev
> *dev, uint16_t qp_id,
> while ((sqid = ffs(queue->free_sqs))) {
> sqid--; /* ffs returns 1 for bit 0 */
> sq = &queue->sqs[sqid];
> - nb_desc = get_free(sq);
> + nb_desc = get_free(sq, priv->has_umr);
> if (nb_desc) {
> /* The ops be handled can't exceed nb_ops. */
> if (nb_desc > nb_left)
> @@ -418,7 +420,7 @@ mlx5_regexdev_enqueue(struct rte_regexdev *dev,
> uint16_t qp_id,
> while ((sqid = ffs(queue->free_sqs))) {
> sqid--; /* ffs returns 1 for bit 0 */
> sq = &queue->sqs[sqid];
> - while (get_free(sq)) {
> + while (get_free(sq, priv->has_umr)) {
> job_id = job_id_get(sqid, sq_size_get(sq), sq->pi);
> prep_one(priv, queue, sq, ops[i], &queue-
> >jobs[job_id]);
> i++;
> --
> 2.25.1
Acked-by: Ori Kam
Best,
Ori
Re: [dpdk-dev] [PATCH v2] ethdev: introduce enable_driver_sdk to install driver headers
On 3/26/2021 8:52 PM, Tyler Retzlaff wrote: On Fri, Mar 26, 2021 at 12:02:55PM +, Ferruh Yigit wrote: On 3/24/2021 4:24 PM, Tyler Retzlaff wrote: On Wed, Mar 24, 2021 at 12:30:36PM +0100, Thomas Monjalon wrote: 24/03/2021 12:27, Ferruh Yigit: But not sure how to manage the same problem for whole project, if install all headers in one patch, or add them gradually via separate patches by time ... We did a cleanup in ethdev but not in other driver classes. When the cleanup will be done gradually, the headers must move in this new category driver_sdk_headers. yes, some headers are not installed now. so they need only to have their api marked __rte_internal and installed (since there should be no external consumer as a function of not being installed) the more difficult case is where headers were installed but the api were not marked __rte_internal and appear in the stable version.map. for those i guess deprecation notice has to be issued before marking as internal. Are you referring to any specific APIs, can you share list of them? i can't remember the whole list but Thomas originally indicated the following candidate list. baseband/ -> librte_bbdev/rte_bbdev_pmd.h bus/ -> rte_bus.h common/ -> no interface crypto/ -> librte_cryptodev/rte_cryptodev_pmd.h event/ -> librte_eventdev/ mempool/ -> librte_mempool/ net/ -> librte_ethdev/ raw/ -> librte_rawdev/rte_rawdev_pmd.h regex/ -> librte_regexdev/rte_regexdev_driver.h vdpa/ -> librte_vhost/rte_vdpa_dev.h some of these headers are not published, some are. These are public headers, so they should not have '__rte_internal' functions, are you saying some of public headers has internal functions that are presented as public APIs?
Re: [dpdk-dev] [PATCH v1] net/ice: remove the redundant function type
> -Original Message- > From: Wang, Haiyue > Sent: Monday, March 29, 2021 12:56 PM > To: dev@dpdk.org > Cc: Zhang, Qi Z ; Wang, Haiyue > ; Yang, Qiming > Subject: [PATCH v1] net/ice: remove the redundant function type > > The function 'ice_is_profile_rule' is defined as 'ice_is_prof_rule' in base > code, > which has the exactly same function body. > > So remove the 'ice_is_profile_rule', use the 'ice_is_prof_rule' instead. > > Signed-off-by: Haiyue Wang Acked-by: Qi Zhang Applied to dpdk-next-net-intel. Thanks Qi
Re: [dpdk-dev] [PATCH v2 2/4] regex/mlx5: add data path scattered mbuf process
Hi Ori, > -Original Message- > From: Ori Kam > Sent: Monday, March 29, 2021 5:35 PM > To: Suanming Mou > Cc: dev@dpdk.org; Slava Ovsiienko ; Matan Azrad > ; Raslan Darawsheh > Subject: RE: [PATCH v2 2/4] regex/mlx5: add data path scattered mbuf process > > Hi Mou, > > PSB one small comment, > Please update and feel free to add my ack. > > > diff --git a/doc/guides/tools/testregex.rst > > b/doc/guides/tools/testregex.rst index a59acd919f..cdb1ffd6ee 100644 > > --- a/doc/guides/tools/testregex.rst > > +++ b/doc/guides/tools/testregex.rst > > @@ -68,6 +68,9 @@ Application Options > > ``--nb_iter N`` > >number of iteration to run > > > > +``--nb_segs N`` > > + number of mbuf segment > > + > > ``--help`` > >print application options > > I don't think this is part of this patch. > It should belong to the app patch. > Yes, will fix that in v3. Thanks. BR, SuanmingMou
[dpdk-dev] [Bug 668] DPDK power governor fails if base_frequency is not opened
https://bugs.dpdk.org/show_bug.cgi?id=668
Bug ID: 668
Summary: DPDK power governor fails if base_frequency is not
opened
Product: DPDK
Version: 20.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: Normal
Component: other
Assignee: dev@dpdk.org
Reporter: michallinuxst...@gmail.com
Target Milestone: ---
DPDK fails to initialize pstate cpufreq in case base_frequency is missing from
sysfs under given cpu. This is a bit problematic now since this particular attr
exists only under specific conditions: active intel_pstate + HWP supported by
the cpu. Also, from the commit itself (4db9587bbf) it looks like this was put
in place by accident since the part which accepts missing base_frequency (and
which sets it to 0) still exists, i.e.:
snprintf(fullpath_base, sizeof(fullpath_base), POWER_SYSFILE_BASE_FREQ,
pi->lcore_id);
f_base = fopen(fullpath_base, "r");
FOPEN_OR_ERR_RET(f_base, -1); /* <- point of failure */
if (f_base == NULL) {
/* No sysfs base_frequency, that's OK, continue without */
base_ratio = 0;
Initially noticed under https://github.com/spdk/spdk/issues/1859.
Any feedback on the matter would be appreciate. :)
--
You are receiving this mail because:
You are the assignee for the bug.
Re: [dpdk-dev] [PATCH v3 0/6] net: ngbe PMD
Hi, > -Original Message- > From: Jiawen Wu > Sent: Tuesday, March 23, 2021 10:20 AM > To: dev@dpdk.org > Cc: Jiawen Wu > Subject: [PATCH v3 0/6] net: ngbe PMD > > This patch set provides a skeleton of ngbe PMD, which adapted to Wangxun > WX1860 series NICs. > > v3: > - Use rte_ether functions to define marcos. > > v2: > - Correct some clerical errors. > - Use ethdev debug flags instead of driver own > > Jiawen Wu (6): > net/ngbe: add build and doc infrastructure > net/ngbe: add device IDs > net/ngbe: support probe and remove > net/ngbe: add device init and uninit > net/ngbe: add log type and error type > net/ngbe: define registers > > MAINTAINERS|6 + > doc/guides/nics/features/ngbe.ini | 11 + > doc/guides/nics/index.rst |1 + > doc/guides/nics/ngbe.rst | 48 + > doc/guides/rel_notes/release_21_05.rst |6 + > drivers/net/meson.build|1 + > drivers/net/ngbe/base/meson.build | 20 + > drivers/net/ngbe/base/ngbe.h | 11 + > drivers/net/ngbe/base/ngbe_devids.h| 83 ++ > drivers/net/ngbe/base/ngbe_hw.c| 59 + > drivers/net/ngbe/base/ngbe_hw.h| 12 + > drivers/net/ngbe/base/ngbe_osdep.h | 174 +++ > drivers/net/ngbe/base/ngbe_regs.h | 1489 > > drivers/net/ngbe/base/ngbe_status.h| 124 ++ > drivers/net/ngbe/base/ngbe_type.h | 30 + > drivers/net/ngbe/meson.build | 18 + > drivers/net/ngbe/ngbe_ethdev.c | 156 +++ > drivers/net/ngbe/ngbe_ethdev.h | 21 + > drivers/net/ngbe/ngbe_logs.h | 45 + > drivers/net/ngbe/version.map |3 + > 20 files changed, 2318 insertions(+) > create mode 100644 doc/guides/nics/features/ngbe.ini create mode > 100644 doc/guides/nics/ngbe.rst create mode 100644 > drivers/net/ngbe/base/meson.build create mode 100644 > drivers/net/ngbe/base/ngbe.h create mode 100644 > drivers/net/ngbe/base/ngbe_devids.h > create mode 100644 drivers/net/ngbe/base/ngbe_hw.c create mode > 100644 drivers/net/ngbe/base/ngbe_hw.h create mode 100644 > drivers/net/ngbe/base/ngbe_osdep.h > create mode 100644 drivers/net/ngbe/base/ngbe_regs.h create mode > 100644 drivers/net/ngbe/base/ngbe_status.h > create mode 100644 drivers/net/ngbe/base/ngbe_type.h create mode > 100644 drivers/net/ngbe/meson.build create mode 100644 > drivers/net/ngbe/ngbe_ethdev.c create mode 100644 > drivers/net/ngbe/ngbe_ethdev.h create mode 100644 > drivers/net/ngbe/ngbe_logs.h create mode 100644 > drivers/net/ngbe/version.map > > -- > 2.21.0.windows.1
Re: [dpdk-dev] [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API
On Thu, Mar 18, 2021 at 2:28 PM Li Zhang wrote:
>
> Currently, the flow meter policy does not support multiple actions
> per color; also the allowed action types per color are very limited.
> In addition, the policy cannot be pre-defined.
>
> Due to the growing in flow actions offload abilities there is a potential
> for the user to use variety of actions per color differently.
> This new meter policy API comes to allow this potential in the most ethdev
> common way using rte_flow action definition.
> A list of rte_flow actions will be provided by the user per color
> in order to create a meter policy.
> In addition, the API forces to pre-define the policy before
> the meters creation in order to allow sharing of single policy
> with multiple meters efficiently.
>
> meter_policy_id is added into struct rte_mtr_params.
> So that it can get the policy during the meters creation.
>
> Policy id 0 is default policy. Action per color as below:
> green - no action, yellow - no action, red - drop
>
> Allow coloring the packet using a new rte_flow_action_color
> as could be done by the old policy API,
>
> The next API function were added:
> - rte_mtr_meter_policy_add
> - rte_mtr_meter_policy_delete
> - rte_mtr_meter_policy_update
> - rte_mtr_meter_policy_validate
> The next struct was changed:
> - rte_mtr_params
> - rte_mtr_capabilities
> The next API was deleted:
> - rte_mtr_policer_actions_update
>
> Signed-off-by: Li Zhang
> ---
> lib/librte_ethdev/rte_flow.h | 18
> lib/librte_ethdev/rte_mtr.c| 55 --
> lib/librte_ethdev/rte_mtr.h| 166 -
> lib/librte_ethdev/rte_mtr_driver.h | 45 ++--
> 4 files changed, 210 insertions(+), 74 deletions(-)
>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index 669e677e91..5f38aa7fa4 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> #ifdef __cplusplus
> extern "C" {
> @@ -2236,6 +2237,13 @@ enum rte_flow_action_type {
> * See struct rte_flow_action_modify_field.
> */
> RTE_FLOW_ACTION_TYPE_MODIFY_FIELD,
> +
> + /**
> +* Color the packet to reflect the meter color result.
> +*
> +* See struct rte_flow_action_color.
> +*/
> + RTE_FLOW_ACTION_TYPE_COlOR,
Based on my understanding of this API,
1) Application creates the policy
2) Attachs the policy ID to meter object in params
If so, Why we need this new action?
> };
>
> /**
> @@ -2828,6 +2836,16 @@ struct rte_flow_action_set_dscp {
> */
> struct rte_flow_shared_action;
>
> +/**
> + * Meter policy add
> + *
> + * Create a new meter policy. The new policy
> + * is used to create single or multiple MTR objects.
> + *
> + * @param[in] port_id
> + * The port identifier of the Ethernet device.
> + * @param[in] policy_id
> + * Policy identifier for the new meter policy.
> + * @param[in] actions
> + * Associated actions per color.
> + * list NULL is legal and means no special action.
> + * (list terminated by the END action).
> + * @param[out] error
> + * Error details. Filled in only on error, when not NULL.
> + * @return
> + * 0 on success, non-zero error code otherwise.
> + */
> +__rte_experimental
> +int
> +rte_mtr_meter_policy_add(uint16_t port_id,
_create() may be better here instead of _add() as you have used _delete()
> + uint32_t policy_id,
> + const struct rte_flow_action *actions[RTE_COLORS],
1) Does this mean that MLX HW can support any rte_flow actions like,
if packet color is green do RTE_FLOW_ACTION_TYPE_SECURITY etc.
2) Is there any real-world use case other than using normal action
like pass or drop as it is used
in conjunction with meter object?
3) Marvell HW has the following policy actions
a) PASS
b) DROP
c) RED (Random early discard)
Both (a) and (c) are not in enumated as rte_flow_actions.
Should we take rte_flow_action or create meter-specific policy actions?
[dpdk-dev] [PATCH v4] build: alias default build as generic
The current machine='default' build name is not descriptive. The actual
default build is machine='native'. Add an alternative string which does
the same build and better describes what we're building:
machine='generic'. Leave machine='default' for backwards compatibility.
Signed-off-by: Juraj Linkeš
Reviewed-by: Honnappa Nagarahalli
Acked-by: Bruce Richardson
---
config/arm/meson.build| 7 ---
config/meson.build| 13 +++--
devtools/test-meson-builds.sh | 14 +++---
doc/guides/prog_guide/build-sdk-meson.rst | 4 ++--
meson_options.txt | 2 +-
5 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 00bc4610a3..aaed89bd5b 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation.
# Copyright(c) 2017 Cavium, Inc
+# Copyright(c) 2021 PANTHEON.tech s.r.o.
# common flags to all aarch64 builds, with lowest priority
flags_common = [
@@ -208,8 +209,8 @@ if dpdk_conf.get('RTE_ARCH_32')
else
# aarch64 build
if not meson.is_cross_build()
- if machine == 'default'
- # default build
+ if machine == 'generic'
+ # generic build
implementer_id = 'generic'
part_number = 'generic'
else
@@ -256,7 +257,7 @@ else
'(-Dmachine=generic) build.')
endif
- # use default flags with implementer flags
+ # use common flags with implementer flags
dpdk_flags = flags_common + implementer_config['flags'] +
part_number_config.get('flags', [])
# apply supported machine args
diff --git a/config/meson.build b/config/meson.build
index 66a2edcc47..3268cf6804 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -70,21 +70,22 @@ else
machine = get_option('machine')
endif
-# machine type 'default' is special, it defaults to the per arch agreed common
-# minimal baseline needed for DPDK.
+# machine type 'generic' is special, it selects the per arch agreed common
+# minimal baseline needed for DPDK. Machine type 'default' is also supported
+# with the same meaning for backwards compatibility.
# That might not be the most optimized, but the most portable version while
# still being able to support the CPU features required for DPDK.
# This can be bumped up by the DPDK project, but it can never be an
# invariant like 'native'
-if machine == 'default'
+if machine == 'default' or machine == 'generic'
if host_machine.cpu_family().startswith('x86')
- # matches the old pre-meson build systems default
+ # matches the old pre-meson build systems generic machine
machine = 'corei7'
elif host_machine.cpu_family().startswith('arm')
machine = 'armv7-a'
elif host_machine.cpu_family().startswith('aarch')
- # arm64 manages defaults in config/arm/meson.build
- machine = 'default'
+ # arm64 manages generic config in config/arm/meson.build
+ machine = 'generic'
elif host_machine.cpu_family().startswith('ppc')
machine = 'power8'
endif
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index c11ae87e0d..daf817ac3e 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -223,12 +223,12 @@ done
# test compilation with minimal x86 instruction set
# Set the install path for libraries to "lib" explicitly to prevent problems
# with pkg-config prefixes if installed in "lib/x86_64-linux-gnu" later.
-default_machine='nehalem'
-if ! check_cc_flags "-march=$default_machine" ; then
- default_machine='corei7'
+generic_machine='nehalem'
+if ! check_cc_flags "-march=$generic_machine" ; then
+ generic_machine='corei7'
fi
-build build-x86-default cc skipABI -Dcheck_includes=true \
- -Dlibdir=lib -Dmachine=$default_machine $use_shared
+build build-x86-generic cc skipABI -Dcheck_includes=true \
+ -Dlibdir=lib -Dmachine=$generic_machine $use_shared
# 32-bit with default compiler
if check_cc_flags '-m32' ; then
@@ -271,10 +271,10 @@ for f in $srcdir/config/ppc/ppc* ; do
build $targetdir $f ABI $use_shared
done
-# Test installation of the x86-default target, to be used for checking
+# Test installation of the x86-generic target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
load_env cc
-build_path=$(readlink -f $builds_dir/build-x86-default)
+build_path=$(readlink -f $builds_dir/build-x86-generic)
export DESTDIR=$build_path/install
install_target $build_path $DESTDIR
pc_file=$(find $DESTDIR -name libdpdk.pc)
diff --git a/doc/guides/prog_guide/build-sdk-meson.rst
b/doc/guides/p
Re: [dpdk-dev] [PATCH v4 0/3] vhost: make virtqueue cache-friendly
On Tue, 2021-03-23 at 11:30 +0100, David Marchand wrote: > On Tue, Mar 23, 2021 at 10:02 AM Maxime Coquelin > wrote: > > > > As done for Virtio PMD, this series improves cache utilization > > of the vhost_virtqueue struct by removing unused field, > > make the live-migration cache dynamically allocated at > > live-migration setup time and by moving fields > > around so that hot fields are on the first cachelines. > > > > With this series, The struct vhost_virtqueue size goes > > from 832B (13 cachelines) down to 320B (5 cachelines). > > > > With this series and the virtio one, I measure a gain > > of up to 8% in IO loop micro-benchmark with packed > > ring, and 5% with split ring. > > > > I don't have a setup at hand to run PVP testing, but > > it might be interresting to get the numbers as I > > suspect the cache pressure is higher in this test as > > in real use-cases. > > > > Changes in v4: > > == > > - Fix missing changes to boolean (Chenbo) > > > > For the series, > Reviewed-by: David Marchand > > Merci ! > > Tested this in a PVP setup on ARM, giving a slight improvement in performance. For the series: Tested-by: Balazs Nemeth
Re: [dpdk-dev] [PATCH v4 0/4] net/virtio: make virtqueue struct cache-friendly
On Tue, 2021-03-16 at 10:38 +0100, Maxime Coquelin wrote: > This series optimizes the cache usage of virtqueue struct, > by making a "fake" mbuf being dynamically allocated in Rx > virtnet struct, by removing a useless virtuque pointer > into the virtnet structs and by moving a few fields > to pack holes. > > With these 3 patches, the virtqueue struct size goes from > 576 bytes (9 cachelines) to 248 bytes (4 cachelines). > > Changes in v4: > == > - Fix ARM build failure after rebase (0-day robot) > - Fix fake_mbuf freeing (David) > - Applied David R-by > > Changes in v3: > == > - Use rte_zmalloc_socket for fake mbuf alloc (David) > - Fix typos in commit messages > - Remove superfluous pointer check befor freeing (David) > - Fix checkpatch warnings > > Changes in v2: > == > - Rebase on latest main > - Improve error path in virtio_init_queue > - Fix various typos in commit messages > > Maxime Coquelin (4): > net/virtio: remove reference to virtqueue in vrings > net/virtio: improve queue init error path > net/virtio: allocate fake mbuf in Rx queue > net/virtio: pack virtqueue struct > > drivers/net/virtio/virtio_ethdev.c | 64 +++ > drivers/net/virtio/virtio_rxtx.c | 37 +-- > drivers/net/virtio/virtio_rxtx.h | 5 +- > drivers/net/virtio/virtio_rxtx_packed.c | 4 +- > drivers/net/virtio/virtio_rxtx_packed.h | 6 +- > drivers/net/virtio/virtio_rxtx_packed_avx.h | 4 +- > drivers/net/virtio/virtio_rxtx_packed_neon.h | 4 +- > drivers/net/virtio/virtio_rxtx_simple.h | 2 +- > .../net/virtio/virtio_rxtx_simple_altivec.c | 2 +- > drivers/net/virtio/virtio_rxtx_simple_neon.c | 2 +- > drivers/net/virtio/virtio_rxtx_simple_sse.c | 2 +- > .../net/virtio/virtio_user/virtio_user_dev.c | 4 +- > drivers/net/virtio/virtio_user_ethdev.c | 2 +- > drivers/net/virtio/virtqueue.h | 24 --- > 14 files changed, 87 insertions(+), 75 deletions(-) > Tested this in a PVP setup on ARM, giving a slight improvement in performance. For the series: Tested-by: Balazs Nemeth
[dpdk-dev] [PATCH v3] build: add platform meson option
The current meson option 'machine' should only specify the ISA, which is
not sufficient for Arm, where setting ISA implies other setting as well.
Add a new meson option, 'platform', which differentiates the type of the
build (native/generic) and sets machine accordingly, unless the user
chooses to override it.
The 'machine' option also doesn't describe very well what it sets, so
introduce a new option 'cpu_instruction_set', but keep 'machine' for
backwards compatibility.
These two new variables, taken together, achieve what 'machine' was
setting per architecture - setting the ISA in x86 build and setting
native/default 'build type' in aarch64 build - is now properly being set
for all architectures in a uniform manner.
Signed-off-by: Juraj Linkeš
---
config/meson.build| 47 +--
devtools/test-meson-builds.sh | 9 ---
meson_options.txt | 8 --
3 files changed, 45 insertions(+), 19 deletions(-)
diff --git a/config/meson.build b/config/meson.build
index 66a2edcc47..32c9e18c17 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -63,42 +63,63 @@ if not is_windows
pmd_subdir_opt)
endif
-# set the machine type and cflags for it
+platform = get_option('platform')
+
+# set the cpu_instruction_set type and cflags for it
if meson.is_cross_build()
- machine = host_machine.cpu()
+ cpu_instruction_set = host_machine.cpu()
else
- machine = get_option('machine')
+ cpu_instruction_set = get_option('cpu_instruction_set')
+ if get_option('machine') != 'auto'
+ warning('The "machine" option is deprecated. ' +
+ 'Please use "cpu_instruction_set" instead.')
+ if cpu_instruction_set != 'auto'
+ error('Setting both "machine" and ' +
+ '"cpu_instruction_set" is unsupported.')
+ endif
+ cpu_instruction_set = get_option('machine')
+ endif
+endif
+
+if platform == 'native'
+ if cpu_instruction_set == 'auto'
+ cpu_instruction_set = 'native'
+ endif
+elif platform == 'generic'
+ if cpu_instruction_set == 'auto'
+ cpu_instruction_set = 'default'
+ endif
endif
-# machine type 'default' is special, it defaults to the per arch agreed common
+if cpu_instruction_set == 'default'
+# cpu_instruction_set type 'default' is special, it defaults to the per arch
agreed common
# minimal baseline needed for DPDK.
# That might not be the most optimized, but the most portable version while
# still being able to support the CPU features required for DPDK.
# This can be bumped up by the DPDK project, but it can never be an
# invariant like 'native'
-if machine == 'default'
if host_machine.cpu_family().startswith('x86')
# matches the old pre-meson build systems default
- machine = 'corei7'
+ cpu_instruction_set = 'corei7'
elif host_machine.cpu_family().startswith('arm')
- machine = 'armv7-a'
+ cpu_instruction_set = 'armv7-a'
elif host_machine.cpu_family().startswith('aarch')
# arm64 manages defaults in config/arm/meson.build
- machine = 'default'
+ cpu_instruction_set = 'default'
elif host_machine.cpu_family().startswith('ppc')
- machine = 'power8'
+ cpu_instruction_set = 'power8'
endif
endif
-dpdk_conf.set('RTE_MACHINE', machine)
+dpdk_conf.set('RTE_MACHINE', cpu_instruction_set)
machine_args = []
# ppc64 does not support -march= at all, use -mcpu and -mtune for that
if host_machine.cpu_family().startswith('ppc')
- machine_args += '-mcpu=' + machine
- machine_args += '-mtune=' + machine
+ machine_args += '-mcpu=' + cpu_instruction_set
+ machine_args += '-mtune=' + cpu_instruction_set
else
- machine_args += '-march=' + machine
+ machine_args += '-march=' + cpu_instruction_set
endif
toolchain = cc.get_id()
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index c11ae87e0d..b413b9e96a 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -223,12 +223,13 @@ done
# test compilation with minimal x86 instruction set
# Set the install path for libraries to "lib" explicitly to prevent problems
# with pkg-config prefixes if installed in "lib/x86_64-linux-gnu" later.
-default_machine='nehalem'
-if ! check_cc_flags "-march=$default_machine" ; then
- default_machine='corei7'
+default_isa='nehalem'
+if ! check_cc_flags "-march=$default_isa" ; then
+ default_isa='corei7'
fi
build build-x86-default cc skipABI -Dcheck_includes=true \
- -Dlibdir=lib -Dmachine=$default_machine $use_shared
+ -Dlibdir=lib -Dcpu_instruction_set=$default_isa \
+ $use_shared
# 32-bit with default compiler
if check_cc_flags '-m32' ; then
diff --git a/me
Re: [dpdk-dev] [PATCH v1 1/1] net/hinic: fix coredump when PMD used by fstack
在 2021/3/23 1:17, Ferruh Yigit 写道:
> On 3/15/2021 8:14 AM, Guoyang Zhou wrote:
>> The fstack will use secondary process to access the memory of
>> eth_dev_ops , and it wants to get the info of dev, but hinic
>> driver does not initialized it when in secondary process.
>>
>
> I guess the issue is not specific to the f-stack, perhaps can generalize the
> patch title.
>
>> Fixes: 66f64dd6dc86 ("net/hinic: fix secondary process")
>> Cc: sta...@dpdk.org
>> Signed-off-by: Guoyang Zhou
>> ---
>> drivers/net/hinic/base/hinic_compat.h | 25 -
>> drivers/net/hinic/hinic_pmd_ethdev.c | 5 +
>> 2 files changed, 13 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/net/hinic/base/hinic_compat.h
>> b/drivers/net/hinic/base/hinic_compat.h
>> index 6dd210e..aea3320 100644
>> --- a/drivers/net/hinic/base/hinic_compat.h
>> +++ b/drivers/net/hinic/base/hinic_compat.h
>> @@ -171,6 +171,7 @@ static inline u32 readl(const volatile void *addr)
>> #else
>> #define CLOCK_TYPE CLOCK_MONOTONIC
>> #endif
>> +#define HINIC_MUTEX_TIMEOUT 10
>> static inline unsigned long clock_gettime_ms(void)
>> {
>> @@ -225,24 +226,14 @@ static inline int hinic_mutex_destroy(pthread_mutex_t
>> *pthreadmutex)
>> static inline int hinic_mutex_lock(pthread_mutex_t *pthreadmutex)
>> {
>> int err;
>> + struct timespec tout;
>> - err = pthread_mutex_lock(pthreadmutex);
>> - if (!err) {
>> - return err;
>> - } else if (err == EOWNERDEAD) {
>> - PMD_DRV_LOG(ERR, "Mutex lock failed. (ErrorNo=%d)", errno);
>> -#if defined(__GLIBC__)
>> -#if __GLIBC_PREREQ(2, 12)
>> - (void)pthread_mutex_consistent(pthreadmutex);
>> -#else
>> - (void)pthread_mutex_consistent_np(pthreadmutex);
>> -#endif
>> -#else
>> - (void)pthread_mutex_consistent(pthreadmutex);
>> -#endif
>> - } else {
>> - PMD_DRV_LOG(ERR, "Mutex lock failed. (ErrorNo=%d)", errno);
>> - }
>> + (void)clock_gettime(CLOCK_TYPE, &tout);
>> +
>> + tout.tv_sec += HINIC_MUTEX_TIMEOUT;
>> + err = pthread_mutex_timedlock(pthreadmutex, &tout);
>> + if (err)
>> + PMD_DRV_LOG(ERR, "Mutex lock failed. (ErrorNo=%d)", err);
>>
>
> Is above change related to the secondary process fix?
>
Yes, the hinic_mutex_lock function is related to the secondary process fix.
Becasue I found if do not fix it, when a lot of secondary processes calls
secondary ops (dev_infos_get), it will cause deadlock in low probability.
>> return err;
>> }
>> diff --git a/drivers/net/hinic/hinic_pmd_ethdev.c
>> b/drivers/net/hinic/hinic_pmd_ethdev.c
>> index 1d6b710..057e7b1 100644
>> --- a/drivers/net/hinic/hinic_pmd_ethdev.c
>> +++ b/drivers/net/hinic/hinic_pmd_ethdev.c
>> @@ -3085,6 +3085,10 @@ static int hinic_dev_close(struct rte_eth_dev *dev)
>> .filter_ctrl = hinic_dev_filter_ctrl,
>> };
>> +static const struct eth_dev_ops hinic_dev_sec_ops = {
>> + .dev_infos_get = hinic_dev_infos_get,
>> +};
>> +
>> static int hinic_func_init(struct rte_eth_dev *eth_dev)
>> {
>> struct rte_pci_device *pci_dev;
>> @@ -3099,6 +3103,7 @@ static int hinic_func_init(struct rte_eth_dev *eth_dev)
>> /* EAL is SECONDARY and eth_dev is already created */
>> if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
>> + eth_dev->dev_ops = &hinic_dev_sec_ops;
>
> Why not using existing dev_ops but creating a new one?
>
>> PMD_DRV_LOG(INFO, "Initialize %s in secondary process",
>> eth_dev->data->name);
>>
>
> .
Because many interfaces do not support calling from the secondary process due to
hardware reason, and from the current test situation, it does not be needed.
Regards,
Guoyang Zhou
Re: [dpdk-dev] [PATCH] ethdev: update qfi definition
On 3/29/2021 10:06 AM, Raslan Darawsheh wrote:
Hi,
-Original Message-
From: Ori Kam
Sent: Monday, March 29, 2021 11:53 AM
To: Ferruh Yigit ; Raslan Darawsheh
; dev@dpdk.org; Andrew Rybchenko
; Ivan Malov
Cc: Slava Ovsiienko ; Shiri Kuzin
; ying.a.w...@intel.com; sta...@dpdk.org; NBU-
Contact-Thomas Monjalon ; Olivier Matz
Subject: RE: [dpdk-dev] [PATCH] ethdev: update qfi definition
Hi
-Original Message-
From: dev On Behalf Of Ferruh Yigit
Subject: Re: [dpdk-dev] [PATCH] ethdev: update qfi definition
On 3/23/2021 12:11 PM, Raslan Darawsheh wrote:
qfi field is 8 bits which represent single bit for
PPP (paging Policy Presence) single bit for RQI
(Reflective QoS Indicator) and 6 bits for qfi
(QoS Flow Identifier)
Can you please put a reference for above information?
Sure, will send in V2,
This update the doxygen format and the mask for qfi
to properly identify the full 8 bits of the field.
note: changing the default mask would cause different
patterns generated by testpmd.
Fixes: 346553db5bd1 ("ethdev: add GTP extension header to flow API")
Cc: ying.a.w...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Raslan Darawsheh
---
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 ++-
lib/librte_ethdev/rte_flow.h| 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index f59eb8a27d..dd39c4c3c2 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3742,7 +3742,8 @@ This section lists supported pattern items and
their
attributes, if any.
- ``gtp_psc``: match GTP PDU extension header with type 0x85.
- ``pdu_type {unsigned}``: PDU type.
- - ``qfi {unsigned}``: QoS flow identifier.
+
+ - ``qfi {unsigned}``: PPP, RQI and QoS flow identifier.
- ``pppoes``, ``pppoed``: match PPPoE header.
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index 669e677e91..79106e0246 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -1392,14 +1392,14 @@ static const struct rte_flow_item_meta
rte_flow_item_meta_mask = {
*/
struct rte_flow_item_gtp_psc {
uint8_t pdu_type; /**< PDU type. */
- uint8_t qfi; /**< QoS flow identifier. */
+ uint8_t qfi; /**< PPP, RQI, QoS flow identifier. */
};
By design requirement, rte_flow_item_* should start with the relevant
protocol
header.
There is already a deprecation notice for using protocol header directly in
the
rte_flow_item* [1] and Adrew/Ivan already fixed a few of them [2].
Your patch is not directly related on this, but since you are touching to the
flow_item, would you mind create a protocol struct for it first, and use it in
the "struct rte_flow_item_gtp_psc"?
So the protocol related update can be done in the protocol header, instead
of
rte_flow struct.
+1
Sure, I can create the new protocol and use it , and will send in V2. But,
wouldn't it cause any ABI breakage ?
For the protocol header, it won't be problem since it is a new struct.
For the flow item struct, it may be, that is why need to use a union for now,
please check what Adrew/Ivan did.
[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.d
pdk.
org%2Fdpdk%2Ftree%2Fdoc%2Fguides%2Frel_notes%2Fdeprecation.rst%3F
h%3
Dv21.02%23n99&data=04%7C01%7Corika%40nvidia.com%7C6391a4c064
0
f4592b70b08d8f058e322%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0
%7C637523611870497932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
w
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sda
t
a=vU%2F5oO47zb9erTnZL1pl9j0nHCKzea3NJgOeo1FTW0Q%3D&reserve
d=
0
[2]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.d
pdk.
org%2Fnext%2Fdpdk-next-
net%2Fcommit%2F%3Fid%3D4a061a7bd70bfa023de23e8e654e&data=0
4%
7C01%7Corika%40nvidia.com%7C6391a4c0640f4592b70b08d8f058e322%7C43
083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637523611870497932%7CU
nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
6Ik
1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WurlQ5VSLqFGVthfRj363xZs
C
No3xJuvxNQCFVcxdkk%3D&reserved=0
Re: [dpdk-dev] Questions about reporting auto-negotiation capability
在 2021/3/29 15:19, Thomas Monjalon 写道: 29/03/2021 09:03, Thomas Monjalon: 29/03/2021 06:02, Huisong Li: 'speed_capa' in struct rte_eth_dev_info is defined as follows: uint32_t speed_capa; /**< Supported speeds bitmap (ETH_LINK_SPEED_). */ Most PMD drivers use this field to report the speeds capability supported by the device to the upper-layer app. But it seems that few NICs report their auto-negotiation capability through this field. If NIC also uses it to report their auto-negotiation capability through this field, and should set it to ETH_LINK_SPEED_AUTONEG(0) based on the definition of ETH_LINK_SPEED_xxx. In this case, it conflicts the report of the speeds capability . I don't know how to correctly report the auto-negotiation capability of the device. Thanks for your reply. ETH_LINK_SPEED_AUTONEG is not for capabilities. Anyway, if it is set, it changes nothing (0) in the bitmap. I see mlx5 is wrongly using it. speed_capa is only for enumerating speeds. I see some drivers are advertising ETH_LINK_SPEED_FIXED in speed_capa if the device cannot support autonegotiation. Should we add a note in doxygen? Can we use bit 0 to indicate whether the device supports auto-negotiation? Like, 1/ If device doesn't support auto-negotiation, set bit(0) of the 'speed_capa' to 1, namely, "speed_capa |= ETH_LINK_SPEED_FIXED". 2/ Other bits of the 'speed_capa' report all the speed capabilities supported by the device regardless of the value of bit(0) . The above behavior is similar to cxgbe, bnxt, and mlx5. In this way, users can know whether the device supports auto-negotiation based on bit(0) and detect the supported speed capabilities based on other bits. After all, this 'speed_capa' and the 'link_speeds' in "rte_eth_conf" struct have different purposes. .
[dpdk-dev] rte_flow ageing
Hi, I've found out the pretty useful experimental brand new flow ageing API implemented in the mlx5 PMD. I'm trying it (rte_eth_dev_callback_register(RTE_ETH_EVENT_FLOW_AGED), RTE_FLOW_ACTION_TYPE_AGE) to recover any flow that I previously offloaded. The DPDK version is 20.08 and Mellanox(Connect-X6) OFED drivers are 5.1-2.5.8.0. I eventually don't see the usefulness of the callback since it's actually triggered indirectly by us(the DPDK application) when calling rte_flow_get_aged_flows(). If we don't call it, the callback is called only once. And, calling rte_flow_get_aged_flows() from the callback won't trigger it next time(MLX5_AGE_TRIGGER is reset after the callback call) Furthermore, I don't see the point of computing ageing flows in mlx5_fow.c::mlx5_flow_aging_check() if the client callback isn't called. So far, I can handle the flow ageing from the same thread as the one which is handling the flow direction(rte_flow), it even avoid threads synchronization. But, in the future, I may need to be noticed as soon as possible of a single flow ageing, and thus handle this flow logic from the ageing callback. I may misunderstand the whole ageing API... Thanks a lot for any clarification.
Re: [dpdk-dev] Questions about reporting auto-negotiation capability
29/03/2021 13:44, Huisong Li: > > 在 2021/3/29 15:19, Thomas Monjalon 写道: > > 29/03/2021 09:03, Thomas Monjalon: > >> 29/03/2021 06:02, Huisong Li: > >>> 'speed_capa' in struct rte_eth_dev_info is defined as follows: > >>> > >>> uint32_t speed_capa; /**< Supported speeds bitmap (ETH_LINK_SPEED_). */ > >>> > >>> > >>> Most PMD drivers use this field to report the speeds capability > >>> supported by the device to the upper-layer app. > >>> > >>> But it seems that few NICs report their auto-negotiation capability > >>> through this field. If NIC also uses it to report > >>> their auto-negotiation capability through this field, and should set it > >>> to ETH_LINK_SPEED_AUTONEG(0) based on > >>> the definition of ETH_LINK_SPEED_xxx. In this case, it conflicts the > >>> report of the speeds capability . > >>> > >>> I don't know how to correctly report the auto-negotiation capability of > >>> the device. Thanks for your reply. > >> ETH_LINK_SPEED_AUTONEG is not for capabilities. > >> Anyway, if it is set, it changes nothing (0) in the bitmap. > >> I see mlx5 is wrongly using it. > >> > >> speed_capa is only for enumerating speeds. > > I see some drivers are advertising ETH_LINK_SPEED_FIXED in speed_capa > > if the device cannot support autonegotiation. > > Should we add a note in doxygen? > > Can we use bit 0 to indicate whether the device supports auto-negotiation? > > Like, > > 1/ If device doesn't support auto-negotiation, set bit(0) of the > 'speed_capa' to 1, namely, "speed_capa |= ETH_LINK_SPEED_FIXED". Yes I think this is what FIXED means: cannot negotiate. > 2/ Other bits of the 'speed_capa' report all the speed capabilities > supported by the device regardless of the value of bit(0) . > > The above behavior is similar to cxgbe, bnxt, and mlx5. In this way, > users can know whether the device supports auto-negotiation > > based on bit(0) and detect the supported speed capabilities based on > other bits. > > After all, this 'speed_capa' and the 'link_speeds' in "rte_eth_conf" > struct have different purposes.
Re: [dpdk-dev] [EXTERNAL] Re: Handling missing export functions in MSVC linkage
Unless I misunderstood the last status of this issue was that it was desired empty stubs that fail at runtime as opposed to conditionally generating exports. Is this no longer the case? -Original Message- From: Thomas Monjalon Sent: Friday, March 26, 2021 1:40 AM To: Dmitry Kozlyuk ; ranjit.menon ; Kadam, Pallavi ; Harini Ramakrishnan ; navas...@linux.microsoft.com; Dmitry Malloy Cc: dev@dpdk.org; talshn ; bruce.richard...@intel.com; David Marchand ; Tyler Retzlaff ; Omar Cardona Subject: [EXTERNAL] Re: [dpdk-dev] Handling missing export functions in MSVC linkage 08/06/2020 10:33, David Marchand: > On Mon, Jun 8, 2020 at 2:09 AM Dmitry Kozlyuk > wrote: > > On Sun, 7 Jun 2020 12:26:56 + > > If you create a .def manually, it will override the generation from > > .map. Of cause, this adds manual work and ideally all .def files should be > > generated. > > On this topic, I just noticed that a patch of mine, that removed > rte_eal_get_configuration() from the stable ABI, missed the > declaration in rte_eal_exports.def. > Probably worth adding a check in devtools/, to avoid further misalignment. The .def file keeps being out of sync. We need a script to avoid forgetting the sync, or/and we must generate this .def from the .map. Ideally the full EAL API (except VFIO) should be implemented for Windows. This situation is waiting for a solution for too much time. Windows maintainers, please solve it.
Re: [dpdk-dev] [PATCH v2] ethdev: introduce enable_driver_sdk to install driver headers
29/03/2021 11:43, Ferruh Yigit: > On 3/26/2021 8:52 PM, Tyler Retzlaff wrote: > > On Fri, Mar 26, 2021 at 12:02:55PM +, Ferruh Yigit wrote: > >> On 3/24/2021 4:24 PM, Tyler Retzlaff wrote: > >>> On Wed, Mar 24, 2021 at 12:30:36PM +0100, Thomas Monjalon wrote: > 24/03/2021 12:27, Ferruh Yigit: > > > > But not sure how to manage the same problem for whole project, if > > install all > > headers in one patch, or add them gradually via separate patches by > > time ... > > We did a cleanup in ethdev but not in other driver classes. > When the cleanup will be done gradually, the headers > must move in this new category driver_sdk_headers. > >>> > >>> yes, some headers are not installed now. so they need only to have > >>> their api marked __rte_internal and installed (since there should be no > >>> external consumer as a function of not being installed) > >>> > >>> the more difficult case is where headers were installed but the api were > >>> not marked __rte_internal and appear in the stable version.map. for > >>> those i guess deprecation notice has to be issued before marking as > >>> internal. > >>> > >> > >> Are you referring to any specific APIs, can you share list of them? > > > > i can't remember the whole list but Thomas originally indicated the > > following candidate list. > > > > baseband/ -> librte_bbdev/rte_bbdev_pmd.h > > bus/ -> rte_bus.h > > common/ -> no interface > > crypto/ -> librte_cryptodev/rte_cryptodev_pmd.h > > event/ -> librte_eventdev/ > > mempool/ -> librte_mempool/ > > net/ -> librte_ethdev/ > > raw/ -> librte_rawdev/rte_rawdev_pmd.h > > regex/ -> librte_regexdev/rte_regexdev_driver.h > > vdpa/ -> librte_vhost/rte_vdpa_dev.h > > > > some of these headers are not published, some are. > > > > These are public headers, so they should not have '__rte_internal' functions, > are you saying some of public headers has internal functions that are > presented > as public APIs? These are the headers for use by the drivers. We should classify them as SDK headers, not API.
Re: [dpdk-dev] [PATCH v2] vhost: add support for packed ring in async vhost
Hi,
> -Original Message-
> From: Liu, Yong
> Sent: Wednesday, March 24, 2021 5:19 PM
> To: Jiang, Cheng1 ; maxime.coque...@redhat.com;
> Xia, Chenbo
> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> ; Wang, Yinan ; Jiang,
> Cheng1
> Subject: RE: [dpdk-dev] [PATCH v2] vhost: add support for packed ring in
> async vhost
>
>
>
> > -Original Message-
> > From: dev On Behalf Of Cheng Jiang
> > Sent: Monday, March 22, 2021 2:15 PM
> > To: maxime.coque...@redhat.com; Xia, Chenbo
> > Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> > ; Wang, Yinan ; Jiang,
> > Cheng1
> > Subject: [dpdk-dev] [PATCH v2] vhost: add support for packed ring in
> > async vhost
> >
> > For now async vhost data path only supports split ring structure. In
> > order to make async vhost compatible with virtio 1.1 spec this patch
> > enables packed ring in async vhost data path.
> >
> > Signed-off-by: Cheng Jiang
> > ---
> > v2:
> > * fix wrong buffer index in rte_vhost_poll_enqueue_completed()
> > * add async_buffers_packed memory free in vhost_free_async_mem()
> >
> > lib/librte_vhost/rte_vhost_async.h | 1 +
> > lib/librte_vhost/vhost.c | 24 +-
> > lib/librte_vhost/vhost.h | 7 +-
> > lib/librte_vhost/virtio_net.c | 447 +++--
> > 4 files changed, 441 insertions(+), 38 deletions(-)
> >
> > diff --git a/lib/librte_vhost/rte_vhost_async.h
> > b/lib/librte_vhost/rte_vhost_async.h
> > index c855ff875..6faa31f5a 100644
> > --- a/lib/librte_vhost/rte_vhost_async.h
> > +++ b/lib/librte_vhost/rte_vhost_async.h
> > @@ -89,6 +89,7 @@ struct rte_vhost_async_channel_ops { struct
> > async_inflight_info { struct rte_mbuf *mbuf; uint16_t descs; /* num
> > of descs inflight */
> > +uint16_t nr_buffers; /* num of buffers inflight for packed ring */
> > };
> >
> > /**
> > diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c index
> > 52ab93d1e..51b44d6f2 100644
> > --- a/lib/librte_vhost/vhost.c
> > +++ b/lib/librte_vhost/vhost.c
> > @@ -330,15 +330,20 @@ vhost_free_async_mem(struct vhost_virtqueue
> > *vq)
> > {
> > if (vq->async_pkts_info)
> > rte_free(vq->async_pkts_info);
> > -if (vq->async_descs_split)
> > +if (vq->async_buffers_packed) {
> > +rte_free(vq->async_buffers_packed);
> > +vq->async_buffers_packed = NULL;
> > +} else {
> > rte_free(vq->async_descs_split);
> > +vq->async_descs_split = NULL;
> > +}
> > +
> > if (vq->it_pool)
> > rte_free(vq->it_pool);
> > if (vq->vec_pool)
> > rte_free(vq->vec_pool);
> >
> > vq->async_pkts_info = NULL;
> > -vq->async_descs_split = NULL;
> > vq->it_pool = NULL;
> > vq->vec_pool = NULL;
> > }
> > @@ -1603,9 +1608,9 @@ int rte_vhost_async_channel_register(int vid,
> > uint16_t queue_id, return -1;
> >
> > /* packed queue is not supported */
> > -if (unlikely(vq_is_packed(dev) || !f.async_inorder)) {
> > +if (unlikely(!f.async_inorder)) {
> > VHOST_LOG_CONFIG(ERR,
> > -"async copy is not supported on packed queue or non-inorder mode "
> > +"async copy is not supported on non-inorder mode "
> > "(vid %d, qid: %d)\n", vid, queue_id); return -1; } @@ -1643,10
> > +1648,17 @@ int rte_vhost_async_channel_register(int vid, uint16_t
> > queue_id, vq->vec_pool = rte_malloc_socket(NULL,
> VHOST_MAX_ASYNC_VEC
> > * sizeof(struct iovec), RTE_CACHE_LINE_SIZE, node);
> > -vq->async_descs_split = rte_malloc_socket(NULL,
> > +if (vq_is_packed(dev)) {
> > +vq->async_buffers_packed = rte_malloc_socket(NULL, size *
> > +vq->sizeof(struct vring_used_elem_packed),
> > +RTE_CACHE_LINE_SIZE, node);
> > +} else {
> > +vq->async_descs_split = rte_malloc_socket(NULL,
> > vq->size * sizeof(struct vring_used_elem), RTE_CACHE_LINE_SIZE,
> > node); -if (!vq->async_descs_split || !vq->async_pkts_info ||
> > +}
> > +
> > +if (!vq->async_pkts_info ||
> > !vq->it_pool || !vq->vec_pool) {
> > vhost_free_async_mem(vq);
> > VHOST_LOG_CONFIG(ERR,
> > diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h index
> > 658f6fc28..d6324fbf8 100644
> > --- a/lib/librte_vhost/vhost.h
> > +++ b/lib/librte_vhost/vhost.h
> > @@ -206,9 +206,14 @@ struct vhost_virtqueue { uint16_tasync_pkts_idx;
> > uint16_tasync_pkts_inflight_n; uint16_tasync_last_pkts_n; -struct
> > vring_used_elem *async_descs_split;
> > +union {
> > +struct vring_used_elem *async_descs_split; struct
> > +vring_used_elem_packed *async_buffers_packed; };
> > uint16_t async_desc_idx;
> > +uint16_t async_packed_buffer_idx;
> > uint16_t last_async_desc_idx;
> > +uint16_t last_async_buffer_idx;
> >
> > /* vq async features */
> > boolasync_inorder;
> > diff --git a/lib/librte_vhost/virtio_net.c
> > b/lib/librte_vhost/virtio_net.c index 583bf379c..fa8c4f4fe 100644
> > --- a/lib/librte_vhost/virtio_net.c
> > +++ b/lib/librte_vhost/virtio_net.c
> > @@ -363,8 +363,7 @@
> > vhost_shadow_dequeue_single_packed_inorder(struct vhost_virtqueue
> *vq,
> > }
> >
> > static __rte_always_inline void
> > -vhost_shadow_enqueue_single_packed(struct virtio_net *dev,
> > -
Re: [dpdk-dev] rte_flow ageing
Sorry for the below topic confusion(in-reply-to). On 3/29/21 9:50 AM, David Bouyeure wrote: Hi, I've found out the pretty useful experimental brand new flow ageing API implemented in the mlx5 PMD. I'm trying it (rte_eth_dev_callback_register(RTE_ETH_EVENT_FLOW_AGED), RTE_FLOW_ACTION_TYPE_AGE) to recover any flow that I previously offloaded. The DPDK version is 20.08 and Mellanox(Connect-X6) OFED drivers are 5.1-2.5.8.0. I eventually don't see the usefulness of the callback since it's actually triggered indirectly by us(the DPDK application) when calling rte_flow_get_aged_flows(). If we don't call it, the callback is called only once. And, calling rte_flow_get_aged_flows() from the callback won't trigger it next time(MLX5_AGE_TRIGGER is reset after the callback call) Furthermore, I don't see the point of computing ageing flows in mlx5_fow.c::mlx5_flow_aging_check() if the client callback isn't called. So far, I can handle the flow ageing from the same thread as the one which is handling the flow direction(rte_flow), it even avoid threads synchronization. But, in the future, I may need to be noticed as soon as possible of a single flow ageing, and thus handle this flow logic from the ageing callback. I may misunderstand the whole ageing API... Thanks a lot for any clarification.
[dpdk-dev] rte_flow ageing
Hi, I've found out the pretty useful experimental brand new flow ageing API implemented in the mlx5 PMD. I'm trying it (rte_eth_dev_callback_register(RTE_ETH_EVENT_FLOW_AGED), RTE_FLOW_ACTION_TYPE_AGE) to recover any flow that I previously offloaded. The DPDK version is 20.08 and Mellanox(Connect-X6) OFED drivers are 5.1-2.5.8.0. I eventually don't see the usefulness of the callback since it's actually triggered indirectly by us(the DPDK application) when calling rte_flow_get_aged_flows(). If we don't call it, the callback is called only once. And, calling rte_flow_get_aged_flows() from the callback won't trigger it next time(MLX5_AGE_TRIGGER is reset after the callback call) Furthermore, I don't see the point of computing ageing flows in mlx5_fow.c::mlx5_flow_aging_check() if the client callback isn't called. So far, I can handle the flow ageing from the same thread as the one which is handling the flow direction(rte_flow), it even avoid threads synchronization. But, in the future, I may need to be noticed as soon as possible of a single flow ageing, and thus handle this flow logic from the ageing callback. I may misunderstand the whole ageing API... Thanks a lot for any clarification.
Re: [dpdk-dev] [PATCH v3] net/ixgbe: fix RSS RETA be reset after port start
> -Original Message-
> From: Yang, MurphyX
> Sent: Monday, March 29, 2021 16:29
> To: dev@dpdk.org
> Cc: Yang, Qiming ; Wang, Haiyue
> ; Guo, Jia
> ; Yang, SteveX ; Zhang, RobinX
> ;
> Yang, MurphyX
> Subject: [PATCH v3] net/ixgbe: fix RSS RETA be reset after port start
>
> If one calls ‘rte_eth_dev_rss_reta_update’ with ixgbe before starting
> the device (but after setting everything else), then RSS RETA
> configuration be zero after starting the device.
>
> This patch gives a notification if the port not started.
>
> Bugzilla ID: 664
> Fixes: 249358424eab ("ixgbe: RSS RETA configuration")
>
> Signed-off-by: Murphy Yang
> ---
> v3:
> - modify the notify message
> v2:
> - tune the return value
> drivers/net/ixgbe/ixgbe_ethdev.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 8a9a21e7c2..d8ef618e5f 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
Acked-by: Haiyue Wang
> --
> 2.17.1
[dpdk-dev] [PATCH v4] build: add platform meson option
The current meson option 'machine' should only specify the ISA, which is
not sufficient for Arm, where setting ISA implies other setting as well.
Add a new meson option, 'platform', which differentiates the type of the
build (native/generic) and sets machine accordingly, unless the user
chooses to override it.
The 'machine' option also doesn't describe very well what it sets, so
introduce a new option 'cpu_instruction_set', but keep 'machine' for
backwards compatibility.
These two new variables, taken together, achieve what 'machine' was
setting per architecture - setting the ISA in x86 build and setting
native/default 'build type' in aarch64 build - is now properly being set
for all architectures in a uniform manner.
Signed-off-by: Juraj Linkeš
---
config/arm/meson.build| 6 ++---
config/meson.build| 47 +--
devtools/test-meson-builds.sh | 9 ---
meson_options.txt | 8 --
4 files changed, 48 insertions(+), 22 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 00bc4610a3..e3a23c4228 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -208,7 +208,7 @@ if dpdk_conf.get('RTE_ARCH_32')
else
# aarch64 build
if not meson.is_cross_build()
- if machine == 'default'
+ if platform == 'generic'
# default build
implementer_id = 'generic'
part_number = 'generic'
@@ -238,7 +238,7 @@ else
else
error('Unsupported Arm implementer: @0@.
'.format(implementer_id) +
'Please add support for it or use the generic ' +
- '(-Dmachine=generic) build.')
+ '(-Dplatform=generic) build.')
endif
message('Arm implementer: ' + implementer_config['description'])
@@ -253,7 +253,7 @@ else
error('Unsupported part number @0@ of implementer @1@. '
.format(part_number, implementer_id) +
'Please add support for it or use the generic ' +
- '(-Dmachine=generic) build.')
+ '(-Dplatform=generic) build.')
endif
# use default flags with implementer flags
diff --git a/config/meson.build b/config/meson.build
index 66a2edcc47..32c9e18c17 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -63,42 +63,63 @@ if not is_windows
pmd_subdir_opt)
endif
-# set the machine type and cflags for it
+platform = get_option('platform')
+
+# set the cpu_instruction_set type and cflags for it
if meson.is_cross_build()
- machine = host_machine.cpu()
+ cpu_instruction_set = host_machine.cpu()
else
- machine = get_option('machine')
+ cpu_instruction_set = get_option('cpu_instruction_set')
+ if get_option('machine') != 'auto'
+ warning('The "machine" option is deprecated. ' +
+ 'Please use "cpu_instruction_set" instead.')
+ if cpu_instruction_set != 'auto'
+ error('Setting both "machine" and ' +
+ '"cpu_instruction_set" is unsupported.')
+ endif
+ cpu_instruction_set = get_option('machine')
+ endif
+endif
+
+if platform == 'native'
+ if cpu_instruction_set == 'auto'
+ cpu_instruction_set = 'native'
+ endif
+elif platform == 'generic'
+ if cpu_instruction_set == 'auto'
+ cpu_instruction_set = 'default'
+ endif
endif
-# machine type 'default' is special, it defaults to the per arch agreed common
+if cpu_instruction_set == 'default'
+# cpu_instruction_set type 'default' is special, it defaults to the per arch
agreed common
# minimal baseline needed for DPDK.
# That might not be the most optimized, but the most portable version while
# still being able to support the CPU features required for DPDK.
# This can be bumped up by the DPDK project, but it can never be an
# invariant like 'native'
-if machine == 'default'
if host_machine.cpu_family().startswith('x86')
# matches the old pre-meson build systems default
- machine = 'corei7'
+ cpu_instruction_set = 'corei7'
elif host_machine.cpu_family().startswith('arm')
- machine = 'armv7-a'
+ cpu_instruction_set = 'armv7-a'
elif host_machine.cpu_family().startswith('aarch')
# arm64 manages defaults in config/arm/meson.build
- machine = 'default'
+ cpu_instruction_set = 'default'
elif host_machine.cpu_family().startswith('ppc')
- machine = 'power8'
+ cpu_instruction_set = 'power8'
endif
endif
-dpdk_conf.set('RTE_MACHINE', machine)
+dpdk_conf.set('RTE_MACHINE', cpu_instruction_set)
machine_args = []
# ppc64 does not support -march= at all, us
[dpdk-dev] [PATCH 0/8] ice: base code update batch 2
Qi Zhang (8): net/ice/base: code cleanup net/ice/base: support removing VSI from flow profile net/ice/base: print link configure error net/ice/base: remove unused ptype field in PTT definition net/ice/base: set MAC type for E823C device net/ice/base: change protocol ID for VLAN in case of DVM net/ice/base: enable I2C read/write commands net/ice/base: add RSS support for PPPoL2TPv2oUDP drivers/net/ice/base/ice_adminq_cmd.h| 29 ++ drivers/net/ice/base/ice_common.c| 104 +++- drivers/net/ice/base/ice_common.h| 8 ++ drivers/net/ice/base/ice_dcb.c | 2 +- drivers/net/ice/base/ice_fdir.c | 2 +- drivers/net/ice/base/ice_flex_pipe.c | 4 +- drivers/net/ice/base/ice_flow.c | 120 --- drivers/net/ice/base/ice_flow.h | 4 + drivers/net/ice/base/ice_lan_tx_rx.h | 10 +- drivers/net/ice/base/ice_protocol_type.h | 1 + drivers/net/ice/base/ice_sched.c | 11 +-- drivers/net/ice/base/ice_switch.c| 34 +-- drivers/net/ice/base/ice_switch.h| 1 + drivers/net/ice/base/ice_type.h | 2 - drivers/net/ice/base/ice_vlan_mode.c | 3 +- 15 files changed, 289 insertions(+), 46 deletions(-) -- 2.26.2
[dpdk-dev] [PATCH 1/8] net/ice/base: code cleanup
1. There are a lots of function header mismatch its function name. 2. remove unnecessary header file include. 3. remove unnecessary macro. 4. remove unnecessary comment. Signed-off-by: Dave Ertman Signed-off-by: Qi Zhang --- drivers/net/ice/base/ice_common.c| 4 ++-- drivers/net/ice/base/ice_dcb.c | 2 +- drivers/net/ice/base/ice_fdir.c | 2 +- drivers/net/ice/base/ice_flex_pipe.c | 1 - drivers/net/ice/base/ice_sched.c | 11 +-- drivers/net/ice/base/ice_switch.c| 15 +++ drivers/net/ice/base/ice_type.h | 2 -- drivers/net/ice/base/ice_vlan_mode.c | 3 +-- 8 files changed, 17 insertions(+), 23 deletions(-) diff --git a/drivers/net/ice/base/ice_common.c b/drivers/net/ice/base/ice_common.c index 1546309da1..65018690c2 100644 --- a/drivers/net/ice/base/ice_common.c +++ b/drivers/net/ice/base/ice_common.c @@ -638,7 +638,7 @@ ice_cleanup_fltr_mgmt_single(struct ice_hw *hw, struct ice_switch_info *sw) } /** - * ice_cleanup_all_fltr_mgmt - cleanup filter management list and locks + * ice_cleanup_fltr_mgmt_struct - cleanup filter management list and locks * @hw: pointer to the HW struct */ void ice_cleanup_fltr_mgmt_struct(struct ice_hw *hw) @@ -4903,7 +4903,7 @@ ice_aq_set_lldp_mib(struct ice_hw *hw, u8 mib_type, void *buf, u16 buf_size, } /** - * ice_fw_supports_lldp_fltr - check NVM version supports lldp_fltr_ctrl + * ice_fw_supports_lldp_fltr_ctrl - check NVM version supports lldp_fltr_ctrl * @hw: pointer to HW struct */ bool ice_fw_supports_lldp_fltr_ctrl(struct ice_hw *hw) diff --git a/drivers/net/ice/base/ice_dcb.c b/drivers/net/ice/base/ice_dcb.c index 7a85e56abf..d5e2cb6e5d 100644 --- a/drivers/net/ice/base/ice_dcb.c +++ b/drivers/net/ice/base/ice_dcb.c @@ -857,7 +857,7 @@ ice_cee_to_dcb_cfg(struct ice_aqc_get_cee_dcb_cfg_resp *cee_cfg, } /** - * ice_get_ieee_dcb_cfg + * ice_get_ieee_or_cee_dcb_cfg * @pi: port information structure * @dcbx_mode: mode of DCBX (IEEE or CEE) * diff --git a/drivers/net/ice/base/ice_fdir.c b/drivers/net/ice/base/ice_fdir.c index 2b39c13127..8f9c0d346b 100644 --- a/drivers/net/ice/base/ice_fdir.c +++ b/drivers/net/ice/base/ice_fdir.c @@ -1845,7 +1845,7 @@ bool ice_fdir_has_frag(enum ice_fltr_ptype flow) } /** - * ice_fdir_find_by_idx - find filter with idx + * ice_fdir_find_fltr_by_idx - find filter with idx * @hw: pointer to hardware structure * @fltr_idx: index to find. * diff --git a/drivers/net/ice/base/ice_flex_pipe.c b/drivers/net/ice/base/ice_flex_pipe.c index f429bfb0d1..90264240c4 100644 --- a/drivers/net/ice/base/ice_flex_pipe.c +++ b/drivers/net/ice/base/ice_flex_pipe.c @@ -357,7 +357,6 @@ ice_marker_ptype_tcam_handler(u32 sect_type, void *section, u32 index, if (sect_type != ICE_SID_RXPARSER_MARKER_PTYPE) return NULL; - /* cppcheck-suppress nullPointer */ if (index > ICE_MAX_MARKER_PTYPE_TCAMS_IN_BUF) return NULL; diff --git a/drivers/net/ice/base/ice_sched.c b/drivers/net/ice/base/ice_sched.c index 38d1f2cc54..be3f56cdf6 100644 --- a/drivers/net/ice/base/ice_sched.c +++ b/drivers/net/ice/base/ice_sched.c @@ -1984,7 +1984,7 @@ ice_sched_cfg_vsi(struct ice_port_info *pi, u16 vsi_handle, u8 tc, u16 maxqs, } /** - * ice_sched_rm_agg_vsi_entry - remove aggregator related VSI info entry + * ice_sched_rm_agg_vsi_info - remove aggregator related VSI info entry * @pi: port information structure * @vsi_handle: software VSI handle * @@ -3360,7 +3360,7 @@ ice_cfg_vsi_bw_lmt_per_tc(struct ice_port_info *pi, u16 vsi_handle, u8 tc, } /** - * ice_cfg_dflt_vsi_bw_lmt_per_tc - configure default VSI BW limit per TC + * ice_cfg_vsi_bw_dflt_lmt_per_tc - configure default VSI BW limit per TC * @pi: port information structure * @vsi_handle: software VSI handle * @tc: traffic class @@ -3515,7 +3515,7 @@ ice_cfg_agg_bw_no_shared_lmt(struct ice_port_info *pi, u32 agg_id) } /** - * ice_cfg_agg_bw_shared_lmt_per_tc - configure aggregator BW shared limit per tc + * ice_cfg_agg_bw_shared_lmt_per_tc - config aggregator BW shared limit per tc * @pi: port information structure * @agg_id: aggregator ID * @tc: traffic class @@ -3535,7 +3535,7 @@ ice_cfg_agg_bw_shared_lmt_per_tc(struct ice_port_info *pi, u32 agg_id, u8 tc, } /** - * ice_cfg_agg_bw_shared_lmt_per_tc - configure aggregator BW shared limit per tc + * ice_cfg_agg_bw_no_shared_lmt_per_tc - cfg aggregator BW shared limit per tc * @pi: port information structure * @agg_id: aggregator ID * @tc: traffic class @@ -3553,7 +3553,7 @@ ice_cfg_agg_bw_no_shared_lmt_per_tc(struct ice_port_info *pi, u32 agg_id, u8 tc) } /** - * ice_config_vsi_queue_priority - config VSI queue priority of node + * ice_cfg_vsi_q_priority - config VSI queue priority of node * @pi: port information structure * @num_qs: number of VSI queues * @q_ids: queue IDs array @@ -3649,7 +3649,6 @@ ice_cfg_agg_vsi_priority_per_tc(struct ice_port_info *pi, u32 agg_id,
[dpdk-dev] [PATCH 2/8] net/ice/base: support removing VSI from flow profile
Adding a function ice_flow_rem_vsi_prof() to remove flow entries
associated to the sw vsi handle. Once complete clear the vsi index from
the flow profile bitmap. This will ensure that the a vsi once removed
can be re-added and the package block rules will be added again.
Signed-off-by: Vignesh Sridhar
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_flow.c | 55 +
drivers/net/ice/base/ice_flow.h | 2 ++
2 files changed, 57 insertions(+)
diff --git a/drivers/net/ice/base/ice_flow.c b/drivers/net/ice/base/ice_flow.c
index d123206fc6..20650b8a7b 100644
--- a/drivers/net/ice/base/ice_flow.c
+++ b/drivers/net/ice/base/ice_flow.c
@@ -3295,6 +3295,61 @@ ice_flow_add_fld_raw(struct ice_flow_seg_info *seg, u16
off, u8 len,
seg->raws_cnt++;
}
+/**
+ * ice_flow_rem_vsi_prof - remove vsi from flow profile
+ * @hw: pointer to the hardware structure
+ * @blk: classification stage
+ * @vsi_handle: software VSI handle
+ * @prof_id: unique ID to identify this flow profile
+ *
+ * This function removes the flow entries associated to the input
+ * vsi handle and disassociates the vsi from the flow profile.
+ */
+enum ice_status ice_flow_rem_vsi_prof(struct ice_hw *hw, enum ice_block blk,
u16 vsi_handle,
+ u64 prof_id)
+{
+ struct ice_flow_prof *prof = NULL;
+ enum ice_status status = ICE_SUCCESS;
+
+ if (blk >= ICE_BLK_COUNT || !ice_is_vsi_valid(hw, vsi_handle))
+ return ICE_ERR_PARAM;
+
+ /* find flow profile pointer with input package block and profile id */
+ prof = ice_flow_find_prof_id(hw, ICE_BLK_FD, prof_id);
+ if (!prof) {
+ ice_debug(hw, ICE_DBG_PKG,
+ "Cannot find flow profile id=%lu\n", prof_id);
+ return ICE_ERR_DOES_NOT_EXIST;
+ }
+
+ /* Remove all remaining flow entries before removing the flow profile */
+ if (!LIST_EMPTY(&prof->entries)) {
+ struct ice_flow_entry *e, *t;
+
+ ice_acquire_lock(&prof->entries_lock);
+ LIST_FOR_EACH_ENTRY_SAFE(e, t, &prof->entries, ice_flow_entry,
+l_entry) {
+ if (e->vsi_handle != vsi_handle)
+ continue;
+
+ status = ice_flow_rem_entry_sync(hw, blk, e);
+ if (status)
+ break;
+ }
+ ice_release_lock(&prof->entries_lock);
+ }
+ if (status)
+ return status;
+
+ /* disassociate the flow profile from sw vsi handle */
+ status = ice_flow_disassoc_prof(hw, blk, prof, vsi_handle);
+ if (status)
+ ice_debug(hw, ICE_DBG_PKG,
+ "ice_flow_disassoc_prof() failed with status=%d\n",
+ status);
+ return status;
+}
+
#define ICE_FLOW_RSS_SEG_HDR_L2_MASKS \
(ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_VLAN)
diff --git a/drivers/net/ice/base/ice_flow.h b/drivers/net/ice/base/ice_flow.h
index c3bce13194..4850249ad3 100644
--- a/drivers/net/ice/base/ice_flow.h
+++ b/drivers/net/ice/base/ice_flow.h
@@ -553,6 +553,8 @@ ice_flow_set_fld_prefix(struct ice_flow_seg_info *seg, enum
ice_flow_field fld,
void
ice_flow_add_fld_raw(struct ice_flow_seg_info *seg, u16 off, u8 len,
u16 val_loc, u16 mask_loc);
+enum ice_status ice_flow_rem_vsi_prof(struct ice_hw *hw, enum ice_block blk,
+ u16 vsi_handle, u64 prof_id);
void ice_rem_vsi_rss_list(struct ice_hw *hw, u16 vsi_handle);
enum ice_status ice_replay_rss_cfg(struct ice_hw *hw, u16 vsi_handle);
enum ice_status
--
2.26.2
[dpdk-dev] [PATCH 3/8] net/ice/base: print link configure error
Newer NVMs return link_cfg_err for get_link_status AQ. Print it for debug use. Signed-off-by: Anirudh Venkataramanan Signed-off-by: Qi Zhang --- drivers/net/ice/base/ice_common.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ice/base/ice_common.c b/drivers/net/ice/base/ice_common.c index 65018690c2..5c21d71b70 100644 --- a/drivers/net/ice/base/ice_common.c +++ b/drivers/net/ice/base/ice_common.c @@ -460,6 +460,7 @@ ice_aq_get_link_info(struct ice_port_info *pi, bool ena_lse, (unsigned long long)li->phy_type_high); ice_debug(hw, ICE_DBG_LINK, " media_type = 0x%x\n", *hw_media_type); ice_debug(hw, ICE_DBG_LINK, " link_info = 0x%x\n", li->link_info); + ice_debug(hw, ICE_DBG_LINK, " link_cfg_err = 0x%x\n", li->link_cfg_err); ice_debug(hw, ICE_DBG_LINK, " an_info = 0x%x\n", li->an_info); ice_debug(hw, ICE_DBG_LINK, " ext_info = 0x%x\n", li->ext_info); ice_debug(hw, ICE_DBG_LINK, " fec_info = 0x%x\n", li->fec_info); -- 2.26.2
[dpdk-dev] [PATCH 4/8] net/ice/base: remove unused ptype field in PTT definition
Remove the unused ptype entry, and use the gcc extension for
ranged initializers in arrays for Linux, and explicitly target
each table entry by index when initializing under Linux.
Signed-off-by: Jesse Brandeburg
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_lan_tx_rx.h | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ice/base/ice_lan_tx_rx.h
b/drivers/net/ice/base/ice_lan_tx_rx.h
index e24a1bb767..696c6a30ae 100644
--- a/drivers/net/ice/base/ice_lan_tx_rx.h
+++ b/drivers/net/ice/base/ice_lan_tx_rx.h
@@ -296,7 +296,6 @@ enum ice_rx_l2_ptype {
};
struct ice_rx_ptype_decoded {
- u32 ptype:10;
u32 known:1;
u32 outer_ip:1;
u32 outer_ip_ver:2;
@@ -1217,8 +1216,7 @@ struct ice_tx_drbell_q_ctx {
/* macro to make the table lines short */
#define ICE_PTT(PTYPE, OUTER_IP, OUTER_IP_VER, OUTER_FRAG, T, TE, TEF, I, PL)\
- { PTYPE, \
- 1, \
+ { 1, \
ICE_RX_PTYPE_OUTER_##OUTER_IP, \
ICE_RX_PTYPE_OUTER_##OUTER_IP_VER, \
ICE_RX_PTYPE_##OUTER_FRAG, \
@@ -1228,14 +1226,14 @@ struct ice_tx_drbell_q_ctx {
ICE_RX_PTYPE_INNER_PROT_##I, \
ICE_RX_PTYPE_PAYLOAD_LAYER_##PL }
-#define ICE_PTT_UNUSED_ENTRY(PTYPE) { PTYPE, 0, 0, 0, 0, 0, 0, 0, 0, 0 }
+#define ICE_PTT_UNUSED_ENTRY(PTYPE) { 0, 0, 0, 0, 0, 0, 0, 0, 0 }
/* shorter macros makes the table fit but are terse */
#define ICE_RX_PTYPE_NOF ICE_RX_PTYPE_NOT_FRAG
#define ICE_RX_PTYPE_FRG ICE_RX_PTYPE_FRAG
-/* Lookup table mapping the HW PTYPE to the bit field for decoding */
-static const struct ice_rx_ptype_decoded ice_ptype_lkup[] = {
+/* Lookup table mapping the 10-bit HW PTYPE to the bit field for decoding */
+static const struct ice_rx_ptype_decoded ice_ptype_lkup[1024] = {
/* L2 Packet types */
ICE_PTT_UNUSED_ENTRY(0),
ICE_PTT(1, L2, NONE, NOF, NONE, NONE, NOF, NONE, PAY2),
--
2.26.2
[dpdk-dev] [PATCH 5/8] net/ice/base: set MAC type for E823C device
Set E823C device's MAC type as generic. Signed-off-by: Anirudh Venkataramanan Signed-off-by: Qi Zhang --- drivers/net/ice/base/ice_common.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/net/ice/base/ice_common.c b/drivers/net/ice/base/ice_common.c index 5c21d71b70..356a8b4d09 100644 --- a/drivers/net/ice/base/ice_common.c +++ b/drivers/net/ice/base/ice_common.c @@ -48,6 +48,11 @@ static enum ice_status ice_set_mac_type(struct ice_hw *hw) case ICE_DEV_ID_E823L_BACKPLANE: case ICE_DEV_ID_E823L_QSFP: case ICE_DEV_ID_E823L_SFP: + case ICE_DEV_ID_E823C_10G_BASE_T: + case ICE_DEV_ID_E823C_BACKPLANE: + case ICE_DEV_ID_E823C_QSFP: + case ICE_DEV_ID_E823C_SFP: + case ICE_DEV_ID_E823C_SGMII: hw->mac_type = ICE_MAC_GENERIC; break; default: -- 2.26.2
[dpdk-dev] [PATCH 6/8] net/ice/base: change protocol ID for VLAN in case of DVM
Protocol id for first vlan in Double VLAN Mode (DVM) should be
ICE_VLAN_OF_HW = 16, but for Single VLAN Mode (SVM) this should be
ICE_VLAN_OL_HW = 17.
Change protocol id in type to id translation array for outer vlan
to 17 when DVM is enabled, which means the driver, package,
and firmware support DVM.
Signed-off-by: Michal Swiatkowski
Signed-off-by: Haiyue Wang
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_flex_pipe.c | 3 +++
drivers/net/ice/base/ice_switch.c| 19 ++-
drivers/net/ice/base/ice_switch.h| 1 +
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ice/base/ice_flex_pipe.c
b/drivers/net/ice/base/ice_flex_pipe.c
index 90264240c4..b489c8ddb2 100644
--- a/drivers/net/ice/base/ice_flex_pipe.c
+++ b/drivers/net/ice/base/ice_flex_pipe.c
@@ -1244,6 +1244,9 @@ ice_download_pkg(struct ice_hw *hw, struct ice_seg
*ice_seg)
ice_cache_vlan_mode(hw);
+ if (ice_is_dvm_ena(hw))
+ ice_change_proto_id_to_dvm();
+
return status;
}
diff --git a/drivers/net/ice/base/ice_switch.c
b/drivers/net/ice/base/ice_switch.c
index 393fec3d40..86ce6064d1 100644
--- a/drivers/net/ice/base/ice_switch.c
+++ b/drivers/net/ice/base/ice_switch.c
@@ -6538,7 +6538,7 @@ static const struct ice_prot_ext_tbl_entry
ice_prot_ext[ICE_PROTOCOL_LAST] = {
* following policy.
*/
-static const struct ice_protocol_entry ice_prot_id_tbl[ICE_PROTOCOL_LAST] = {
+static struct ice_protocol_entry ice_prot_id_tbl[ICE_PROTOCOL_LAST] = {
{ ICE_MAC_OFOS, ICE_MAC_OFOS_HW },
{ ICE_MAC_IL, ICE_MAC_IL_HW },
{ ICE_ETYPE_OL, ICE_ETYPE_OL_HW },
@@ -6643,6 +6643,23 @@ static u16 ice_find_recp(struct ice_hw *hw, struct
ice_prot_lkup_ext *lkup_exts,
return ICE_MAX_NUM_RECIPES;
}
+/**
+ * ice_change_proto_id_to_dvm - change proto id in prot_id_tbl
+ *
+ * As protocol id for outer vlan is different in dvm and svm, if dvm is
+ * supported protocol array record for outer vlan has to be modified to
+ * reflect the value proper for DVM.
+ */
+void ice_change_proto_id_to_dvm(void)
+{
+ u8 i;
+
+ for (i = 0; i < ARRAY_SIZE(ice_prot_id_tbl); i++)
+ if (ice_prot_id_tbl[i].type == ICE_VLAN_OFOS &&
+ ice_prot_id_tbl[i].protocol_id != ICE_VLAN_OF_HW)
+ ice_prot_id_tbl[i].protocol_id = ICE_VLAN_OF_HW;
+}
+
/**
* ice_prot_type_to_id - get protocol ID from protocol type
* @type: protocol type
diff --git a/drivers/net/ice/base/ice_switch.h
b/drivers/net/ice/base/ice_switch.h
index 04d3c31006..61be54f9c0 100644
--- a/drivers/net/ice/base/ice_switch.h
+++ b/drivers/net/ice/base/ice_switch.h
@@ -535,4 +535,5 @@ bool ice_is_prof_rule(enum ice_sw_tunnel_type type);
enum ice_status
ice_update_recipe_lkup_idx(struct ice_hw *hw,
struct ice_update_recipe_lkup_idx_params *params);
+void ice_change_proto_id_to_dvm(void);
#endif /* _ICE_SWITCH_H_ */
--
2.26.2
[dpdk-dev] [PATCH 7/8] net/ice/base: enable I2C read/write commands
Enable I2C read/write AQ commands. They are now required for
controlling the external physical connectors via external I2C
port expander on E810-T adapters.
Signed-off-by: Maciej Machnikowski
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_adminq_cmd.h | 29 +
drivers/net/ice/base/ice_common.c | 94 +++
drivers/net/ice/base/ice_common.h | 8 +++
3 files changed, 131 insertions(+)
diff --git a/drivers/net/ice/base/ice_adminq_cmd.h
b/drivers/net/ice/base/ice_adminq_cmd.h
index 4b78da92b5..f9a741e99f 100644
--- a/drivers/net/ice/base/ice_adminq_cmd.h
+++ b/drivers/net/ice/base/ice_adminq_cmd.h
@@ -1665,6 +1665,31 @@ struct ice_aqc_get_link_topo {
u8 rsvd[9];
};
+/* Read/Write I2C (direct, 0x06E2/0x06E3) */
+struct ice_aqc_i2c {
+ struct ice_aqc_link_topo_addr topo_addr;
+ __le16 i2c_addr;
+ u8 i2c_params;
+#define ICE_AQC_I2C_DATA_SIZE_S0
+#define ICE_AQC_I2C_DATA_SIZE_M(0xF << ICE_AQC_I2C_DATA_SIZE_S)
+#define ICE_AQC_I2C_ADDR_TYPE_MBIT(4)
+#define ICE_AQC_I2C_ADDR_TYPE_7BIT 0
+#define ICE_AQC_I2C_ADDR_TYPE_10BITICE_AQC_I2C_ADDR_TYPE_M
+#define ICE_AQC_I2C_DATA_OFFSET_S 5
+#define ICE_AQC_I2C_DATA_OFFSET_M (0x3 << ICE_AQC_I2C_DATA_OFFSET_S)
+#define ICE_AQC_I2C_USE_REPEATED_START BIT(7)
+ u8 rsvd;
+ __le16 i2c_bus_addr;
+#define ICE_AQC_I2C_ADDR_7BIT_MASK 0x7F
+#define ICE_AQC_I2C_ADDR_10BIT_MASK0x3FF
+ u8 i2c_data[4]; /* Used only by write command, reserved in read. */
+};
+
+/* Read I2C Response (direct, 0x06E2) */
+struct ice_aqc_read_i2c_resp {
+ u8 i2c_data[16];
+};
+
/* Set Port Identification LED (direct, 0x06E9) */
struct ice_aqc_set_port_id_led {
u8 lport_num;
@@ -2838,6 +2863,8 @@ struct ice_aq_desc {
struct ice_aqc_get_phy_caps get_phy;
struct ice_aqc_set_phy_cfg set_phy;
struct ice_aqc_restart_an restart_an;
+ struct ice_aqc_i2c read_write_i2c;
+ struct ice_aqc_read_i2c_resp read_i2c_resp;
struct ice_aqc_sff_eeprom read_write_sff_param;
struct ice_aqc_set_port_id_led set_port_id_led;
struct ice_aqc_get_sw_cfg get_sw_conf;
@@ -3074,6 +3101,8 @@ enum ice_adminq_opc {
ice_aqc_opc_set_event_mask = 0x0613,
ice_aqc_opc_set_mac_lb = 0x0620,
ice_aqc_opc_get_link_topo = 0x06E0,
+ ice_aqc_opc_read_i2c= 0x06E2,
+ ice_aqc_opc_write_i2c = 0x06E3,
ice_aqc_opc_set_port_id_led = 0x06E9,
ice_aqc_opc_get_port_options= 0x06EA,
ice_aqc_opc_set_port_option = 0x06EB,
diff --git a/drivers/net/ice/base/ice_common.c
b/drivers/net/ice/base/ice_common.c
index 356a8b4d09..befaa83a4b 100644
--- a/drivers/net/ice/base/ice_common.c
+++ b/drivers/net/ice/base/ice_common.c
@@ -4766,6 +4766,100 @@ enum ice_fw_modes ice_get_fw_mode(struct ice_hw *hw)
return ICE_FW_MODE_NORMAL;
}
+/**
+ * ice_aq_read_i2c
+ * @hw: pointer to the hw struct
+ * @topo_addr: topology address for a device to communicate with
+ * @bus_addr: 7-bit I2C bus address
+ * @addr: I2C memory address (I2C offset) with up to 16 bits
+ * @params: I2C parameters: bit [7] - Repeated start, bits [6:5] data offset
size,
+ * bit [4] - I2C address type, bits [3:0] - data size
to read (0-16 bytes)
+ * @data: pointer to data (0 to 16 bytes) to be read from the I2C device
+ * @cd: pointer to command details structure or NULL
+ *
+ * Read I2C (0x06E2)
+ */
+enum ice_status
+ice_aq_read_i2c(struct ice_hw *hw, struct ice_aqc_link_topo_addr topo_addr,
+ u16 bus_addr, __le16 addr, u8 params, u8 *data,
+ struct ice_sq_cd *cd)
+{
+ struct ice_aq_desc desc = { 0 };
+ struct ice_aqc_i2c *cmd;
+ enum ice_status status;
+ u8 data_size;
+
+ ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_read_i2c);
+ cmd = &desc.params.read_write_i2c;
+
+ if (!data)
+ return ICE_ERR_PARAM;
+
+ data_size = (params & ICE_AQC_I2C_DATA_SIZE_M) >>
ICE_AQC_I2C_DATA_SIZE_S;
+
+ cmd->i2c_bus_addr = CPU_TO_LE16(bus_addr);
+ cmd->topo_addr = topo_addr;
+ cmd->i2c_params = params;
+ cmd->i2c_addr = addr;
+
+ status = ice_aq_send_cmd(hw, &desc, NULL, 0, cd);
+ if (!status) {
+ struct ice_aqc_read_i2c_resp *resp;
+ u8 i;
+
+ resp = &desc.params.read_i2c_resp;
+ for (i = 0; i < data_size; i++) {
+ *data = resp->i2c_data[i];
+ data++;
+ }
+ }
+
+ return status;
+}
+
+/**
+ * ice_aq_write_i2c
+ * @hw: pointer to the hw struct
+ * @topo_addr: topology address for a device to commun
[dpdk-dev] [PATCH 8/8] net/ice/base: add RSS support for PPPoL2TPv2oUDP
Add support for PPPoL2TPv2oUDP RSS hash. L2TPv2 and PPP ptypes
and flow headers are added. Prot id for PPP is added.
Signed-off-by: Ting Xu
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_flow.c | 65 ++--
drivers/net/ice/base/ice_flow.h | 2 +
drivers/net/ice/base/ice_protocol_type.h | 1 +
3 files changed, 52 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ice/base/ice_flow.c b/drivers/net/ice/base/ice_flow.c
index 20650b8a7b..28e441ea76 100644
--- a/drivers/net/ice/base/ice_flow.c
+++ b/drivers/net/ice/base/ice_flow.c
@@ -212,7 +212,7 @@ static const u32 ice_ptypes_mac_ofos[] = {
0xFDC00846, 0xBFBF7F7E, 0xF70001DF, 0xFEFDFDFB,
0x077E, 0x03FF, 0x, 0x,
0x0040, 0x03FFF000, 0xFFE0, 0x00100707,
- 0x, 0x, 0x, 0x,
+ 0xFF00, 0x003F, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
@@ -238,7 +238,7 @@ static const u32 ice_ptypes_ipv4_ofos[] = {
0x1DC0, 0x24000800, 0x, 0x,
0x, 0x0155, 0x, 0x,
0x, 0x000FC000, 0x02A0, 0x0010,
- 0x, 0x, 0x, 0x,
+ 0x1500, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
@@ -252,7 +252,7 @@ static const u32 ice_ptypes_ipv4_ofos_all[] = {
0x1DC0, 0x24000800, 0x, 0x,
0x, 0x0155, 0x, 0x,
0x, 0x000FC000, 0x83E0FAA0, 0x0101,
- 0x, 0x, 0x, 0x,
+ 0x03FFD500, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
@@ -264,7 +264,7 @@ static const u32 ice_ptypes_ipv4_il[] = {
0xE000, 0xB807700E, 0x8003, 0xE01DC03B,
0x000E, 0x, 0x, 0x,
0x, 0x, 0x001FF800, 0x0010,
- 0x, 0x, 0x, 0x,
+ 0xFC0FC000, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
@@ -278,7 +278,7 @@ static const u32 ice_ptypes_ipv6_ofos[] = {
0x, 0x, 0x7700, 0x10002000,
0x, 0x02AA, 0x, 0x,
0x, 0x03F0, 0x0540, 0x,
- 0x, 0x, 0x, 0x,
+ 0x2A00, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
@@ -292,7 +292,7 @@ static const u32 ice_ptypes_ipv6_ofos_all[] = {
0x, 0x, 0x7700, 0x10002000,
0x, 0x02AA, 0x, 0x,
0x, 0x03F0, 0x7C1F0540, 0x0206,
- 0x, 0x, 0x, 0x,
+ 0xFC002A00, 0x003F, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
@@ -304,7 +304,7 @@ static const u32 ice_ptypes_ipv6_il[] = {
0x, 0x03B80770, 0x01DC, 0x0EE0,
0x0770, 0x, 0x, 0x,
0x, 0x, 0x7FE0, 0x,
- 0x, 0x, 0x, 0x,
+ 0x03F0, 0x003F, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
@@ -316,7 +316,7 @@ static const u32 ice_ptypes_ipv4_ofos_no_l4[] = {
0x10C0, 0x04000800, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x000cc000, 0x02A0, 0x,
- 0x, 0x, 0x, 0x,
+ 0x1500, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
@@ -328,7 +328,7 @@ static const u32 ice_ptypes_ipv4_il_no_l4[] = {
0x6000, 0x18043008, 0x8002, 0x6010c021,
0x0008, 0x, 0x, 0x,
0x, 0x, 0x00139800, 0x,
- 0x, 0x, 0x, 0x,
+ 0x8C08C00
Re: [dpdk-dev] [PATCH] vdpa/mlx5: improve interrupt management
On 3/18/21 10:13 AM, Matan Azrad wrote: > The driver should notify the guest for each traffic burst detected by CQ > polling. > > The CQ polling trigger is defined by `event_mode` device argument, > either by busy polling on all the CQs or by blocked call to HW > completion event using DevX channel. > > Also, the polling event modes can move to blocked call when the > traffic rate is low. > > The current blocked call uses the EAL interrupt API suffering a lot > of overhead in the API management and serve all the drivers and > libraries using only single thread. > > Use blocking FD of the DevX channel in order to do blocked call > directly by the DevX channel FD mechanism. > > Signed-off-by: Matan Azrad > Acked-by: Xueming Li > --- > doc/guides/vdpadevs/mlx5.rst| 8 +- > drivers/vdpa/mlx5/mlx5_vdpa.c | 8 +- > drivers/vdpa/mlx5/mlx5_vdpa.h | 8 +- > drivers/vdpa/mlx5/mlx5_vdpa_event.c | 308 > +++- > 4 files changed, 134 insertions(+), 198 deletions(-) > Reviewed-by: Maxime Coquelin Thanks, Maxime
[dpdk-dev] [PATCH v5 1/3] kni: refactor user request processing
From: Elad Nachman
Refactor the parameter kni_net_process_request() gets, this is
preparation for addressing a user request processing deadlock problem.
Signed-off-by: Stephen Hemminger
Signed-off-by: Elad Nachman
---
kernel/linux/kni/kni_net.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
index 4b752083da28..b830054c7491 100644
--- a/kernel/linux/kni/kni_net.c
+++ b/kernel/linux/kni/kni_net.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -102,17 +103,15 @@ get_data_kva(struct kni_dev *kni, void *pkt_kva)
* It can be called to process the request.
*/
static int
-kni_net_process_request(struct kni_dev *kni, struct rte_kni_request *req)
+kni_net_process_request(struct net_device *dev, struct rte_kni_request *req)
{
+ struct kni_dev *kni = netdev_priv(dev);
int ret = -1;
void *resp_va;
uint32_t num;
int ret_val;
- if (!kni || !req) {
- pr_err("No kni instance or request\n");
- return -EINVAL;
- }
+ ASSERT_RTNL();
mutex_lock(&kni->sync_lock);
@@ -155,7 +154,6 @@ kni_net_open(struct net_device *dev)
{
int ret;
struct rte_kni_request req;
- struct kni_dev *kni = netdev_priv(dev);
netif_start_queue(dev);
if (kni_dflt_carrier == 1)
@@ -168,7 +166,7 @@ kni_net_open(struct net_device *dev)
/* Setting if_up to non-zero means up */
req.if_up = 1;
- ret = kni_net_process_request(kni, &req);
+ ret = kni_net_process_request(dev, &req);
return (ret == 0) ? req.result : ret;
}
@@ -178,7 +176,6 @@ kni_net_release(struct net_device *dev)
{
int ret;
struct rte_kni_request req;
- struct kni_dev *kni = netdev_priv(dev);
netif_stop_queue(dev); /* can't transmit any more */
netif_carrier_off(dev);
@@ -188,7 +185,7 @@ kni_net_release(struct net_device *dev)
/* Setting if_up to 0 means down */
req.if_up = 0;
- ret = kni_net_process_request(kni, &req);
+ ret = kni_net_process_request(dev, &req);
return (ret == 0) ? req.result : ret;
}
@@ -643,14 +640,13 @@ kni_net_change_mtu(struct net_device *dev, int new_mtu)
{
int ret;
struct rte_kni_request req;
- struct kni_dev *kni = netdev_priv(dev);
pr_debug("kni_net_change_mtu new mtu %d to be set\n", new_mtu);
memset(&req, 0, sizeof(req));
req.req_id = RTE_KNI_REQ_CHANGE_MTU;
req.new_mtu = new_mtu;
- ret = kni_net_process_request(kni, &req);
+ ret = kni_net_process_request(dev, &req);
if (ret == 0 && req.result == 0)
dev->mtu = new_mtu;
@@ -661,7 +657,6 @@ static void
kni_net_change_rx_flags(struct net_device *netdev, int flags)
{
struct rte_kni_request req;
- struct kni_dev *kni = netdev_priv(netdev);
memset(&req, 0, sizeof(req));
@@ -683,7 +678,7 @@ kni_net_change_rx_flags(struct net_device *netdev, int
flags)
req.promiscusity = 0;
}
- kni_net_process_request(kni, &req);
+ kni_net_process_request(netdev, &req);
}
/*
@@ -742,7 +737,6 @@ kni_net_set_mac(struct net_device *netdev, void *p)
{
int ret;
struct rte_kni_request req;
- struct kni_dev *kni;
struct sockaddr *addr = p;
memset(&req, 0, sizeof(req));
@@ -754,8 +748,7 @@ kni_net_set_mac(struct net_device *netdev, void *p)
memcpy(req.mac_addr, addr->sa_data, netdev->addr_len);
memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
- kni = netdev_priv(netdev);
- ret = kni_net_process_request(kni, &req);
+ ret = kni_net_process_request(netdev, &req);
return (ret == 0 ? req.result : ret);
}
--
2.30.2
[dpdk-dev] [PATCH v5 2/3] kni: support async user request
Adding async userspace requests which don't wait for the userspace
response and always return success. This is preparation to address a
regression in KNI.
Signed-off-by: Elad Nachman
Signed-off-by: Ferruh Yigit
---
kernel/linux/kni/kni_net.c | 9 +
lib/librte_kni/rte_kni.c| 7 +--
lib/librte_kni/rte_kni_common.h | 1 +
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
index b830054c7491..6cf99da0dc92 100644
--- a/kernel/linux/kni/kni_net.c
+++ b/kernel/linux/kni/kni_net.c
@@ -124,6 +124,14 @@ kni_net_process_request(struct net_device *dev, struct
rte_kni_request *req)
goto fail;
}
+ /* No result available since request is handled
+* asynchronously. set response to success.
+*/
+ if (req->async != 0) {
+ req->result = 0;
+ goto async;
+ }
+
ret_val = wait_event_interruptible_timeout(kni->wq,
kni_fifo_count(kni->resp_q), 3 * HZ);
if (signal_pending(current) || ret_val <= 0) {
@@ -139,6 +147,7 @@ kni_net_process_request(struct net_device *dev, struct
rte_kni_request *req)
}
memcpy(req, kni->sync_kva, sizeof(struct rte_kni_request));
+async:
ret = 0;
fail:
diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index 837d0217d2d1..9dae6a8d7c0c 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -591,8 +591,11 @@ rte_kni_handle_request(struct rte_kni *kni)
break;
}
- /* Construct response mbuf and put it back to resp_q */
- ret = kni_fifo_put(kni->resp_q, (void **)&req, 1);
+ /* if needed, construct response buffer and put it back to resp_q */
+ if (!req->async)
+ ret = kni_fifo_put(kni->resp_q, (void **)&req, 1);
+ else
+ ret = 1;
if (ret != 1) {
RTE_LOG(ERR, KNI, "Fail to put the muf back to resp_q\n");
return -1; /* It is an error of can't putting the mbuf back */
diff --git a/lib/librte_kni/rte_kni_common.h b/lib/librte_kni/rte_kni_common.h
index ffb3182731a0..b547ea550171 100644
--- a/lib/librte_kni/rte_kni_common.h
+++ b/lib/librte_kni/rte_kni_common.h
@@ -48,6 +48,7 @@ struct rte_kni_request {
uint8_t promiscusity;/**< 1: promisc mode enable, 0: disable */
uint8_t allmulti;/**< 1: all-multicast mode enable, 0:
disable */
};
+ int32_t async : 1;/**< 1: request is asynchronous */
int32_t result; /**< Result for processing request */
} __attribute__((__packed__));
--
2.30.2
[dpdk-dev] [PATCH v5 3/3] kni: fix kernel deadlock when using mlx devices
KNI runs userspace callback with rtnl lock held, this is not working
fine with some devices that needs to interact with kernel interface in
the callback, like Mellanox devices.
The solution is releasing the rtnl lock before calling the userspace
callback. But it requires two consideration:
1. The rtnl lock needs to released before 'kni->sync_lock', otherwise it
causes deadlock with multiple KNI devices, please check below the A.
for the details of the deadlock condition.
2. When rtnl lock is released for interface down event, it cause a
regression and deadlock, so can't release the rtnl lock for interface
down event, please check below B. for the details.
As a solution, interface down event is handled asynchronously and for
all other events rtnl lock is released before processing the callback.
A. KNI sync lock is being locked while rtnl is held.
If two threads are calling kni_net_process_request() ,
then the first one will take the sync lock, release rtnl lock then sleep.
The second thread will try to lock sync lock while holding rtnl.
The first thread will wake, and try to lock rtnl, resulting in a
deadlock. The remedy is to release rtnl before locking the KNI sync
lock.
Since in between nothing is accessing Linux network-wise, no rtnl
locking is needed.
B. There is a race condition in __dev_close_many() processing the
close_list while the application terminates.
It looks like if two KNI interfaces are terminating,
and one releases the rtnl lock, the other takes it,
updating the close_list in an unstable state,
causing the close_list to become a circular linked list,
hence list_for_each_entry() will endlessly loop inside
__dev_close_many() .
To summarize:
request != interface down : unlock rtnl, send request to user-space,
wait for response, send the response error code to caller in user-space.
request == interface down: send request to user-space, return immediately
with error code of 0 (success) to user-space.
Fixes: 3fc5ca2f6352 ("kni: initial import")
Cc: sta...@dpdk.org
Signed-off-by: Elad Nachman
---
Cc: Stephen Hemminger
Cc: Igor Ryzhov
Cc: Dan Gora
# kernel/linux/kni/kni_net.c.rej
---
kernel/linux/kni/kni_net.c | 16
1 file changed, 16 insertions(+)
diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
index 6cf99da0dc92..f259327954b2 100644
--- a/kernel/linux/kni/kni_net.c
+++ b/kernel/linux/kni/kni_net.c
@@ -113,6 +113,14 @@ kni_net_process_request(struct net_device *dev, struct
rte_kni_request *req)
ASSERT_RTNL();
+ /* If we need to wait and RTNL mutex is held
+* drop the mutex and hold reference to keep device
+*/
+ if (req->async == 0) {
+ dev_hold(dev);
+ rtnl_unlock();
+ }
+
mutex_lock(&kni->sync_lock);
/* Construct data */
@@ -152,6 +160,10 @@ kni_net_process_request(struct net_device *dev, struct
rte_kni_request *req)
fail:
mutex_unlock(&kni->sync_lock);
+ if (req->async == 0) {
+ rtnl_lock();
+ dev_put(dev);
+ }
return ret;
}
@@ -194,6 +206,10 @@ kni_net_release(struct net_device *dev)
/* Setting if_up to 0 means down */
req.if_up = 0;
+
+ /* request async because of the deadlock problem */
+ req.async = 1;
+
ret = kni_net_process_request(dev, &req);
return (ret == 0) ? req.result : ret;
--
2.30.2
Re: [dpdk-dev] [PATCH 01/25] event/dlb2: add dlb v2.5 probe
> -Original Message- > From: Jerin Jacob > Sent: Friday, March 26, 2021 9:33 AM > To: McDaniel, Timothy > Cc: dpdk-dev ; Jerin Jacob ; Van Haaren, > Harry ; Ray Kinsella ; Neil > Horman ; Rao, Nikhil ; > Carrillo, Erik G ; Gujjar, Abhinandan S > ; Pavan Nikhilesh > ; Hemant Agrawal ; > mattias.ronnblom ; Mccarthy, Peter > > Subject: Re: [dpdk-dev] [PATCH 01/25] event/dlb2: add dlb v2.5 probe > > On Fri, Mar 26, 2021 at 7:33 PM McDaniel, Timothy > wrote: > > > > > > > > > -Original Message- > > > From: Jerin Jacob > > > Sent: Friday, March 26, 2021 6:01 AM > > > To: McDaniel, Timothy > > > Cc: dpdk-dev ; Jerin Jacob ; Van > Haaren, > > > Harry ; Ray Kinsella ; Neil > > > Horman ; Rao, Nikhil ; > > > Carrillo, Erik G ; Gujjar, Abhinandan S > > > ; Pavan Nikhilesh > > > ; Hemant Agrawal > ; > > > mattias.ronnblom ; Mccarthy, Peter > > > > > > Subject: Re: [dpdk-dev] [PATCH 01/25] event/dlb2: add dlb v2.5 probe > > > > > > On Thu, Mar 25, 2021 at 1:01 AM McDaniel, Timothy > > > wrote: > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Jerin Jacob > > > > > Sent: Sunday, March 21, 2021 4:48 AM > > > > > To: McDaniel, Timothy > > > > > Cc: dpdk-dev ; Jerin Jacob ; Van > > > Haaren, > > > > > Harry ; Ray Kinsella ; > Neil > > > > > Horman ; Rao, Nikhil ; > > > > > Carrillo, Erik G ; Gujjar, Abhinandan S > > > > > ; Pavan Nikhilesh > > > > > ; Hemant Agrawal > > > ; > > > > > mattias.ronnblom ; Mccarthy, Peter > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 01/25] event/dlb2: add dlb v2.5 probe > > > > > > > > > > On Wed, Mar 17, 2021 at 3:49 AM Timothy McDaniel > > > > > wrote: > > > > > > > > > > > > This commit adds dlb v2.5 probe support, and updates > > > > > > parameter parsing. > > > > > > > > > > > > The dlb v2.5 device differs from dlb v2, in that the > > > > > > number of resources (ports, queues, ...) is different, > > > > > > so macros have been added to take the device version > > > > > > into account. > > > > > > > > > > > > This commit also cleans up a few issues in the original > > > > > > dlb2 source: > > > > > > - eliminate duplicate constant definitions > > > > > > - removed unused constant definitions > > > > > > > > > > > > Signed-off-by: Timothy McDaniel > > > > > > --- > > > > > > > > > > > > > > > > > -#define EVDEV_DLB2_NAME_PMD dlb2_event > > > > > > +#define EVDEV_DLB2_NAME_PMD dlb_event > > > > > > > > > > Is this an intended change? why change the driver's name. > > > > > > > > Yes, This is an intentional change. We will be using the same driver > > > > name > > > going forward, regardless of the hardware version. > > > > Internally, we know which version of the hardware is present. > > > > > > Since the driver name is still driver/event/dlb2. Keep it as same > > > prefix scheme with other drivers. > > > > > > > > > > > > > > Thanks, > > > > Tim > > > > > > > > Would it be acceptable to rename drivers/event/dlb2 to drivers/event/dlb? > > We may have additional dlb devices in the pipeline, such as v3, and we would > really like > > to have them all use a common name. > > Makes sense to change to drivers/event/dlb. I think, we can make to > dlb when you > add v3 support. Now there is no need. > > > > Hi Jerin, I spoke to the team, and we would like to get this change in now. It happens that we have several applications that use the eventdev API rte_event_dev_get_dev_id(const char *name). Having a single name simplifies these applications, and also prevents customers from having to update application source code every time a new dlb device is released. Thanks, Tim
Re: [dpdk-dev] [PATCH 2/4] vhost: remove unnecessary free
On 3/17/21 1:56 PM, Jiayu Hu wrote: > This patch removes unnecessary rte_free() for async_pkts_info > and async_descs_split. > > Signed-off-by: Jiayu Hu > --- > lib/librte_vhost/vhost_user.c | 7 --- > 1 file changed, 7 deletions(-) > Reviewed-by: Maxime Coquelin Thanks, Maxime
[dpdk-dev] [PATCH v2 0/2] Enhancements to crypto adapter forward mode
This series proposes a new event device enqueue operation if crypto
adapter forward mode is supported. Second patch in the series is the
implementation of the same in PMD. Test application changes for the
usage of new API is yet to add.
v2:
- Updated release notes.
- Made use of RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET macro.
- Fixed v1 build error.
v1:
- Added crypto adapter forward mode support for octeontx2.
Akhil Goyal (1):
eventdev: introduce crypto adapter enqueue API
Shijith Thotton (1):
event/octeontx2: support crypto adapter forward mode
.../prog_guide/event_crypto_adapter.rst | 69 ++--
doc/guides/rel_notes/release_21_05.rst| 6 ++
drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 42 ++
drivers/event/octeontx2/otx2_evdev.c | 5 +-
.../event/octeontx2/otx2_evdev_crypto_adptr.c | 3 +-
...dptr_dp.h => otx2_evdev_crypto_adptr_rx.h} | 6 +-
.../octeontx2/otx2_evdev_crypto_adptr_tx.h| 82 +++
drivers/event/octeontx2/otx2_worker.h | 2 +-
drivers/event/octeontx2/otx2_worker_dual.h| 2 +-
lib/librte_eventdev/eventdev_trace_points.c | 3 +
.../rte_event_crypto_adapter.h| 62 ++
lib/librte_eventdev/rte_eventdev.c| 10 +++
lib/librte_eventdev/rte_eventdev.h| 8 +-
lib/librte_eventdev/rte_eventdev_trace_fp.h | 10 +++
lib/librte_eventdev/version.map | 3 +
15 files changed, 265 insertions(+), 48 deletions(-)
rename drivers/event/octeontx2/{otx2_evdev_crypto_adptr_dp.h =>
otx2_evdev_crypto_adptr_rx.h} (93%)
create mode 100644 drivers/event/octeontx2/otx2_evdev_crypto_adptr_tx.h
--
2.25.1
[dpdk-dev] [PATCH v2 1/2] eventdev: introduce crypto adapter enqueue API
From: Akhil Goyal In case an event from a previous stage is required to be forwarded to a crypto adapter and PMD supports internal event port in crypto adapter, exposed via capability RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD, we do not have a way to check in the API rte_event_enqueue_burst(), whether it is for crypto adapter or for eth tx adapter. Hence we need a new API similar to rte_event_eth_tx_adapter_enqueue(), which can send to a crypto adapter. Note that RTE_EVENT_TYPE_* cannot be used to make that decision, as it is meant for event source and not event destination. And event port designated for crypto adapter is designed to be used for OP_NEW mode. Hence, in order to support an event PMD which has an internal event port in crypto adapter (RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode), exposed via capability RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD, application should use rte_event_crypto_adapter_enqueue() API to enqueue events. When internal port is not available(RTE_EVENT_CRYPTO_ADAPTER_OP_NEW mode), application can use API rte_event_enqueue_burst() as it was doing earlier, i.e. retrieve event port used by crypto adapter and bind its event queues to that port and enqueue events using the API rte_event_enqueue_burst(). Signed-off-by: Akhil Goyal --- .../prog_guide/event_crypto_adapter.rst | 69 --- doc/guides/rel_notes/release_21_05.rst| 6 ++ lib/librte_eventdev/eventdev_trace_points.c | 3 + .../rte_event_crypto_adapter.h| 62 + lib/librte_eventdev/rte_eventdev.c| 10 +++ lib/librte_eventdev/rte_eventdev.h| 8 ++- lib/librte_eventdev/rte_eventdev_trace_fp.h | 10 +++ lib/librte_eventdev/version.map | 3 + 8 files changed, 144 insertions(+), 27 deletions(-) diff --git a/doc/guides/prog_guide/event_crypto_adapter.rst b/doc/guides/prog_guide/event_crypto_adapter.rst index 1e3eb7139..4fb5c688e 100644 --- a/doc/guides/prog_guide/event_crypto_adapter.rst +++ b/doc/guides/prog_guide/event_crypto_adapter.rst @@ -55,21 +55,22 @@ which is needed to enqueue an event after the crypto operation is completed. RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode -In the RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode, if HW supports -RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD capability the application -can directly submit the crypto operations to the cryptodev. -If not, application retrieves crypto adapter's event port using -rte_event_crypto_adapter_event_port_get() API. Then, links its event -queue to this port and starts enqueuing crypto operations as events -to the eventdev. The adapter then dequeues the events and submits the -crypto operations to the cryptodev. After the crypto completions, the -adapter enqueues events to the event device. -Application can use this mode, when ingress packet ordering is needed. -In this mode, events dequeued from the adapter will be treated as -forwarded events. The application needs to specify the cryptodev ID -and queue pair ID (request information) needed to enqueue a crypto -operation in addition to the event information (response information) -needed to enqueue an event after the crypto operation has completed. +In the ``RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD`` mode, if the event PMD and crypto +PMD supports internal event port +(``RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD``), the application should +use ``rte_event_crypto_adapter_enqueue()`` API to enqueue crypto operations as +events to crypto adapter. If not, application retrieves crypto adapter's event +port using ``rte_event_crypto_adapter_event_port_get()`` API, links its event +queue to this port and starts enqueuing crypto operations as events to eventdev +using ``rte_event_enqueue_burst()``. The adapter then dequeues the events and +submits the crypto operations to the cryptodev. After the crypto operation is +complete, the adapter enqueues events to the event device. The application can +use this mode when ingress packet ordering is needed. In this mode, events +dequeued from the adapter will be treated as forwarded events. The application +needs to specify the cryptodev ID and queue pair ID (request information) needed +to enqueue a crypto operation in addition to the event information (response +information) needed to enqueue an event after the crypto operation has +completed. .. _figure_event_crypto_adapter_op_forward: @@ -120,28 +121,44 @@ service function and needs to create an event port for it. The callback is expected to fill the ``struct rte_event_crypto_adapter_conf`` structure passed to it. -For RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode, the event port created by adapter -can be retrieved using ``rte_event_crypto_adapter_event_port_get()`` API. -Application can use this event port to link with event queue on which it -enqueues events towards the crypto adapter. +In the ``RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD`` mode, i
[dpdk-dev] [PATCH v2 2/2] event/octeontx2: support crypto adapter forward mode
Advertise crypto adapter forward mode capability and set crypto adapter
enqueue function in driver.
Signed-off-by: Shijith Thotton
---
drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 42 ++
drivers/event/octeontx2/otx2_evdev.c | 5 +-
.../event/octeontx2/otx2_evdev_crypto_adptr.c | 3 +-
...dptr_dp.h => otx2_evdev_crypto_adptr_rx.h} | 6 +-
.../octeontx2/otx2_evdev_crypto_adptr_tx.h| 82 +++
drivers/event/octeontx2/otx2_worker.h | 2 +-
drivers/event/octeontx2/otx2_worker_dual.h| 2 +-
7 files changed, 121 insertions(+), 21 deletions(-)
rename drivers/event/octeontx2/{otx2_evdev_crypto_adptr_dp.h =>
otx2_evdev_crypto_adptr_rx.h} (93%)
create mode 100644 drivers/event/octeontx2/otx2_evdev_crypto_adptr_tx.h
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
index cec20b5c6..4808dca64 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include "otx2_cryptodev.h"
#include "otx2_cryptodev_capabilities.h"
@@ -434,15 +435,28 @@ sym_session_configure(int driver_id, struct
rte_crypto_sym_xform *xform,
return -ENOTSUP;
}
-static __rte_always_inline void __rte_hot
+static __rte_always_inline int32_t __rte_hot
otx2_ca_enqueue_req(const struct otx2_cpt_qp *qp,
struct cpt_request_info *req,
void *lmtline,
+ struct rte_crypto_op *op,
uint64_t cpt_inst_w7)
{
+ union rte_event_crypto_metadata *m_data;
union cpt_inst_s inst;
uint64_t lmt_status;
+ if (op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
+ m_data = rte_cryptodev_sym_session_get_user_data(
+ op->sym->session);
+ else if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
+op->private_data_offset)
+ m_data = (union rte_event_crypto_metadata *)
+((uint8_t *)op +
+ op->private_data_offset);
+ else
+ return -EINVAL;
+
inst.u[0] = 0;
inst.s9x.res_addr = req->comp_baddr;
inst.u[2] = 0;
@@ -453,12 +467,11 @@ otx2_ca_enqueue_req(const struct otx2_cpt_qp *qp,
inst.s9x.ei2 = req->ist.ei2;
inst.s9x.ei3 = cpt_inst_w7;
- inst.s9x.qord = 1;
- inst.s9x.grp = qp->ev.queue_id;
- inst.s9x.tt = qp->ev.sched_type;
- inst.s9x.tag = (RTE_EVENT_TYPE_CRYPTODEV << 28) |
- qp->ev.flow_id;
- inst.s9x.wq_ptr = (uint64_t)req >> 3;
+ inst.u[2] = (((RTE_EVENT_TYPE_CRYPTODEV << 28) |
+ m_data->response_info.flow_id) |
+((uint64_t)m_data->response_info.sched_type << 32) |
+((uint64_t)m_data->response_info.queue_id << 34));
+ inst.u[3] = 1 | (((uint64_t)req >> 3) << 3);
req->qp = qp;
do {
@@ -475,22 +488,22 @@ otx2_ca_enqueue_req(const struct otx2_cpt_qp *qp,
lmt_status = otx2_lmt_submit(qp->lf_nq_reg);
} while (lmt_status == 0);
+ return 0;
}
static __rte_always_inline int32_t __rte_hot
otx2_cpt_enqueue_req(const struct otx2_cpt_qp *qp,
struct pending_queue *pend_q,
struct cpt_request_info *req,
+struct rte_crypto_op *op,
uint64_t cpt_inst_w7)
{
void *lmtline = qp->lmtline;
union cpt_inst_s inst;
uint64_t lmt_status;
- if (qp->ca_enable) {
- otx2_ca_enqueue_req(qp, req, lmtline, cpt_inst_w7);
- return 0;
- }
+ if (qp->ca_enable)
+ return otx2_ca_enqueue_req(qp, req, lmtline, op, cpt_inst_w7);
if (unlikely(pend_q->pending_count >= OTX2_CPT_DEFAULT_CMD_QLEN))
return -EAGAIN;
@@ -594,7 +607,8 @@ otx2_cpt_enqueue_asym(struct otx2_cpt_qp *qp,
goto req_fail;
}
- ret = otx2_cpt_enqueue_req(qp, pend_q, params.req, sess->cpt_inst_w7);
+ ret = otx2_cpt_enqueue_req(qp, pend_q, params.req, op,
+ sess->cpt_inst_w7);
if (unlikely(ret)) {
CPT_LOG_DP_ERR("Could not enqueue crypto req");
@@ -638,7 +652,7 @@ otx2_cpt_enqueue_sym(struct otx2_cpt_qp *qp, struct
rte_crypto_op *op,
return ret;
}
- ret = otx2_cpt_enqueue_req(qp, pend_q, req, sess->cpt_inst_w7);
+ ret = otx2_cpt_enqueue_req(qp, pend_q, req, op, sess->cpt_inst_w7);
if (unlikely(ret)) {
/* Free buffer allocated by fill params routines */
@@ -707,7 +721,7 @@ otx2_cpt_enqueue_sec(struct otx2_cpt_qp *qp, struct
rte_crypto_op *op,
return ret;
}
- ret = otx2_cpt_enqueue_req(qp, pend_q, req, sess->cpt_inst_w7);
+ ret = otx2_cpt_enqueue_req(qp, p
Re: [dpdk-dev] [PATCH 3/4] vhost: avoid deadlock on async register
On 3/17/21 1:56 PM, Jiayu Hu wrote:
> Users register async copy device when vhost queue is enabled.
> However, if VHOST_USER_F_PROTOCOL_FEATURES is not supported,
> a deadlock occurs inside rte_vhost_async_channel_register(),
> as vhost_user_msg_handler() already takes vq->access_lock
> before processing VHOST_USER_SET_VRING_KICK message.
>
> This patch removes calling vring_state_changed() in
> vhost_user_set_vring_kick() to avoid deadlock on async register.
>
> Signed-off-by: Jiayu Hu
> ---
> lib/librte_vhost/vhost_user.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> index 399675c..a319c1c 100644
> --- a/lib/librte_vhost/vhost_user.c
> +++ b/lib/librte_vhost/vhost_user.c
> @@ -1919,9 +1919,6 @@ vhost_user_set_vring_kick(struct virtio_net **pdev,
> struct VhostUserMsg *msg,
>*/
> if (!(dev->features & (1ULL << VHOST_USER_F_PROTOCOL_FEATURES))) {
> vq->enabled = 1;
> - if (dev->notify_ops->vring_state_changed)
> - dev->notify_ops->vring_state_changed(
> - dev->vid, file.index, 1);
That looks very wrong, as:
1. The apps want to receive this notification. It looks like breaking
existing apps in order to support the experimental async datapath. E.g.
OVS needs it to start polling the queues when protocol features is not
negotiated.
2. The fix in your case seems to indicate that your app's
vring_state_changed callback called rte_vhost_async_channel_register.
And your fix consists in no more calling the callback, and so no more
calling rte_vhost_async_channel_register?
> }
>
> if (vq->ready) {
>
Re: [dpdk-dev] [PATCH v2] ethdev: introduce enable_driver_sdk to install driver headers
On 3/29/2021 1:10 PM, Thomas Monjalon wrote: 29/03/2021 11:43, Ferruh Yigit: On 3/26/2021 8:52 PM, Tyler Retzlaff wrote: On Fri, Mar 26, 2021 at 12:02:55PM +, Ferruh Yigit wrote: On 3/24/2021 4:24 PM, Tyler Retzlaff wrote: On Wed, Mar 24, 2021 at 12:30:36PM +0100, Thomas Monjalon wrote: 24/03/2021 12:27, Ferruh Yigit: But not sure how to manage the same problem for whole project, if install all headers in one patch, or add them gradually via separate patches by time ... We did a cleanup in ethdev but not in other driver classes. When the cleanup will be done gradually, the headers must move in this new category driver_sdk_headers. yes, some headers are not installed now. so they need only to have their api marked __rte_internal and installed (since there should be no external consumer as a function of not being installed) the more difficult case is where headers were installed but the api were not marked __rte_internal and appear in the stable version.map. for those i guess deprecation notice has to be issued before marking as internal. Are you referring to any specific APIs, can you share list of them? i can't remember the whole list but Thomas originally indicated the following candidate list. baseband/ -> librte_bbdev/rte_bbdev_pmd.h bus/ -> rte_bus.h common/ -> no interface crypto/ -> librte_cryptodev/rte_cryptodev_pmd.h event/ -> librte_eventdev/ mempool/ -> librte_mempool/ net/ -> librte_ethdev/ raw/ -> librte_rawdev/rte_rawdev_pmd.h regex/ -> librte_regexdev/rte_regexdev_driver.h vdpa/ -> librte_vhost/rte_vdpa_dev.h some of these headers are not published, some are. These are public headers, so they should not have '__rte_internal' functions, are you saying some of public headers has internal functions that are presented as public APIs? These are the headers for use by the drivers. We should classify them as SDK headers, not API. Yes, you are right, they shouldn't be public header. So, agree to Tyler's comment, that some of those functions needs to be removed from the stable API list first, which will take time. I can proceed with the ethdev one, any objection? And for the rest of the list, how can we fix them? I guess best option is to distribute the work to each library, but we need an owner of the task to follow and communicate it.
Re: [dpdk-dev] [PATCH v4 6/6] net/txgbe: add FFE parameters for user debugging
On 3/29/2021 4:17 AM, Jiawen Wu wrote: Support to set PHY link mode by user defined. And update release notes 21.05 for txgbe. During merge, release notes update moved to 3/6 where looks more appropriate, since this patch adds FFE parameters but note is about AN training. But please let me know if it is wrong. Signed-off-by: Jiawen Wu <...>
Re: [dpdk-dev] [PATCH 01/25] event/dlb2: add dlb v2.5 probe
On Mon, Mar 29, 2021 at 8:30 PM McDaniel, Timothy wrote: > > > > > -Original Message- > > From: Jerin Jacob > > Sent: Friday, March 26, 2021 9:33 AM > > To: McDaniel, Timothy > > Cc: dpdk-dev ; Jerin Jacob ; Van Haaren, > > Harry ; Ray Kinsella ; Neil > > Horman ; Rao, Nikhil ; > > Carrillo, Erik G ; Gujjar, Abhinandan S > > ; Pavan Nikhilesh > > ; Hemant Agrawal ; > > mattias.ronnblom ; Mccarthy, Peter > > > > Subject: Re: [dpdk-dev] [PATCH 01/25] event/dlb2: add dlb v2.5 probe > > > > On Fri, Mar 26, 2021 at 7:33 PM McDaniel, Timothy > > wrote: > > > > > > > > > > > > > -Original Message- > > > > From: Jerin Jacob > > > > Sent: Friday, March 26, 2021 6:01 AM > > > > To: McDaniel, Timothy > > > > Cc: dpdk-dev ; Jerin Jacob ; Van > > Haaren, > > > > Harry ; Ray Kinsella ; Neil > > > > Horman ; Rao, Nikhil ; > > > > Carrillo, Erik G ; Gujjar, Abhinandan S > > > > ; Pavan Nikhilesh > > > > ; Hemant Agrawal > > ; > > > > mattias.ronnblom ; Mccarthy, Peter > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 01/25] event/dlb2: add dlb v2.5 probe > > > > > > > > On Thu, Mar 25, 2021 at 1:01 AM McDaniel, Timothy > > > > wrote: > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: Jerin Jacob > > > > > > Sent: Sunday, March 21, 2021 4:48 AM > > > > > > To: McDaniel, Timothy > > > > > > Cc: dpdk-dev ; Jerin Jacob ; Van > > > > Haaren, > > > > > > Harry ; Ray Kinsella ; > > Neil > > > > > > Horman ; Rao, Nikhil ; > > > > > > Carrillo, Erik G ; Gujjar, Abhinandan S > > > > > > ; Pavan Nikhilesh > > > > > > ; Hemant Agrawal > > > > ; > > > > > > mattias.ronnblom ; Mccarthy, Peter > > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 01/25] event/dlb2: add dlb v2.5 probe > > > > > > > > > > > > On Wed, Mar 17, 2021 at 3:49 AM Timothy McDaniel > > > > > > wrote: > > > > > > > > > > > > > > This commit adds dlb v2.5 probe support, and updates > > > > > > > parameter parsing. > > > > > > > > > > > > > > The dlb v2.5 device differs from dlb v2, in that the > > > > > > > number of resources (ports, queues, ...) is different, > > > > > > > so macros have been added to take the device version > > > > > > > into account. > > > > > > > > > > > > > > This commit also cleans up a few issues in the original > > > > > > > dlb2 source: > > > > > > > - eliminate duplicate constant definitions > > > > > > > - removed unused constant definitions > > > > > > > > > > > > > > Signed-off-by: Timothy McDaniel > > > > > > > --- > > > > > > > > > > > > > > > > > > > > -#define EVDEV_DLB2_NAME_PMD dlb2_event > > > > > > > +#define EVDEV_DLB2_NAME_PMD dlb_event > > > > > > > > > > > > Is this an intended change? why change the driver's name. > > > > > > > > > > Yes, This is an intentional change. We will be using the same driver > > > > > name > > > > going forward, regardless of the hardware version. > > > > > Internally, we know which version of the hardware is present. > > > > > > > > Since the driver name is still driver/event/dlb2. Keep it as same > > > > prefix scheme with other drivers. > > > > > > > > > > > > > > > > > > Thanks, > > > > > Tim > > > > > > > > > > > Would it be acceptable to rename drivers/event/dlb2 to drivers/event/dlb? > > > We may have additional dlb devices in the pipeline, such as v3, and we > > > would > > really like > > > to have them all use a common name. > > > > Makes sense to change to drivers/event/dlb. I think, we can make to > > dlb when you > > add v3 support. Now there is no need. > > > > > > > > > Hi Jerin, > > I spoke to the team, and we would like to get this change in now. It happens > that we have > several applications that use the eventdev API rte_event_dev_get_dev_id(const > char *name). > Having a single name simplifies these applications, and also prevents > customers from having to > update application source code every time a new dlb device is released. Now that we removed drivers/event/dlb, Please rename drivers/event/dlb2 as drivers/event/dlb. and change EVDEV_DLB_NAME_PMD as dlb_event and submit the new patch patches for v2.5. > > Thanks, > Tim >
Re: [dpdk-dev] [PATCH v4 0/6] txgbe backplane AN training
On 3/29/2021 4:17 AM, Jiawen Wu wrote: This series update link process for backplane NICs. And support to control AN training. v4: - Convert BP_LOG to dynamic log. v3: - Add devargs gradually in the patches they are used. - Update 21.05 relaese notes. v2: - Convert compile time flags to runtime options - Move firmware version get operation to base code - Fix minor bugs Jiawen Wu (6): net/txgbe: update device ID net/txgbe: move firmware version get function to base code net/txgbe: update link setup process of backplane NICs net/txgbe/base: support to handle backplane AN73 flow net/txgbe: handle AN interrupt and link update net/txgbe: add FFE parameters for user debugging Series applied to dpdk-next-net/main, thanks.
Re: [dpdk-dev] [PATCH 01/25] event/dlb2: add dlb v2.5 probe
> -Original Message- > From: Jerin Jacob > Sent: Monday, March 29, 2021 10:51 AM > To: McDaniel, Timothy > Cc: dpdk-dev ; Jerin Jacob ; Van Haaren, > Harry ; Ray Kinsella ; Neil > Horman ; Rao, Nikhil ; > Carrillo, Erik G ; Gujjar, Abhinandan S > ; Pavan Nikhilesh > ; Hemant Agrawal ; > mattias.ronnblom ; Mccarthy, Peter > > Subject: Re: [dpdk-dev] [PATCH 01/25] event/dlb2: add dlb v2.5 probe > > On Mon, Mar 29, 2021 at 8:30 PM McDaniel, Timothy > wrote: > > > > > > > > > -Original Message- > > > From: Jerin Jacob > > > Sent: Friday, March 26, 2021 9:33 AM > > > To: McDaniel, Timothy > > > Cc: dpdk-dev ; Jerin Jacob ; Van > Haaren, > > > Harry ; Ray Kinsella ; Neil > > > Horman ; Rao, Nikhil ; > > > Carrillo, Erik G ; Gujjar, Abhinandan S > > > ; Pavan Nikhilesh > > > ; Hemant Agrawal > ; > > > mattias.ronnblom ; Mccarthy, Peter > > > > > > Subject: Re: [dpdk-dev] [PATCH 01/25] event/dlb2: add dlb v2.5 probe > > > > > > On Fri, Mar 26, 2021 at 7:33 PM McDaniel, Timothy > > > wrote: > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Jerin Jacob > > > > > Sent: Friday, March 26, 2021 6:01 AM > > > > > To: McDaniel, Timothy > > > > > Cc: dpdk-dev ; Jerin Jacob ; Van > > > Haaren, > > > > > Harry ; Ray Kinsella ; > Neil > > > > > Horman ; Rao, Nikhil ; > > > > > Carrillo, Erik G ; Gujjar, Abhinandan S > > > > > ; Pavan Nikhilesh > > > > > ; Hemant Agrawal > > > ; > > > > > mattias.ronnblom ; Mccarthy, Peter > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 01/25] event/dlb2: add dlb v2.5 probe > > > > > > > > > > On Thu, Mar 25, 2021 at 1:01 AM McDaniel, Timothy > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > From: Jerin Jacob > > > > > > > Sent: Sunday, March 21, 2021 4:48 AM > > > > > > > To: McDaniel, Timothy > > > > > > > Cc: dpdk-dev ; Jerin Jacob ; > Van > > > > > Haaren, > > > > > > > Harry ; Ray Kinsella > ; > > > Neil > > > > > > > Horman ; Rao, Nikhil > ; > > > > > > > Carrillo, Erik G ; Gujjar, Abhinandan S > > > > > > > ; Pavan Nikhilesh > > > > > > > ; Hemant Agrawal > > > > > ; > > > > > > > mattias.ronnblom ; Mccarthy, > Peter > > > > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 01/25] event/dlb2: add dlb v2.5 > > > > > > > probe > > > > > > > > > > > > > > On Wed, Mar 17, 2021 at 3:49 AM Timothy McDaniel > > > > > > > wrote: > > > > > > > > > > > > > > > > This commit adds dlb v2.5 probe support, and updates > > > > > > > > parameter parsing. > > > > > > > > > > > > > > > > The dlb v2.5 device differs from dlb v2, in that the > > > > > > > > number of resources (ports, queues, ...) is different, > > > > > > > > so macros have been added to take the device version > > > > > > > > into account. > > > > > > > > > > > > > > > > This commit also cleans up a few issues in the original > > > > > > > > dlb2 source: > > > > > > > > - eliminate duplicate constant definitions > > > > > > > > - removed unused constant definitions > > > > > > > > > > > > > > > > Signed-off-by: Timothy McDaniel > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > > -#define EVDEV_DLB2_NAME_PMD dlb2_event > > > > > > > > +#define EVDEV_DLB2_NAME_PMD dlb_event > > > > > > > > > > > > > > Is this an intended change? why change the driver's name. > > > > > > > > > > > > Yes, This is an intentional change. We will be using the same > > > > > > driver > name > > > > > going forward, regardless of the hardware version. > > > > > > Internally, we know which version of the hardware is present. > > > > > > > > > > Since the driver name is still driver/event/dlb2. Keep it as same > > > > > prefix scheme with other drivers. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Tim > > > > > > > > > > > > > > Would it be acceptable to rename drivers/event/dlb2 to > > > > drivers/event/dlb? > > > > We may have additional dlb devices in the pipeline, such as v3, and we > would > > > really like > > > > to have them all use a common name. > > > > > > Makes sense to change to drivers/event/dlb. I think, we can make to > > > dlb when you > > > add v3 support. Now there is no need. > > > > > > > > > > > > > > Hi Jerin, > > > > I spoke to the team, and we would like to get this change in now. It happens > that we have > > several applications that use the eventdev API > rte_event_dev_get_dev_id(const char *name). > > Having a single name simplifies these applications, and also prevents > customers from having to > > update application source code every time a new dlb device is released. > > > Now that we removed drivers/event/dlb, Please rename > drivers/event/dlb2 as drivers/event/dlb. > and change EVDEV_DLB_NAME_PMD as dlb_event and submit the new patch > patches for v2.5. > > > > > > > Thanks, > > Tim > > Thank you Jerin. I will make those changes and submit a new patch set containing this and the other requested changes. Best Regards, Tim
Re: [dpdk-dev] [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API
Hi Matan,
> -Original Message-
> From: Matan Azrad
> Sent: Thursday, March 25, 2021 6:57 AM
> To: Dumitrescu, Cristian ; Li Zhang
> ; Dekel Peled ; Ori Kam
> ; Slava Ovsiienko ; Shahaf
> Shuler ; lir...@marvell.com; Singh, Jasvinder
> ; NBU-Contact-Thomas Monjalon
> ; Yigit, Ferruh ; Andrew
> Rybchenko ; Jerin Jacob
> ; Hemant Agrawal ;
> Ajit Khaparde
> Cc: dev@dpdk.org; Raslan Darawsheh ; Roni Bar Yanai
>
> Subject: RE: [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API
>
> Hi Cristian
>
> Thank you for your important review!
> I agree with all your comments except one, please see inline.
>
> From: Dumitrescu, Cristian
> > Hi Li and Matan,
> >
> > Thank you for your proposal, some comments below.
> >
> > I am also adding Jerin and Hemant to this thread, as they also participated
> in
> > the definition of the rte_mtr API in 2017. Also Ajit expressed some interest
> in a
> > previous email.
> >
> > > -Original Message-
> > > From: Li Zhang
> > > Sent: Thursday, March 18, 2021 8:58 AM
> > > To: dek...@nvidia.com; or...@nvidia.com; viachesl...@nvidia.com;
> > > ma...@nvidia.com; shah...@nvidia.com; lir...@marvell.com; Singh,
> > > Jasvinder ; Thomas Monjalon
> > > ; Yigit, Ferruh ;
> Andrew
> > > Rybchenko ; Dumitrescu, Cristian
> > >
> > > Cc: dev@dpdk.org; rasl...@nvidia.com; ron...@nvidia.com
> > > Subject: [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API
> > >
> > > Currently, the flow meter policy does not support multiple actions per
> > > color; also the allowed action types per color are very limited.
> > > In addition, the policy cannot be pre-defined.
> > >
> > > Due to the growing in flow actions offload abilities there is a
> > > potential for the user to use variety of actions per color differently.
> > > This new meter policy API comes to allow this potential in the most
> > > ethdev common way using rte_flow action definition.
> > > A list of rte_flow actions will be provided by the user per color in
> > > order to create a meter policy.
> > > In addition, the API forces to pre-define the policy before the meters
> > > creation in order to allow sharing of single policy with multiple
> > > meters efficiently.
> > >
> > > meter_policy_id is added into struct rte_mtr_params.
> > > So that it can get the policy during the meters creation.
> > >
> > > Policy id 0 is default policy. Action per color as below:
> > > green - no action, yellow - no action, red - drop
> > >
> > > Allow coloring the packet using a new rte_flow_action_color as could
> > > be done by the old policy API,
> > >
> >
> > The proposal essentially is to define the meter policy based on rte_flow
> actions
> > rather than a reduced action set defined specifically just for meter object.
> This
> > makes sense to me.
> >
> > > The next API function were added:
> > > - rte_mtr_meter_policy_add
> > > - rte_mtr_meter_policy_delete
> > > - rte_mtr_meter_policy_update
> > > - rte_mtr_meter_policy_validate
> > > The next struct was changed:
> > > - rte_mtr_params
> > > - rte_mtr_capabilities
> > > The next API was deleted:
> > > - rte_mtr_policer_actions_update
> > >
> > > Signed-off-by: Li Zhang
> > > ---
> > > lib/librte_ethdev/rte_flow.h | 18
> > > lib/librte_ethdev/rte_mtr.c| 55 --
> > > lib/librte_ethdev/rte_mtr.h| 166 -
> > > lib/librte_ethdev/rte_mtr_driver.h | 45 ++--
> > > 4 files changed, 210 insertions(+), 74 deletions(-)
> > >
> > > diff --git a/lib/librte_ethdev/rte_flow.h
> > > b/lib/librte_ethdev/rte_flow.h index 669e677e91..5f38aa7fa4 100644
> > > --- a/lib/librte_ethdev/rte_flow.h
> > > +++ b/lib/librte_ethdev/rte_flow.h
> > > @@ -31,6 +31,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #ifdef __cplusplus
> > > extern "C" {
> > > @@ -2236,6 +2237,13 @@ enum rte_flow_action_type {
> > >* See struct rte_flow_action_modify_field.
> > >*/
> > > RTE_FLOW_ACTION_TYPE_MODIFY_FIELD,
> > > +
> > > + /**
> > > + * Color the packet to reflect the meter color result.
> > > + *
> > > + * See struct rte_flow_action_color.
> > > + */
> > > + RTE_FLOW_ACTION_TYPE_COlOR,
> >
> > Typo here, it should be RTE_FLOW_ACTION_TYPE_COLOR.
> >
> > > };
> > >
> > > /**
> > > @@ -2828,6 +2836,16 @@ struct rte_flow_action_set_dscp {
> > > */
> > > struct rte_flow_shared_action;
> > >
> > > +/**
> > > + * RTE_FLOW_ACTION_TYPE_COLOR
> > > + *
> > > + * The meter color should be set in the packet meta-data
> > > + * (i.e. struct rte_mbuf::sched::color).
> > > + */
> > > +struct rte_flow_action_color {
> > > + enum rte_color color; /**< Green/Yellow/Red. */
> >
> > I would avoid expanding the list of colors in the comment, as we might
> have to
> > support more than 3 colors in the future. I would simply write: "Packet
> color."
> >
> > > +};
> > > +
> > > /**
> > > * Field IDs for MODIFY_FIELD action.
> > > */
> > > diff --git a/lib
Re: [dpdk-dev] [PATCH 2/6] net/hns3: fix compiling error for using SVE algorithm
On 3/23/2021 1:45 PM, Min Hu (Connor) wrote:
From: Huisong Li
The 'queue_full_cnt' stats have been encapsulated in 'dfx_stats'.
However, the modification in the SVE algorithm is omitted.
As a result, the driver fails to be compiled when the SVE
algorithm is used.
Fixes: 9b77f1fe303f ("net/hns3: encapsulate DFX stats in datapath")
Signed-off-by: Huisong Li
Signed-off-by: Min Hu (Connor)
---
drivers/net/hns3/hns3_rxtx_vec_sve.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hns3/hns3_rxtx_vec_sve.c
b/drivers/net/hns3/hns3_rxtx_vec_sve.c
index f8655fa..e1a1731 100644
--- a/drivers/net/hns3/hns3_rxtx_vec_sve.c
+++ b/drivers/net/hns3/hns3_rxtx_vec_sve.c
@@ -439,7 +439,7 @@ hns3_xmit_fixed_burst_vec_sve(void *__restrict tx_queue,
nb_pkts = RTE_MIN(txq->tx_bd_ready, nb_pkts);
if (unlikely(nb_pkts == 0)) {
- txq->queue_full_cnt++;
+ txq->dfx_stats.queue_full_cnt++;
return 0;
}
Hi Connor,
This is a very obvious build error, I am concerned how this is released. Do you
have any internal testing?
+ Aaron & Honnappa,
If we can have a build test in our public CI with SVE?
Re: [dpdk-dev] [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API
Hi Ori,
> -Original Message-
> From: Ori Kam
> Sent: Monday, March 29, 2021 10:23 AM
> To: Matan Azrad ; Dumitrescu, Cristian
> ; Li Zhang ; Dekel Peled
> ; Slava Ovsiienko ; Shahaf
> Shuler ; lir...@marvell.com; Singh, Jasvinder
> ; NBU-Contact-Thomas Monjalon
> ; Yigit, Ferruh ; Andrew
> Rybchenko ; Jerin Jacob
> ; Hemant Agrawal ;
> Ajit Khaparde
> Cc: dev@dpdk.org; Raslan Darawsheh ; Roni Bar Yanai
>
> Subject: RE: [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API
>
> Hi All,
>
> > -Original Message-
> > From: Matan Azrad
> > Subject: RE: [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API
> >
> > Hi Cristian
> >
> > Thank you for your important review!
> > I agree with all your comments except one, please see inline.
> >
> > From: Dumitrescu, Cristian
> > > Hi Li and Matan,
> > >
> > > Thank you for your proposal, some comments below.
> > >
> > > I am also adding Jerin and Hemant to this thread, as they also
> > > participated
> in
> > > the definition of the rte_mtr API in 2017. Also Ajit expressed some
> interest in
> > a
> > > previous email.
> > >
> > > > -Original Message-
> > > > From: Li Zhang
> > > > Sent: Thursday, March 18, 2021 8:58 AM
> > > > To: dek...@nvidia.com; or...@nvidia.com; viachesl...@nvidia.com;
> > > > ma...@nvidia.com; shah...@nvidia.com; lir...@marvell.com; Singh,
> > > > Jasvinder ; Thomas Monjalon
> > > > ; Yigit, Ferruh ;
> Andrew
> > > > Rybchenko ; Dumitrescu, Cristian
> > > >
> > > > Cc: dev@dpdk.org; rasl...@nvidia.com; ron...@nvidia.com
> > > > Subject: [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API
> > > >
> > > > Currently, the flow meter policy does not support multiple actions per
> > > > color; also the allowed action types per color are very limited.
> > > > In addition, the policy cannot be pre-defined.
> > > >
> > > > Due to the growing in flow actions offload abilities there is a
> > > > potential for the user to use variety of actions per color differently.
> > > > This new meter policy API comes to allow this potential in the most
> > > > ethdev common way using rte_flow action definition.
> > > > A list of rte_flow actions will be provided by the user per color in
> > > > order to create a meter policy.
> > > > In addition, the API forces to pre-define the policy before the meters
> > > > creation in order to allow sharing of single policy with multiple
> > > > meters efficiently.
> > > >
> > > > meter_policy_id is added into struct rte_mtr_params.
> > > > So that it can get the policy during the meters creation.
> > > >
> > > > Policy id 0 is default policy. Action per color as below:
> > > > green - no action, yellow - no action, red - drop
> > > >
> > > > Allow coloring the packet using a new rte_flow_action_color as could
> > > > be done by the old policy API,
> > > >
> > >
> > > The proposal essentially is to define the meter policy based on rte_flow
> > actions
> > > rather than a reduced action set defined specifically just for meter
> > > object.
> > This
> > > makes sense to me.
> > >
> > > > The next API function were added:
> > > > - rte_mtr_meter_policy_add
> > > > - rte_mtr_meter_policy_delete
> > > > - rte_mtr_meter_policy_update
> > > > - rte_mtr_meter_policy_validate
> > > > The next struct was changed:
> > > > - rte_mtr_params
> > > > - rte_mtr_capabilities
> > > > The next API was deleted:
> > > > - rte_mtr_policer_actions_update
> > > >
> > > > Signed-off-by: Li Zhang
> > > > ---
> > > > lib/librte_ethdev/rte_flow.h | 18
> > > > lib/librte_ethdev/rte_mtr.c| 55 --
> > > > lib/librte_ethdev/rte_mtr.h| 166 -
> > > > lib/librte_ethdev/rte_mtr_driver.h | 45 ++--
> > > > 4 files changed, 210 insertions(+), 74 deletions(-)
> > > >
> > > > diff --git a/lib/librte_ethdev/rte_flow.h
> > > > b/lib/librte_ethdev/rte_flow.h index 669e677e91..5f38aa7fa4 100644
> > > > --- a/lib/librte_ethdev/rte_flow.h
> > > > +++ b/lib/librte_ethdev/rte_flow.h
> > > > @@ -31,6 +31,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > #ifdef __cplusplus
> > > > extern "C" {
> > > > @@ -2236,6 +2237,13 @@ enum rte_flow_action_type {
> > > >* See struct rte_flow_action_modify_field.
> > > >*/
> > > > RTE_FLOW_ACTION_TYPE_MODIFY_FIELD,
> > > > +
> > > > + /**
> > > > + * Color the packet to reflect the meter color result.
> > > > + *
> > > > + * See struct rte_flow_action_color.
> > > > + */
> > > > + RTE_FLOW_ACTION_TYPE_COlOR,
> > >
> > > Typo here, it should be RTE_FLOW_ACTION_TYPE_COLOR.
> > >
>
> Why do we need this action?
We need this new proposed RTE_FLOW_ACTION_TYPE_COLOR action to set the packet
color in the packet mbuf (i.e. in the mbuf::sched:color field) in order to tell
the later stages of the pipeline what the packet color is.
> if it is to save the color it should be done by using mark/metadata
As stated in its descr
[dpdk-dev] [PATCH] doc: remove obsolete future considerations in flow guide
After 4 years, rte_flow has evolved enough to not require special notes about what could be added in future. Part of the removed plans were obsolete anyway. Signed-off-by: Thomas Monjalon --- doc/guides/prog_guide/rte_flow.rst | 38 +- 1 file changed, 1 insertion(+), 37 deletions(-) diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index 62a57919eb..c6cef43bdd 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -719,9 +719,6 @@ Most of these are basically protocol header definitions with associated bit-masks. They must be specified (stacked) from lowest to highest protocol layer to form a matching pattern. -The following list is not exhaustive, new protocols will be added in the -future. - Item: ``ANY`` ^ @@ -1523,8 +1520,7 @@ that VOID is ignored. Action types -Common action types are described in this section. Like pattern item types, -this list is not exhaustive as new actions will be added in the future. +Common action types are described in this section. Action: ``END`` ^^^ @@ -2854,19 +2850,6 @@ A method to generate them remains to be defined. Application may use PMD dynamic items or actions in flow rules. In that case size of configuration object in dynamic element must be a pointer size. -Planned types -~ - -Pattern item types will be added as new protocols are implemented. - -Variable headers support through dedicated pattern items, for example in -order to match specific IPv4 options and IPv6 extension headers would be -stacked after IPv4/IPv6 items. - -Other action types are planned but are not defined yet. These include the -ability to alter packet data in several ways, such as performing -encapsulation/decapsulation of tunnel headers. - Rules management @@ -3361,8 +3344,6 @@ so the API level protection is disabled. Please note that this API-level mutex protects only rte_flow functions, other control path functions are not in scope. -More will be added over time. - Device compatibility @@ -3511,22 +3492,5 @@ PMDs. - In order to save priority levels, PMDs may evaluate whether rules are likely to collide and adjust their priority accordingly. -Future evolutions -- - -- A device profile selection function which could be used to force a - permanent profile instead of relying on its automatic configuration based - on existing flow rules. - -- A method to optimize *rte_flow* rules with specific pattern items and - action types generated on the fly by PMDs. DPDK should assign negative - numbers to these in order to not collide with the existing types. See - `Negative types`_. - -- Adding specific egress pattern items and actions as described in - `Attribute: Traffic direction`_. - -- Optional software fallback when PMDs are unable to handle requested flow - rules so applications do not have to implement their own. .. _OpenFlow Switch Specification: https://www.opennetworking.org/software-defined-standards/specifications/ -- 2.30.1
Re: [dpdk-dev] [PATCH v3] pflock: implementation of phase-fair reader writer locks
On Mon, 29 Mar 2021 03:14:29 + Honnappa Nagarahalli wrote: > > > > Subject: [PATCH v3] pflock: implementation of phase-fair reader writer locks > > > > This is a new type of reader-writer lock that provides better fairness > > guarantees which makes it better for typical DPDK applications. > > They lock internally uses two ticket pools, one for readers and one for > The > > > writers. > > > > Phase fair reader writer locks ensure that neither reader or writer will be > > starved. Neither reader or writer are preferred, they execute in alternating > > phases. All operations of the same time (reader or writer) that try to > > acquire > type > > > the lock are handled in FIFO order. Write operations are exclusive, and > > multiple read operations can be run together (until a write arrives). > > > > A similar implementation is in Concurrency Kit package in FreeBSD. > > For more information see: > >"Reader-Writer Synchronization for Shared-Memory Multiprocessor > > Real-Time Systems", > > http://www.cs.unc.edu/~anderson/papers/ecrts09b.pdf > > > > Signed-off-by: Stephen Hemminger Any more comments? Other than the typos in the commit log...
Re: [dpdk-dev] rte_flow ageing
Hello David, Thanks for reaching out, I'll try to answer as best as I know and I added Matan who will be able to provide further info during next week. First, according to our pmd documentation (http://doc.dpdk.org/guides/nics/mlx5.html#supported-hardware-offloads) we recommend using DPDK20.11 and OFED5.2, and not the combo you are referring to. Second, we can always improve our documentation and I appreciate your queries. Please see my comments inline. Regards, Asaf Penso >-Original Message- >From: dev On Behalf Of David Bouyeure >Sent: Monday, March 29, 2021 11:35 AM >To: dev@dpdk.org >Subject: [dpdk-dev] rte_flow ageing > >Hi, > > >I've found out the pretty useful experimental brand new flow ageing API >implemented in the mlx5 PMD. It is useful and I hope you'll fully understand at the end why 😊 > >I'm trying it (rte_eth_dev_callback_register(RTE_ETH_EVENT_FLOW_AGED), >RTE_FLOW_ACTION_TYPE_AGE) to recover any flow that I previously >offloaded. > >The DPDK version is 20.08 and Mellanox(Connect-X6) OFED drivers are 5.1- >2.5.8.0. > See above the suggested versions for this feature >I eventually don't see the usefulness of the callback since it's actually >triggered >indirectly by us(the DPDK application) when calling >rte_flow_get_aged_flows(). The main intention is to offload the aging logic from the application level to the pmd level. There is so saving of cpu cycles, and the gain here is with simplicity. The application doesn't need to have complex logic of comparison between counters or other HW info that can be retrieve. Now, the pmd hides all of that and leaves the application only to decide what to do with the flows that are aged out. Please note, the pmd does not delete any flow, just provide the list of all the flows that are aged. > If we don't call it, the callback is called only once. > >And, calling rte_flow_get_aged_flows() from the callback won't trigger it next >time(MLX5_AGE_TRIGGER is reset after the callback call) Once you call the function the pmd will not trigger more events. Now it's up to the application to decide what to do. Doing it differently, will cause an interrupt storm and the pmd avoids that. If new flows are aged then the pmd will trigger a new event. > >Furthermore, I don't see the point of computing ageing flows in >mlx5_fow.c::mlx5_flow_aging_check() if the client callback isn't called. > Can you elaborate? I'm not sure I understand your intention. >So far, I can handle the flow ageing from the same thread as the one which is >handling the flow direction(rte_flow), it even avoid threads synchronization. >But, in the future, I may need to be noticed as soon as possible of a single >flow >ageing, and thus handle this flow logic from the ageing callback. > > >I may misunderstand the whole ageing API... Thanks a lot for any clarification.
Re: [dpdk-dev] [PATCH v3] pflock: implementation of phase-fair reader writer locks
> > > > > Subject: [PATCH v3] pflock: implementation of phase-fair reader > > > writer locks > > > > > > This is a new type of reader-writer lock that provides better > > > fairness guarantees which makes it better for typical DPDK applications. > > > They lock internally uses two ticket pools, one for readers and one > > > for > > The > > > > > writers. > > > > > > Phase fair reader writer locks ensure that neither reader or writer > > > will be starved. Neither reader or writer are preferred, they > > > execute in alternating phases. All operations of the same time > > > (reader or writer) that try to acquire > > > > type > > > > > the lock are handled in FIFO order. Write operations are exclusive, > > > and multiple read operations can be run together (until a write arrives). > > > > > > A similar implementation is in Concurrency Kit package in FreeBSD. > > > For more information see: > > >"Reader-Writer Synchronization for Shared-Memory Multiprocessor > > > Real-Time Systems", > > > http://www.cs.unc.edu/~anderson/papers/ecrts09b.pdf > > > > > > Signed-off-by: Stephen Hemminger > > Any more comments? Other than the typos in the commit log... There are additional comments in the code (in librte_eal/include/generic/rte_pflock.h), you need to scroll down as the test code is on the top. I did not take a deeper look at the test code yet.
Re: [dpdk-dev] [PATCH] drivers/net: remove useless autoneg capability
On Mon, Mar 29, 2021 at 12:29 AM Thomas Monjalon wrote: > > The flag ETH_LINK_SPEED_AUTONEG is 0, > so it cannot be used in a capability bitmap. > > Having 0 in speed capability means all speeds are accepted. > > Signed-off-by: Thomas Monjalon > --- > drivers/net/bnxt/bnxt_ethdev.c | 2 -- For bnxt Acked-by: Ajit Khaparde > drivers/net/mlx5/linux/mlx5_ethdev_os.c | 4 > 2 files changed, 6 deletions(-) > > diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c > index f1dd40591f..a2debdbb64 100644 > --- a/drivers/net/bnxt/bnxt_ethdev.c > +++ b/drivers/net/bnxt/bnxt_ethdev.c > @@ -889,8 +889,6 @@ uint32_t bnxt_get_speed_capabilities(struct bnxt *bp) > if (bp->link_info->auto_mode == > HWRM_PORT_PHY_QCFG_OUTPUT_AUTO_MODE_NONE) > speed_capa |= ETH_LINK_SPEED_FIXED; > - else > - speed_capa |= ETH_LINK_SPEED_AUTONEG; > > return speed_capa; > } > diff --git a/drivers/net/mlx5/linux/mlx5_ethdev_os.c > b/drivers/net/mlx5/linux/mlx5_ethdev_os.c > index 0e8de9439e..58d56913ae 100644 > --- a/drivers/net/mlx5/linux/mlx5_ethdev_os.c > +++ b/drivers/net/mlx5/linux/mlx5_ethdev_os.c > @@ -409,8 +409,6 @@ mlx5_link_update_unlocked_gset(struct rte_eth_dev *dev, > else > dev_link.link_speed = link_speed; > priv->link_speed_capa = 0; > - if (edata.supported & SUPPORTED_Autoneg) > - priv->link_speed_capa |= ETH_LINK_SPEED_AUTONEG; > if (edata.supported & (SUPPORTED_1000baseT_Full | >SUPPORTED_1000baseKX_Full)) > priv->link_speed_capa |= ETH_LINK_SPEED_1G; > @@ -517,8 +515,6 @@ mlx5_link_update_unlocked_gs(struct rte_eth_dev *dev, > sc = ecmd->link_mode_masks[0] | > ((uint64_t)ecmd->link_mode_masks[1] << 32); > priv->link_speed_capa = 0; > - if (sc & MLX5_BITSHIFT(ETHTOOL_LINK_MODE_Autoneg_BIT)) > - priv->link_speed_capa |= ETH_LINK_SPEED_AUTONEG; > if (sc & (MLX5_BITSHIFT(ETHTOOL_LINK_MODE_1000baseT_Full_BIT) | > MLX5_BITSHIFT(ETHTOOL_LINK_MODE_1000baseKX_Full_BIT))) > priv->link_speed_capa |= ETH_LINK_SPEED_1G; > -- > 2.30.1 >
Re: [dpdk-dev] Questions about reporting auto-negotiation capability
On Mon, Mar 29, 2021 at 12:19 AM Thomas Monjalon wrote: > > 29/03/2021 09:03, Thomas Monjalon: > > 29/03/2021 06:02, Huisong Li: > > > 'speed_capa' in struct rte_eth_dev_info is defined as follows: > > > > > > uint32_t speed_capa; /**< Supported speeds bitmap (ETH_LINK_SPEED_). */ > > > > > > > > >Most PMD drivers use this field to report the speeds capability > > > supported by the device to the upper-layer app. > > > > > > But it seems that few NICs report their auto-negotiation capability > > > through this field. If NIC also uses it to report > > > their auto-negotiation capability through this field, and should set it > > > to ETH_LINK_SPEED_AUTONEG(0) based on > > > the definition of ETH_LINK_SPEED_xxx. In this case, it conflicts the > > > report of the speeds capability . > > > > > > I don't know how to correctly report the auto-negotiation capability of > > > the device. Thanks for your reply. > > > > ETH_LINK_SPEED_AUTONEG is not for capabilities. > > Anyway, if it is set, it changes nothing (0) in the bitmap. > > I see mlx5 is wrongly using it. > > > > speed_capa is only for enumerating speeds. > > I see some drivers are advertising ETH_LINK_SPEED_FIXED in speed_capa > if the device cannot support autonegotiation. > Should we add a note in doxygen? I think we should do that. > >
Re: [dpdk-dev] [PATCH 2/6] net/hns3: fix compiling error for using SVE algorithm
Ferruh Yigit writes:
> On 3/23/2021 1:45 PM, Min Hu (Connor) wrote:
>> From: Huisong Li
>>
>> The 'queue_full_cnt' stats have been encapsulated in 'dfx_stats'.
>> However, the modification in the SVE algorithm is omitted.
>> As a result, the driver fails to be compiled when the SVE
>> algorithm is used.
>>
>> Fixes: 9b77f1fe303f ("net/hns3: encapsulate DFX stats in datapath")
>>
>> Signed-off-by: Huisong Li
>> Signed-off-by: Min Hu (Connor)
>> ---
>> drivers/net/hns3/hns3_rxtx_vec_sve.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/hns3/hns3_rxtx_vec_sve.c
>> b/drivers/net/hns3/hns3_rxtx_vec_sve.c
>> index f8655fa..e1a1731 100644
>> --- a/drivers/net/hns3/hns3_rxtx_vec_sve.c
>> +++ b/drivers/net/hns3/hns3_rxtx_vec_sve.c
>> @@ -439,7 +439,7 @@ hns3_xmit_fixed_burst_vec_sve(void *__restrict tx_queue,
>> nb_pkts = RTE_MIN(txq->tx_bd_ready, nb_pkts);
>> if (unlikely(nb_pkts == 0)) {
>> -txq->queue_full_cnt++;
>> +txq->dfx_stats.queue_full_cnt++;
>> return 0;
>> }
>>
>>
>
> Hi Connor,
>
> This is a very obvious build error, I am concerned how this is
> released. Do you have any internal testing?
>
> + Aaron & Honnappa,
>
> If we can have a build test in our public CI with SVE?
Maybe it's possible - we might need to expand the aarch64 cross builds
with a bit of extra information. I'm not sure which compiler is needed,
though. Currently, we install whatever ubuntu18.04 is providing - I
don't know if it has the SVE extensions needed. Honnappa/ARM folks can
provide more information that way - though I would expect it's just a
setting that can be changed in the host_machine or properties section of
the cross-config file.
If that's known (maybe we need to use the thunderx2 config or something
else? I don't know too much about enabling compiler support for SVE),
then we should probably hook it up.
Re: [dpdk-dev] [PATCH v2] ethdev: introduce enable_driver_sdk to install driver headers
29/03/2021 17:23, Ferruh Yigit: > On 3/29/2021 1:10 PM, Thomas Monjalon wrote: > > 29/03/2021 11:43, Ferruh Yigit: > >> On 3/26/2021 8:52 PM, Tyler Retzlaff wrote: > >>> On Fri, Mar 26, 2021 at 12:02:55PM +, Ferruh Yigit wrote: > On 3/24/2021 4:24 PM, Tyler Retzlaff wrote: > > On Wed, Mar 24, 2021 at 12:30:36PM +0100, Thomas Monjalon wrote: > >> 24/03/2021 12:27, Ferruh Yigit: > >>> > >>> But not sure how to manage the same problem for whole project, if > >>> install all > >>> headers in one patch, or add them gradually via separate patches by > >>> time ... > >> > >> We did a cleanup in ethdev but not in other driver classes. > >> When the cleanup will be done gradually, the headers > >> must move in this new category driver_sdk_headers. > > > > yes, some headers are not installed now. so they need only to have > > their api marked __rte_internal and installed (since there should be no > > external consumer as a function of not being installed) > > > > the more difficult case is where headers were installed but the api were > > not marked __rte_internal and appear in the stable version.map. for > > those i guess deprecation notice has to be issued before marking as > > internal. > > > > Are you referring to any specific APIs, can you share list of them? > >>> > >>> i can't remember the whole list but Thomas originally indicated the > >>> following candidate list. > >>> > >>> baseband/ -> librte_bbdev/rte_bbdev_pmd.h > >>> bus/ -> rte_bus.h > >>> common/ -> no interface > >>> crypto/ -> librte_cryptodev/rte_cryptodev_pmd.h > >>> event/ -> librte_eventdev/ > >>> mempool/ -> librte_mempool/ > >>> net/ -> librte_ethdev/ > >>> raw/ -> librte_rawdev/rte_rawdev_pmd.h > >>> regex/ -> librte_regexdev/rte_regexdev_driver.h > >>> vdpa/ -> librte_vhost/rte_vdpa_dev.h > >>> > >>> some of these headers are not published, some are. > >>> > >> > >> These are public headers, so they should not have '__rte_internal' > >> functions, > >> are you saying some of public headers has internal functions that are > >> presented > >> as public APIs? > > > > These are the headers for use by the drivers. > > We should classify them as SDK headers, not API. > > > > Yes, you are right, they shouldn't be public header. > > So, agree to Tyler's comment, that some of those functions needs to be > removed > from the stable API list first, which will take time. > > I can proceed with the ethdev one, any objection? +1 > And for the rest of the list, how can we fix them? I guess best option is to > distribute the work to each library, but we need an owner of the task to > follow > and communicate it. +1 +Cc techboard
Re: [dpdk-dev] [PATCH 2/6] net/hns3: fix compiling error for using SVE algorithm
On Mon, Mar 29, 2021 at 8:32 PM Aaron Conole wrote: > Ferruh Yigit writes: > > This is a very obvious build error, I am concerned how this is > > released. Do you have any internal testing? > > > > + Aaron & Honnappa, > > > > If we can have a build test in our public CI with SVE? > > Maybe it's possible - we might need to expand the aarch64 cross builds > with a bit of extra information. I'm not sure which compiler is needed, > though. Currently, we install whatever ubuntu18.04 is providing - I > don't know if it has the SVE extensions needed. Honnappa/ARM folks can > provide more information that way - though I would expect it's just a > setting that can be changed in the host_machine or properties section of > the cross-config file. > > If that's known (maybe we need to use the thunderx2 config or something > else? I don't know too much about enabling compiler support for SVE), > then we should probably hook it up. Last time I tried SVE builds, I needed a gcc 10 + tweaking cross compiler config. http://inbox.dpdk.org/dev/cajfav8ywp0qa7qg7cgahb1uly72awjzm6fodbej4royne8o...@mail.gmail.com/ Ruifeng had replied there was a gcc 10 for Ubuntu. Not sure how others compile with SVE. -- David Marchand
Re: [dpdk-dev] [PATCH 2/2] [RFC]: ethdev: manage meter API object handles by the drivers
Hi Ajit Looks like you agree with this RFC to move meter objects to be managed by PMD pointers. Thanks for the review! From: Ajit Khaparde > On Thu, Mar 25, 2021 at 1:21 AM Matan Azrad wrote: > > > > Hi Cristian > > > > From: Dumitrescu, Cristian > > > Hi Li and Matan, > > > > > > > -Original Message- > > > > From: Li Zhang > > > > Sent: Thursday, March 18, 2021 8:58 AM > > > > To: dek...@nvidia.com; or...@nvidia.com; viachesl...@nvidia.com; > > > > ma...@nvidia.com; shah...@nvidia.com; lir...@marvell.com; Singh, > > > > Jasvinder ; Thomas Monjalon > > > > ; Yigit, Ferruh ; Andrew > > > > Rybchenko ; Dumitrescu, Cristian > > > > > > > > Cc: dev@dpdk.org; rasl...@nvidia.com; ron...@nvidia.com > > > > Subject: [PATCH 2/2] [RFC]: ethdev: manage meter API object handles by > > > > the drivers > > > > > > > > Currently, all the meter objects are managed by the user IDs: > > > > meter, profile and policy. > > > > Hence, each PMD should manage data-structure in order to map each API > > > > ID to the private PMD management structure. > > > > > > > > From the application side, it has all the picture how meter is going > > > > to be assigned to flows and can easily use direct mapping even when > > > > the meter handler is provided by the PMDs. > > > > > > > > Also, this is the approach of the rte_flow API handles: > > > > the flow handle and the shared action handle is provided by the PMDs. > > > > > > > > Use drivers handlers in order to manage all the meter API objects. > > > > > > > > > > This seems to be take 2 of the discussion that we already had in this > > > thread: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dp > > > dk.org%2Farchives%2Fdev%2F2021- > > > > March%2F200710.html&data=04%7C01%7Cmatan%40nvidia.com%7Cab0 > > > > e3cc77b9e4101344e08d8ee434bbe%7C43083d15727340c1b7db39efd9ccc17a% > > > > 7C0%7C0%7C637521320105450617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > > > > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > > > > amp;sdata=94bFRICfGEzk5s53MRUvFMQe5ZlhP2Tmnu82hwUytc4%3D&re > > > served=0, so apologies for mostly summarizing my previous feedback here. > > > > > > I am against this proposal because: > > > 1. We already discussed this topic of user-provided handles vs. driver- > provided > > > handles at length on this exact email list back in 2017, when we first > introduced > > > this API, and I don't see any real reason to revisit the decision we took > > > then. > > > > Why not? > > There is more experiences\usages now. > > New drivers added the support and also now scalability is growing and > growing > > > > > > > 2. For me, it is more natural and it also helps the application to > > > simplify its > data > > > structures if the user provides its own IDs rather than the user having to > deal > > > with the IDs provided by the driver. > > > > Generally I don't think other flow DPDK APIs align with your feelings here, > > see > rte_flow object and rte_flow_shared_action. > > > > Specifically for meter: > > - here, meter is HW\driver offload where performance\rate either for > meter creation\deletion or for the actual data-path is very important > especially > when we talk on very big numbers, so "natural" has less importance here. > > We need to think on the global solution for application > > ->API->driver. in > meter feature, the user has the ability to manage the IDs better than the PMDs > for the most of the use-cases: > > 1. meter per flow: just save the driver handle in > > the app flow > context. > > 2. meter per VM\USER flows\rte_flow group\any other > > context > grouped multiple flows: just save the driver handle in the app context. > > If PMD need to map the IDs, it is more complex for sure, requires > > more > memory and more lookup time. > > > > - I'm not sure it is natural for all the use-cases, sometimes > > generating > unique ID may complex the app. > > > > > > > 3. It is much easier and portable to pass numeric and string-based IDs > around > > > (e.g. between processes) as opposed to pointer-based IDs, as pointers are > only > > > valid in one address space and not in others. There are several DPDK APIs > that > > > moved away from pointer handles to string IDs. > Pardon my ignorance.. > But which DPDK APIs moved to string IDs from pointer handles? > > > > > Yes, I agree here generally. > > But again, since meter is used only by rte_flow, it is better to align the > > same > handle mechanism. > I don't want to say - do this because rte_flow uses a pointer. > I don't have a strong opinion for one over the other. In the end the > logic can be adapted one way or the other. > But having implemented rte_flow support in the PMD, I think it is a > good idea to avoid the duplication of meter_id to pointer based handle > conversion and bookkeeping logic in the application and the PMD. > > > > > > 4. The mapping of user IDs
