From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9E02DA32A8 for ; Sat, 26 Oct 2019 06:40:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C3CB21BFC8; Sat, 26 Oct 2019 06:40:42 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id AFDC91BFC7 for ; Sat, 26 Oct 2019 06:40:40 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2019 21:40:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,230,1569308400"; d="scan'208";a="224116230" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga004.fm.intel.com with ESMTP; 25 Oct 2019 21:40:39 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 25 Oct 2019 21:40:39 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.176]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.165]) with mapi id 14.03.0439.000; Sat, 26 Oct 2019 12:40:37 +0800 From: "Wang, Haiyue" To: Thomas Monjalon , Jerin Jacob CC: "Yigit, Ferruh" , dpdk-dev , "Ye, Xiaolong" , "Kinsella, Ray" , "Iremonger, Bernard" , "Sun, Chenmin" , Andrew Rybchenko , Slava Ovsiienko , Stephen Hemminger , David Marchand , Jerin Jacob Thread-Topic: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information Thread-Index: AQHVgy4vnIA7MA5UA0Sl3pLNFwDOY6dqovQAgABMCACAABr4gIAABOkAgABrZQCAAOrKcA== Date: Sat, 26 Oct 2019 04:40:37 +0000 Message-ID: References: <20191015075133.38560-1-haiyue.wang@intel.com> <1811898.7XjjD7ZjLQ@xps> <12001140.UMXFOKstgs@xps> In-Reply-To: <12001140.UMXFOKstgs@xps> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWZmNTAwMTAtMGUxOS00YzM1LTkyZjItYzg3ZWY3MzI3ZGZjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiM2JOYXVxcTlKSU1McTA2bDhCVXIyZGZISGh1ZE5JTktoZXRxXC96SUlXSFZCUkRuWVJEc1ZwZnJwNWc5RkFwWVMifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Saturday, October 26, 2019 06:27 > To: Jerin Jacob > Cc: Yigit, Ferruh ; Wang, Haiyue ; dpdk-dev > ; Ye, Xiaolong ; Kinsella, Ray ; > Iremonger, Bernard ; Sun, Chenmin ; Andrew > Rybchenko ; Slava Ovsiienko ; Stephen Hemminger > ; David Marchand ;= Jerin Jacob > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting bu= rst mode information >=20 > 25/10/2019 18:02, Jerin Jacob: > > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon w= rote: > > > 25/10/2019 16:08, Ferruh Yigit: > > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote: > > > > > 15/10/2019 09:51, Haiyue Wang: > > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev A= PI > > > > >> that allows an application to retrieve the mode information abou= t > > > > >> Rx/Tx packet burst such as Scalar or Vector, and Vector technolo= gy > > > > >> like AVX2. > > > > > > > > > > I missed this patch. I and Andrew, maintainers of ethdev, were no= t CC'ed. > > > > > Ferruh, I would expect to be Cc'ed and/or get a notification befo= re merging. > > > > > > > > It has been discussed in the mail list and went through multiple di= scussions, > > > > patch is out since the August, +1 to cc all maintainers I missed th= at part, > > > > but when the patch is reviewed and there is no objection, why block= the merge? > > > > > > I'm not saying blocking the merge. > > > My bad is that I missed the patch and I am asking for help with a not= ification > > > in this case. Same for Andrew I guess. > > > Note: it is merged in master and I am looking to improve this feature= . > > > > > > >> +/** > > > > >> + * Ethernet device RX/TX queue packet burst mode information st= ructure. > > > > >> + * Used to retrieve information about packet burst mode setting= . > > > > >> + */ > > > > >> +struct rte_eth_burst_mode { > > > > >> + uint64_t options; > > > > >> +}; > > > > > > > > > > Why a struct for an integer? > > > > > > > > Again by a request from me, to not need to break the API if we need= to add more > > > > thing in the future. > > > > > > I would replace it with a string. This is the most flexible API. > > > > IMO, Probably, best of both worlds make a good option here, > > as Haiyue suggested if we have an additional dev_specific[1] in structu= re. > > and when a pass to the application, let common code make final string a= s > > (options flags to string + dev_specific) > > > > options flag can be zero if PMD does not have any generic flags nor > > interested in such a scheme. > > Generic flags will help at least to have some common code. > > > > [1] > > struct rte_eth_burst_mode { > > uint64_t options; > > char dev_specific[128]; /* PMD has specific burst mode informat= ion */ > > }; >=20 > I really don't see how we can have generic flags. > The flags which are proposed are just matching > the functions implemented in Intel PMDs. > And this is a complicate solution. > Why not just returning a name for the selected Rx/Tx mode? >=20 Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTI= VEC, 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Deve= lopment Kit that consists of libraries to accelerate packet processing workloads runnin= g on a wide variety of CPU architectures." If understand these new experimental APIs from above, then bit options is t= he best, and we didn't invent new words to describe them, just from the CPU & other = *generic* technology. And the application can loop to check which kind of burst is ru= nning by just simple bit test. If PMDs missed these, they can update them in future roadmaps to enhance th= eir PMDs, like MLX5 supports ARM NEON, x86 SSE.