[dpdk-stable] [PATCH] net/ice: remove bulk alloc compile option

Zhang, Qi Z qi.z.zhang at intel.com
Sat Mar 7 00:29:30 CET 2020



> -----Original Message-----
> From: Ye, Xiaolong <xiaolong.ye at intel.com>
> Sent: Friday, March 6, 2020 4:46 PM
> To: Zhang, Qi Z <qi.z.zhang at intel.com>
> Cc: Xing, Beilei <beilei.xing at intel.com>; dev at dpdk.org; stable at dpdk.org
> Subject: Re: [PATCH] net/ice: remove bulk alloc compile option
> 
> Hi, Qi
> 
> Thanks for the cleanup.
> 
> On 03/04, Qi Zhang wrote:
> >Remove CONFIG_RTE_LIBRTE_ICE_RX_ALLOW_BULK_ALLOC with below
> >consideration:
> >
> >1. a default Rx path can always be selected by setting a proper
> >   rx_free_thresh value at runtime, see
> >   ice_check_rx_burst_bulk_alloc_preconditions.
> >
> >2. its not a big deal to always reserve more space for desc ring.
> >   "ring_size = (uint16_t)(rxq->nb_rx_desc + ICE_RX_MAX_BURST);"
> >
> >3. Fixes a potential invalid memory access in ice_reset_rx_queue.
> >   if CONFIG_RTE_LIBRTE_ICE_RX_ALLOW_BULK_ALLOC is turned on while
> >   ice_check_rx_burst_bulk_alloc_preconditions return fail.
> >   below code will have problem.
> >
> >   for (i = 0; i < ICE_RX_MAX_BURST; ++i)
> >   	rxq->sw_ring[rxq->nb_rx_desc + i].mbuf = &rxq->fake_mbuf;
> >
> >Fixes: 50370662b727 ("net/ice: support device and queue ops")
> >Cc: stable at dpdk.org
> >
> >Signed-off-by: Qi Zhang <qi.z.zhang at intel.com>
> >---
> > config/common_base         |  1 -
> > doc/guides/nics/ice.rst    |  4 ---
> > drivers/net/ice/ice_rxtx.c | 64
> >++++++++++------------------------------------
> > 3 files changed, 13 insertions(+), 56 deletions(-)
> >
> >diff --git a/config/common_base b/config/common_base index
> >7ca2f28b1..c31175f9d 100644
> >--- a/config/common_base
> >+++ b/config/common_base
> >@@ -337,7 +337,6 @@ CONFIG_RTE_LIBRTE_ICE_PMD=y
> >CONFIG_RTE_LIBRTE_ICE_DEBUG_RX=n
> CONFIG_RTE_LIBRTE_ICE_DEBUG_TX=n
> >CONFIG_RTE_LIBRTE_ICE_DEBUG_TX_FREE=n
> >-CONFIG_RTE_LIBRTE_ICE_RX_ALLOW_BULK_ALLOC=y
> > CONFIG_RTE_LIBRTE_ICE_16BYTE_RX_DESC=n
> >
> > # Compile burst-oriented IAVF PMD driver diff --git
> >a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst index
> >cde3fd620..8af32dabf 100644
> >--- a/doc/guides/nics/ice.rst
> >+++ b/doc/guides/nics/ice.rst
> >@@ -54,10 +54,6 @@ Please note that enabling debugging options may
> affect system performance.
> >
> >   Toggle display of generic debugging messages.
> >
> >-- ``CONFIG_RTE_LIBRTE_ICE_RX_ALLOW_BULK_ALLOC`` (default ``y``)
> >-
> >-  Toggle bulk allocation for RX.
> >-
> > - ``CONFIG_RTE_LIBRTE_ICE_16BYTE_RX_DESC`` (default ``n``)
> >
> >   Toggle to use a 16-byte RX descriptor, by default the RX descriptor is 32
> byte.
> >diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
> >index 60c411bfa..c7e5fc484 100644
> >--- a/drivers/net/ice/ice_rxtx.c
> >+++ b/drivers/net/ice/ice_rxtx.c
> >@@ -236,17 +236,15 @@ _ice_rx_queue_release_mbufs(struct
> ice_rx_queue *rxq)
> > 			rxq->sw_ring[i].mbuf = NULL;
> > 		}
> > 	}
> >-#ifdef RTE_LIBRTE_ICE_RX_ALLOW_BULK_ALLOC
> >-		if (rxq->rx_nb_avail == 0)
> >-			return;
> >-		for (i = 0; i < rxq->rx_nb_avail; i++) {
> >-			struct rte_mbuf *mbuf;
> >-
> >-			mbuf = rxq->rx_stage[rxq->rx_next_avail + i];
> >-			rte_pktmbuf_free_seg(mbuf);
> >-		}
> >-		rxq->rx_nb_avail = 0;
> >-#endif /* RTE_LIBRTE_ICE_RX_ALLOW_BULK_ALLOC */
> >+	if (rxq->rx_nb_avail == 0)
> >+		return;
> >+	for (i = 0; i < rxq->rx_nb_avail; i++) {
> >+		struct rte_mbuf *mbuf;
> >+
> >+		mbuf = rxq->rx_stage[rxq->rx_next_avail + i];
> >+		rte_pktmbuf_free_seg(mbuf);
> >+	}
> 
> How about just
> 
> 	for (i = 0; i < rxq->rx_nb_avail; i++)
> 		rte_pktmbuf_free_seg(rxq->rx_stage[rxq->rx_next_avail + i]);

I just remove the compile option and keep the code unchanged, but no objection for your suggestion. 

> 
> [snip]
> 
> For the rest,
> 
> Acked-by: Xiaolong Ye <xiaolong.ye at intel.com>
> 
> And can this cleanup be applied to i40e as well? I think it's good to have less
> configurations generally.

I40e should be similar with a little bit complexity, I will take chance to cleanup later.

Thanks
Qi

> 
> Thanks,
> Xiaolong


More information about the stable mailing list