From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: "Ye, Xiaolong" <xiaolong.ye@intel.com>
Cc: "Xing, Beilei" <beilei.xing@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] net/ice: remove bulk alloc compile option
Date: Fri, 6 Mar 2020 23:29:30 +0000 [thread overview]
Message-ID: <039ED4275CED7440929022BC67E70611547DB595@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <20200306084626.GB18727@intel.com>
> -----Original Message-----
> From: Ye, Xiaolong <xiaolong.ye@intel.com>
> Sent: Friday, March 6, 2020 4:46 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Xing, Beilei <beilei.xing@intel.com>; dev@dpdk.org; stable@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@dpdk.org
> >
> >Signed-off-by: Qi Zhang <qi.z.zhang@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@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
next prev parent reply other threads:[~2020-03-06 23:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-04 11:40 Qi Zhang
2020-03-06 8:46 ` Ye Xiaolong
2020-03-06 23:29 ` Zhang, Qi Z [this message]
2020-03-08 4:13 ` Ye Xiaolong
-- strict thread matches above, loose matches on Subject: below --
2020-03-04 11:39 Qi Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=039ED4275CED7440929022BC67E70611547DB595@SHSMSX103.ccr.corp.intel.com \
--to=qi.z.zhang@intel.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=stable@dpdk.org \
--cc=xiaolong.ye@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).