From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 216F07CBD for ; Wed, 13 Sep 2017 11:32:18 +0200 (CEST) Received: from pure.maildistiller.com (dispatch1.mdlocal [10.7.20.164]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 7D38F60065; Wed, 13 Sep 2017 09:32:17 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx4-us4.ppe-hosted.com (filterqueue.mdlocal [10.7.20.246]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 02287260049; Wed, 13 Sep 2017 09:32:17 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx4-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id AD54FB8005E; Wed, 13 Sep 2017 09:32:16 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 13 Sep 2017 10:32:11 +0100 To: Ferruh Yigit , CC: Ivan Malov References: <1504880151-15394-1-git-send-email-arybchenko@solarflare.com> <1504880151-15394-2-git-send-email-arybchenko@solarflare.com> <888cc02a-07f9-204a-c59a-8bd35431e49b@intel.com> From: Andrew Rybchenko Message-ID: <3393c629-1309-ae63-8f36-5dbd2e7e9f44@solarflare.com> Date: Wed, 13 Sep 2017 12:32:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <888cc02a-07f9-204a-c59a-8bd35431e49b@intel.com> Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23326.003 X-TM-AS-Result: No--16.615300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1505295137-xbnVTKIexLDr Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH 2/2] net/sfc: free mbufs in bulks on simple EF10 Tx datapath reap X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 09:32:18 -0000 On 09/12/2017 09:28 PM, Ferruh Yigit wrote: > On 9/8/2017 3:15 PM, Andrew Rybchenko wrote: >> From: Ivan Malov >> >> Signed-off-by: Ivan Malov >> Signed-off-by: Andrew Rybchenko >> --- >> doc/guides/nics/sfc_efx.rst | 4 +++- >> drivers/net/sfc/sfc_dp_tx.h | 2 ++ >> drivers/net/sfc/sfc_ef10_tx.c | 15 ++++++++++++++- >> drivers/net/sfc/sfc_ethdev.c | 6 ++++++ >> drivers/net/sfc/sfc_tx.c | 17 +++++++++++++++++ >> 5 files changed, 42 insertions(+), 2 deletions(-) >> >> diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst >> index 973a4a0..028b980 100644 >> --- a/doc/guides/nics/sfc_efx.rst >> +++ b/doc/guides/nics/sfc_efx.rst >> @@ -245,12 +245,14 @@ boolean parameters value. >> features available and required by the datapath implementation. >> **efx** chooses libefx-based datapath which supports VLAN insertion >> (full-feature firmware variant only), TSO and multi-segment mbufs. >> + Mbuf segments may come from different mempools, and mbuf reference >> + counters are treated responsibly. > This is also the case for ef10 native, right? Does it make sense to > document it in below too? Thanks, will add. >> **ef10** chooses EF10 (SFN7xxx, SFN8xxx) native datapath which is >> more efficient than libefx-based but has no VLAN insertion and TSO >> support yet. >> **ef10_simple** chooses EF10 (SFN7xxx, SFN8xxx) native datapath which >> is even more faster then **ef10** but does not support multi-segment >> - mbufs. >> + mbufs, disallows multiple mempools and neglects mbuf reference counters. >> >> - ``perf_profile`` [auto|throughput|low-latency] (default **throughput**) >> > <...> > >> --- a/drivers/net/sfc/sfc_ef10_tx.c >> +++ b/drivers/net/sfc/sfc_ef10_tx.c >> @@ -401,14 +401,25 @@ struct sfc_ef10_txq { >> pending += sfc_ef10_tx_process_events(txq); >> >> if (pending != completed) { >> + struct rte_mbuf *bulk[SFC_TX_REAP_BULK_SIZE]; >> + unsigned int nb = 0; >> + >> do { >> struct sfc_ef10_tx_sw_desc *txd; >> >> txd = &txq->sw_ring[completed & ptr_mask]; >> >> - rte_pktmbuf_free_seg(txd->mbuf); >> + if (nb == RTE_DIM(bulk)) { >> + rte_mempool_put_bulk(bulk[0]->pool, >> + (void *)bulk, nb); > same warning here, again false positive I think: > error #3656: variable "bulk" may be used before its value is set I think this one is false positive as well. > The patch to ignore the warning will take care of this one too. > >> + nb = 0; >> + } >> + >> + bulk[nb++] = txd->mbuf; >> } while (++completed != pending); >> >> + rte_mempool_put_bulk(bulk[0]->pool, (void *)bulk, nb); >> + >> txq->completed = completed; >> } > <...> >