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 4252AA32A8 for ; Sat, 26 Oct 2019 11:31:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4D80D1BF97; Sat, 26 Oct 2019 11:31:49 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id A40EF1BF96 for ; Sat, 26 Oct 2019 11:31:47 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2019 02:31:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,231,1569308400"; d="scan'208";a="229170159" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga002.fm.intel.com with ESMTP; 26 Oct 2019 02:31:46 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sat, 26 Oct 2019 02:31:46 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sat, 26 Oct 2019 02:31:45 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.176]) by SHSMSX152.ccr.corp.intel.com ([10.239.6.52]) with mapi id 14.03.0439.000; Sat, 26 Oct 2019 17:31:44 +0800 From: "Wang, Haiyue" To: Slava Ovsiienko , Thomas Monjalon , Jerin Jacob CC: "Yigit, Ferruh" , dpdk-dev , "Ye, Xiaolong" , "Kinsella, Ray" , "Iremonger, Bernard" , "Sun, Chenmin" , Andrew Rybchenko , 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: AQHVgy4vnIA7MA5UA0Sl3pLNFwDOY6dqovQAgABMCACAABr4gIAABOkAgABrZQCAAInZgIAAs7AA Date: Sat, 26 Oct 2019 09:31:42 +0000 Message-ID: References: <20191015075133.38560-1-haiyue.wang@intel.com> <1811898.7XjjD7ZjLQ@xps> <12001140.UMXFOKstgs@xps> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjU4MDNhNGQtMDVkNy00MDI1LWE3YzgtYzUxNzQwMjEwYTU0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoieDdGd0JnZlwvSTFjQTZHOVNsZlpuMHZIalFqVFNLRE04SjV5N3F3YXlZNEFwV0d3ZFRrQkRpcmVxa2VmZ1JMTUMifQ== 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: Slava Ovsiienko [mailto:viacheslavo@mellanox.com] > Sent: Saturday, October 26, 2019 14:41 > To: Thomas Monjalon ; Jerin Jacob > Cc: Yigit, Ferruh ; Wang, Haiyue ; dpdk-dev > ; Ye, Xiaolong ; Kinsella, Ray ; > Iremonger, Bernard ; Sun, Chenmin ; Andrew > Rybchenko ; 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 >=20 >=20 > > -----Original Message----- > > From: Thomas Monjalon > > Sent: Saturday, October 26, 2019 1:27 > > To: Jerin Jacob > > Cc: Ferruh Yigit ; Haiyue Wang > > ; dpdk-dev ; > > xiaolong.ye@intel.com; ray.kinsella@intel.com; Bernard Iremonger > > ; chenmin.sun@intel.com; Andrew > > Rybchenko ; Slava Ovsiienko > > ; Stephen Hemminger > > ; David Marchand > > ; Jerin Jacob > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting = burst > > mode information > > > > 25/10/2019 18:02, Jerin Jacob: > > > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon > > wrote: > > > > 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 > > > > > >> API that allows an application to retrieve the mode informatio= n > > > > > >> about Rx/Tx packet burst such as Scalar or Vector, and Vector > > > > > >> technology like AVX2. > > > > > > > > > > > > I missed this patch. I and Andrew, maintainers of ethdev, were = not > > CC'ed. > > > > > > Ferruh, I would expect to be Cc'ed and/or get a notification be= fore > > merging. > > > > > > > > > > It has been discussed in the mail list and went through multiple > > > > > discussions, patch is out since the August, +1 to cc all > > > > > maintainers I missed that part, but when the patch is reviewed an= d > > 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 > > > > notification in this case. Same for Andrew I guess. > > > > Note: it is merged in master and I am looking to improve this featu= re. > > > > > > > > >> +/** > > > > > >> + * Ethernet device RX/TX queue packet burst mode information > > structure. > > > > > >> + * Used to retrieve information about packet burst mode setti= ng. > > > > > >> + */ > > > > > >> +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 structure. > > > and when a pass to the application, let common code make final string > > > as (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 > > > information */ }; > > > > I really don't see how we can have generic flags. > > The flags which are proposed are just matching the functions implemente= d in > > Intel PMDs. > > And this is a complicate solution. > > Why not just returning a name for the selected Rx/Tx mode? > > > +1 > Just an example, mlx5 PMD now has approx. 60 tx_burst routines and most = of these ones > are not related to vectorized variations (but to tx offloads). Returning = the name would be more > flexible and informative. >=20 > It is very common case to ask customer about which tx routine is engaged = with particular settings, > now we have to ask to build the debug version and present the log. >=20 Yes, this API is from that VPP can't get the static function by default com= pile options. Current design is from CPU's view like vectorized, mbuf bulk allocation. We= think it can be bit data. Name is not good for this, you have to strcat them for differe= nt combinations. But for hardware specific, name is a good one. We didn't design this API fo= r this at first. ;-) > With best regards, Slava