From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shahaf Shuler Subject: Re: [PATCH v2 2/2] ethdev: introduce Tx queue offloads API Date: Tue, 12 Sep 2017 08:03:31 +0000 Message-ID: References: <20170911062119.GA9342@jerin> <20170911080621.GA15867@jerin> <20170911090543.GA9965@jerin> <2601191342CEEE43887BDE71AB9772584F2497DC@irsmsx105.ger.corp.intel.com> <20170912040107.GA8081@jerin> <20170912055137.GA24921@jerin> <20170912071735.GA29366@jerin> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "Ananyev, Konstantin" , Stephen Hemminger , Thomas Monjalon , "dev@dpdk.org" , "Zhang, Helin" , "Wu, Jingjing" To: Jerin Jacob Return-path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0043.outbound.protection.outlook.com [104.47.0.43]) by dpdk.org (Postfix) with ESMTP id 35BC92B84 for ; Tue, 12 Sep 2017 10:03:34 +0200 (CEST) In-Reply-To: <20170912071735.GA29366@jerin> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Tuesday, September 12, 2017 10:18 AM, Jerin Jacob: > > Tuesday, September 12, 2017 8:52 AM, Jerin Jacob: > > > > I understand the use case, and the fact those flags improve the > > > performance on low-end ARM CPUs. > > > > IMO those flags cannot be on queue/port level. They must be global. > > > > > > Where should we have it as global(in terms of API)? > > > And why it can not be at port level? > > > > Because I don't think there is a use-case that application would want t= o > have recounting on one port and not on the other. It is either applicatio= n > clone/not clone mbufs. > > Same about the multi mempool. It is either application have it or not. >=20 > Why not? If a port is given to data plane and another port to control pla= ne. It > can have different characteristics. >=20 > Making it port level, we can achieve the global use case as well. but not > another way around. >=20 > MULTISEG flag also has the same attribute. But some reason you are OK to > include that in flags. >=20 > > > > If there is a strong use-case for application to say on port X it clone= s mbufs > and and port Y it don't then maybe this is enough to have it per-port. > > We can go even further - why not to have guarantee per queue? it is > possible if application is willing to manage. > > > > Again those are not offloads, therefore if we expose those this should = on > different location the offloads field on eth conf. >=20 > What is the definition of offload? It is something we can offload to HW. > If so, then, reference count we can offload to HW with external HW pool > manager which DPDK has support now. OK, well understood the requirement for such flags. Thanks for your replies= . I think that for simplicity I will add two more flags on the Tx offloads ca= pabilities: DEV_TX_OFFLOADS _MULTI_MEMPOOL <** Device supports transmission of mbufs fr= om multiple mempools. */ DEV_TX_OFFLOADS_INDIRECT_MBUFS <** Device support transmission of indirect = mbufs. */ Those caps can be reported by the PMD as per-port/per-queue offloads. Appli= cation will choose how to set those. When not set - PMD can assume all mbuf= s has ref_cnt =3D 1 and the same mempool. Any objection?=20