From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 5F1C86D45 for ; Mon, 11 Sep 2017 13:02:18 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2017 04:02:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,377,1500966000"; d="scan'208";a="310271145" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by fmsmga004.fm.intel.com with ESMTP; 11 Sep 2017 04:02:16 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.75]) by IRSMSX151.ger.corp.intel.com ([169.254.4.108]) with mapi id 14.03.0319.002; Mon, 11 Sep 2017 12:02:08 +0100 From: "Ananyev, Konstantin" To: Jerin Jacob , Shahaf Shuler CC: Stephen Hemminger , Thomas Monjalon , "dev@dpdk.org" , "Zhang, Helin" , "Wu, Jingjing" Thread-Topic: [dpdk-dev] [PATCH v2 2/2] ethdev: introduce Tx queue offloads API Thread-Index: AQHTKsI3jtYVV+5GM0mY6B3CcHR52aKvJhUAgAAaeYCAAALgAIAAC04AgAAFSACAACXSAA== Date: Mon, 11 Sep 2017 11:02:07 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772584F2497DC@irsmsx105.ger.corp.intel.com> References: <20170910104827.11da9230@xeon-e3> <20170911062119.GA9342@jerin> <20170911080621.GA15867@jerin> <20170911090543.GA9965@jerin> In-Reply-To: <20170911090543.GA9965@jerin> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTY5Y2U5OGUtYjYwZS00MGJjLWIwOWUtZmQ1Y2ViYjY4NjYxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImN4dmwwdk9YaVN1MVhIYUpaaFdBK292bVVOVUFnUWpVdjZhZHFDZlNaWGs9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 2/2] ethdev: introduce Tx queue offloads API 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: Mon, 11 Sep 2017 11:02:19 -0000 > > > > > > > > I don't understand. > > > > From the exact link above, you explicitly say that *you* will move = this flags > > > once the series is integrated. Quoting: > > > > > > > > " > > > > > Please Jerin, could you work on moving these settings in a new AP= I? > > > > > > > > Sure. Once the generic code is in place. We are committed to fix th= e > > > > PMDs by 18.02. > > > > > > Yes. I will take care of the PMD(nicvf) side of the changes. Not in e= thdev or > > > mempool. Meaning, you need to decide how you are going to expose the > > > equivalent of these flags and enable the generic code for those flags= in > > > ethdev or mempool. The drivers side of changes I can take care. > > > > > > > How about doing it a PMD option? > > Seems like nicvf is the only PMD which care about them. >=20 > Lets take flag by flag: > ETH_TXQ_FLAGS_NOMULTMEMP - I think, this should be removed. But we can ha= ve > common code in ethdev pmd to detect all pool being configured from on the= same pool > as on the rx_configure() application passes the mempool. This is TX offloads, not RX. At tx_queue_setup() user doesn't have to provide the mempool pointer, and can pass mbuf from any mempool to the TX routine. BTW, how do you know one which particular mempool to use? Still read it from xmitted mbuf (At least first one), I presume? >=20 > ETH_TXQ_FLAGS_NOREFCOUNT: This one has i40e and nicvf consumers. About i40e - as far as I know, no-one use i40e PMD with this flag. As far as I remember, it was added purely for benchmarking purposes on some= early stages. So my vote would be to remove it from i40e. Helin, Jingjing - what are your thoughts here. About nicvf - as I can see it is used only in conjunction with ETH_TXQ_FLAG= S_NOMULTMEMP, never alone. My understanding is that current meaning of these flags is a promise for PMD that for that particular TX queue user would submit on= ly mbufs that: - all belong to the same mempool - always would have refcount=3D=3D1 - would always be a direct ones (no indirect mbufs) So literally, yes it is not a TX HW offload, though I understand your inten= tion to have such possibility - it might help to save some cycles.=20 Wonder would some new driver specific function would help in that case? nicvf_txq_pool_setup(portid, queueid, struct rte_mempool *txpool, uint32_t = flags); or so? So the user can call it just before rte_eth_tx_queue_setup()? Konstantin > And it is driven by the use case too. So it should available in some > form.=09 >=20 > > > > If there will be more PMDs later, we can think about which API is neede= d. > >