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 14DBBA0352; Sun, 3 Nov 2019 20:31:28 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3F2A51D414; Sun, 3 Nov 2019 20:31:27 +0100 (CET) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70080.outbound.protection.outlook.com [40.107.7.80]) by dpdk.org (Postfix) with ESMTP id 2CAB41D14C for ; Sun, 3 Nov 2019 20:31:26 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XjB67YVF8K3A/VO7+JAMPvIhREXjxCvQK0QukqlNt9AzF/gcjJWib6aZunO9g5onTvBqP3s+lUPV1RRwKaOuSQVPkmPxd4VUO6g0vy7huGDw43aSs/mIDJ8fwFdmvdEMXs9r1nrVqJEJ82EPWOUHC7k3bYWIjJIVBhdFPgZFvuMAmK057z8wbuYXOYaYlewHTRvt4zQBAXCJi0r9OdYXVTeXHUCbEN0GPV8N7Zl1DBjBcaqgiUFwg5luSnYUyl4p52yPXwObvFFWPSAthHpsELel0doOn6SzadhXXWmPaNW8iJH540I16t2N+gjYxoi1Oe3r45lpKaXgun2HUyGxhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=etDBtC8/5Au3CelZ4HgFuTpIw8vnRAmcjQ1WipP9Rdk=; b=iEqA9cGGFSPiGXG1vFyZRCdACCuqaiDKpvIHK7wtcn8KKXxBL1YeliKLO2Vq07mV/b8NytsG65OnrpjFb0KDaQPUyik4H1ctgDiWbYjc8yPmhBxfq7UAceRqpXIC64veBaKsRiHu4thAaF0cOTZdmFq7ewvik/pLjf96WW/JVDWdbWDpRao0F85t9NHz7jpffO8TlQ/p+qznQ49pyBqQK1aYfJSKucfp8V88ro9VArH8WpuUydKdYjh36Lv1cNUAR6O7FdQkNbTPRRik0hYNkUsi/UWbtYRni6ice+iAZCQw/ZOx/AcgyB6zFiJQuylqWu4BxbBbr+0nEKyRcFd7LQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=etDBtC8/5Au3CelZ4HgFuTpIw8vnRAmcjQ1WipP9Rdk=; b=URQJ81rulled3AGwrDYRn60fsW8zg4SYLgA955Dc+p5dwMGKN+tF/BrYavBK1Y/mWa7kQTlxRw7kNZnCURUcoPek6jZT3vbJCJCqS7j3OKniESviqs05xh/7HUcvs8PmavAlomWCl7sRROl97lwmy+eWyMi5OPFkgJj6Wyim+D0= Received: from AM4PR05MB3265.eurprd05.prod.outlook.com (10.171.188.154) by AM4PR05MB3473.eurprd05.prod.outlook.com (10.170.126.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Sun, 3 Nov 2019 19:31:24 +0000 Received: from AM4PR05MB3265.eurprd05.prod.outlook.com ([fe80::9940:94f2:db23:aa2c]) by AM4PR05MB3265.eurprd05.prod.outlook.com ([fe80::9940:94f2:db23:aa2c%4]) with mapi id 15.20.2408.024; Sun, 3 Nov 2019 19:31:24 +0000 From: Slava Ovsiienko To: "Wang, Haiyue" , "Liu, Yu Y" , Thomas Monjalon CC: "dev@dpdk.org" , "arybchenko@solarflare.com" , "Yigit, Ferruh" , "jerinjacobk@gmail.com" , "Ye, Xiaolong" , "Kinsella, Ray" , "Sun, Chenmin" , "Damjan Marion (damarion)" Thread-Topic: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information Thread-Index: AQHVkQY1BkrzvtNkw0WO7M2IFajIc6d3WxAAgAAYC4CAABc7cIABMfAAgABZXWCAAD69gIAAcWKA Date: Sun, 3 Nov 2019 19:31:24 +0000 Message-ID: References: <20191031171139.105110-1-haiyue.wang@intel.com> <20191031171139.105110-3-haiyue.wang@intel.com> <20693558.VL3dRorq05@xps> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=viacheslavo@mellanox.com; x-originating-ip: [95.164.10.10] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: cee4aebd-5953-44f6-b62a-08d7609469ec x-ms-traffictypediagnostic: AM4PR05MB3473: x-ms-exchange-purlcount: 2 x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 0210479ED8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(136003)(39860400002)(366004)(376002)(13464003)(189003)(199004)(66446008)(64756008)(8936002)(110136005)(8676002)(4326008)(486006)(256004)(76176011)(102836004)(14454004)(33656002)(45080400002)(25786009)(30864003)(52536014)(53546011)(7696005)(6506007)(11346002)(476003)(446003)(14444005)(966005)(6246003)(5660300002)(86362001)(229853002)(99286004)(66476007)(316002)(54906003)(81156014)(26005)(81166006)(6436002)(71190400001)(478600001)(71200400001)(3846002)(6116002)(2906002)(7736002)(7416002)(6306002)(66066001)(55016002)(66946007)(76116006)(9686003)(305945005)(74316002)(186003)(66556008)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR05MB3473; H:AM4PR05MB3265.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EJov8PgWEhaxz/11/fjtIZn6NK/oGMuslmEQqw4PvDonuRrxLqaD4fqPUfsh1GmXWxSOGvyZGpQgI/J7Uu1MbB5xWjI5TSSoEiMy4BJ78rwyIaciFU4iKcMihC6gYnqserRGN00RsfwlMaG4FcDCcDhcTF73jqG53RU1wvX79xb3wZZW6f+QboXup2f/GgQ2ujVLUkJRgHNlq2TzOC5ayfppjQmyomTS4gSQ5WQZVAnWeyFYdF0buHwamZNdOrhGuLUyWQDnbURf49DvvPD7cn8UwmD/RZgEp0n+F9CtSgpNuucXjUyDcVRSbBX/3Ytn+F2aSkNUROTiEr+l36vCtgRjcYqJCPTDYGTLsPDtGOddMhqe9KKlF6OW8Tp8c7ZvD2KvpWmMAJS0e07mkilbneqPVbc1IFecVTEqFZKfyCqPk+1l0UPZe9PZl4N3z/DX x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: cee4aebd-5953-44f6-b62a-08d7609469ec X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2019 19:31:24.3302 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RiSuMUq1a6u5A03w5EIKuW32FfmE8Qq2qtU9bQG+TmS2RUCrXovCk8jwSNjOnyMrkEQNadLicxrQxmXF5OH2T0P4gw6cr8CFjnZD17n4Vog= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR05MB3473 Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance 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" Hi, Haiyue > -----Original Message----- > From: Wang, Haiyue > Sent: Sunday, November 3, 2019 13:38 > To: Slava Ovsiienko ; Liu, Yu Y > ; Thomas Monjalon > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh > ; jerinjacobk@gmail.com; Ye, Xiaolong > ; Kinsella, Ray ; Sun, > Chenmin ; Damjan Marion (damarion) > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mod= e > information >=20 > Hi Slava, >=20 > > -----Original Message----- > > From: Slava Ovsiienko > > Sent: Sunday, November 3, 2019 16:59 > > To: Wang, Haiyue ; Liu, Yu Y > ; Thomas Monjalon > > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh > ; > > jerinjacobk@gmail.com; Ye, Xiaolong ; Kinsella, > Ray ; > > Sun, Chenmin ; Damjan Marion (damarion) > > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst > mode information > > > > > -----Original Message----- > > > From: Wang, Haiyue > > > Sent: Sunday, November 3, 2019 4:34 > > > To: Slava Ovsiienko ; Liu, Yu Y > > > ; Thomas Monjalon > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh > > > ; jerinjacobk@gmail.com; Ye, Xiaolong > > > ; Kinsella, Ray ; Sun, > > > Chenmin ; Damjan Marion (damarion) > > > > > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst > mode > > > information > > > > > > Hi Thomas, Slava, > > > > > > Please see the inline reply in one place. > > > > > > > -----Original Message----- > > > > From: Slava Ovsiienko > > > > Sent: Saturday, November 2, 2019 16:39 > > > > To: Liu, Yu Y ; Wang, Haiyue > > > > ; Thomas Monjalon > > > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh > > > > ; jerinjacobk@gmail.com; Ye, Xiaolong > > > > ; Kinsella, Ray ; Su= n, > > > > Chenmin ; Damjan Marion (damarion) > > > > > > > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting bur= st > > > > mode information > > > > > > > > Hi > > > > > -----Original Message----- > > > > > From: Liu, Yu Y > > > > > Sent: Saturday, November 2, 2019 8:56 > > > > > To: Wang, Haiyue ; Thomas Monjalon > > > > > > > > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh > > > > > ; jerinjacobk@gmail.com; Ye, Xiaolong > > > > > ; Kinsella, Ray ; > > > > > Sun, Chenmin ; Slava Ovsiienko > > > > > ; Damjan Marion (damarion) > > > > > ; Liu, Yu Y > > > > > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting > > > > > burst mode information > > > > > > > > > > Add Damjan from FD.io for awareness... > > > > > > > > > > Hi Thomas, > > > > > > > > > > Long time no see. Sorry I use outlook which is not friendly to > > > > > community email. > > > > > > > > > > >Anyway I will propose to replace this API in the next release. > > > > > Will your plan be affected by API/ABI stable plan? > > > > > BTW, if you propose new change in next release, it will make DPDK > > > > > consumer(FD.io) to change again. > > > > > So even if it is not affected to the API/ABI stable plan, do we > > > > > still have time to get a solution for everyone in DPDK 19.11 with > > > > > your contribution/acceleration? > > > > > > > > > > > I suspect a real hidden issue in Intel CPUs that you try to mit= igate. > > > > > Please be rest assured it is not the case. > > > > > This request is just from one FD.io project internal bug " tx/rx > > > > > burst function is shown as nil" reported by Chenmin. > > > > > > > > Why just the presenting string with function name (possible with su= ffix) > is > > > not enough? > > > > I would like to see this API (strings approach) in mlx5 either, > > > > dropping the entire feature does not look nice, as for me. > > > > > > > > We could consider some requirements for the name suffices to > > > > distinguish whether function uses vector instructions and which one= s if > any. > > > > > > > > > My understanding is DPDK behavior was taken as bug for someone in > > > > > FD.io project and potentially will mislead other DPDK consumer. > > > > > > > > Why does FD.io code want to know which vector extension is used by > burst > > > routines? > > > > Is it going to share/preserve some resources (registers, etc.)? Is = it > robust ? > > > > Burst routines might not know whether vector extensions is used (th= ey > > > > might call libraries, even rte_memcpy() can use vectors in implicit > fashion). > > > > > > > > > > 1. > > > > > > The original issue description is: > > > "VPP uses dladdr() to translate a function address to name, however, > some > > > tx/rx functions in DPDK are invisible for dladdr(), which is because= they > are > > > defined as static." > > > > > > 2. > > > > > > So the RFC design is: one function, one description, like: > > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fpatch > > > > work.dpdk.org%2Fpatch%2F57644%2F&data=3D02%7C01%7Cviacheslavo > > > > %40mellanox.com%7Ca99632b4e2444ec00b1f08d760065041%7Ca652971c7 > > > > d2e4d9ba6a4d149256f461b%7C0%7C0%7C637083452540980873&sdat > > > > a=3D4re5GOXPSwGk5BTOYLglafzgjBzRLk1gXyWKT47o8o0%3D&reserved=3D > > > 0 > > > > > > +#ifdef RTE_ARCH_X86 > > > + else if (dev->rx_pkt_burst =3D=3D ice_recv_scattered_pkts_vec_avx2) > > > + len =3D snprintf(buf, sz, "AVX2 Vector Scattered Rx"); > > > + else if (dev->rx_pkt_burst =3D=3D ice_recv_scattered_pkts_vec) > > > + len =3D snprintf(buf, sz, "Vector Scattered Rx"); > > > + else if (dev->rx_pkt_burst =3D=3D ice_recv_pkts_vec_avx2) > > > + len =3D snprintf(buf, sz, "AVX2 Vector Rx"); > > > + else if (dev->rx_pkt_burst =3D=3D ice_recv_pkts_vec) > > > + len =3D snprintf(buf, sz, "Vector Rx"); #endif > > The application gets the routine names with dladdr(). OK, it happens. > > It is not clear for me why instead of direct replacement/extension of d= laddr > > functionality some new names were introduced and then converted to > flags. > > >=20 > Sorry, can you explain more ? Who 'direct replacement/extension of dladdr= ' > ? > VPP, or DPDK ? >=20 > > > 3. Since the main issue is as Damjan replied in another thread: > > > "people are reporting lower performance caused by DPDK deciding fo= r > > > variety > > > of reasons to switch from vector PMD to scalar one." > > > > > > And Ferruh replied also: > > > "As I understand this is to let applications to give informed dec= ision > based > > > on what vectorization is used in the driver, currently this is n= ot known > by > > > the application. > > > > > > And as previously replied, the main target of the API is to defi= ne the > vector > > > path, not all optimizations, so the number is limited." > > > > > > So we enhanced it with bit, example detail is (Yes, we defined a= lit > more, > > > so we removed it in this patch): > > > > There are might be a lot of various burst functions, vectorized or not= , > > with various sets of supported offloads. Yes, identifying the engaged b= urst > > routine is meaningful, but it is not clear for me, why the vectorizing = type > > should have dedicated means (flags) to identify ? > > >=20 > The new 'rte_eth_rx/tx_burst_mode_get' works like logging, but in fact, t= he > log > message is something special, like "Vector Neon/AltiVec/SSE/AVX2" and the > device > specific offloads as you said. >=20 > This kind of string "Vector Neon/AltiVec/SSE/AVX2" can be common, we not > treat it > as 'flag', it is a normal bit like macro definition, and it will be trans= lated into > string later. And we want to make PMD's string format life to be easy, do= n't > need > to call 'snprintf/sprintf' with the copied string format. >=20 > So now, the log message format is: device specific (if have) + "Vector ..= ." (if > have, this is not MUST, if the PMD doesn't use vector, but at least, this= is not > hardware specific, it is some common from arch: > lib/librte_eal/common/arch/arm,ppc_64,x86). >=20 > Further, as a SDK, the API exposes these common bit data for application > easily access > if it may need, DON'T NEED TO BREAK THE ABI/API. Compared to > 'strstr/strcasestr', > 'mode->options & RTE_ETH_BURST_VECTOR' is more friendly ? Yes, it is more friendly for app. But there is quite another question: do w= e really need these flags for logging purposes ? There are no explicitly expressed requirements from applications for these flags. > > > > > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fpatch > > > > work.dpdk.org%2Fpatch%2F61196%2F&data=3D02%7C01%7Cviacheslavo > > > > %40mellanox.com%7Ca99632b4e2444ec00b1f08d760065041%7Ca652971c7 > > > > d2e4d9ba6a4d149256f461b%7C0%7C0%7C637083452540980873&sdat > > > > a=3Dnm80Pt0fFWqmmrJcKY6ks4qRTJ7cjGJWEG1Wv6gxfSw%3D&reserved > > > =3D0 > > > > > > 4. And thanks Jerin's suggestion, I think his word can be more accura= te: > "This > > > would > > > help to reuse some of the flags to name conversion logic across al= l > PMDs" > > > for the > > > reason we try to use bit to reduce some string format effort, it w= ill be > > > handled > > > by the API internally "burst_mode_options_append(struct > > > rte_eth_burst_mode *mode)". > > > Now the new API will return the string finally: > > > > > > #define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 1024 struct > > > rte_eth_burst_mode { > > > uint64_t options; > > > > > > /**< Each PMD can fill specific burst mode information into this, an= d > > > * ethdev APIs will append the 'options' string format at its end. > > > */ > > > char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE]; > > > }; > > > > > > So MLX PMD can add 'full_empw', 'mtsc_empw' etc into > 'alternate_options' > > > firstly, assign 'RTE_ETH_BURST_VECTOR | RTE_ETH_BURST_SSE' to > 'options' > > > as needed, then finally, 'alternate_options' will be "full_empw, Vect= or > SSE". > > > > For mlx5 tx_burst these flags have no meaning. All information regardin= g > routine > > is encoded within the name, mtsc stands for: > > m - multisegment > > t - TSO > > s - software tunnel parser > > c - check sum > > > > There are no two versions of mtsc_empw - "mtsc_empw, Vector SSE", > "mtsc_empw, Vector Neon". > > If we developed vectorized version, I would prefer "mtsc_empw_sse". > > > > To summarize: > > - application uses routine names, gets with dladdr(). Nice. > > - compatible API providing names of internal routines is proposed. Nice= . > > - users now are able to identify the engaged burst routine. Nice. > > - proposed API is extended, some vector related flags were added. > Hmmm.... Questionable. > > Why vector related only? Why do we change the string format? (name -> > name, options) >=20 > Again, vector is not "only", it is just 'main' characteristic "tree ./dri= vers/net/ | > grep rxtx_". > we can design the Rx/Tx burst function mainly by vector type, it is > straightforward. OK, we have some flag field proposed. Saying "why vector only" I meant that vectorizing is just one of optimizing technics. I do not see it as "main tree characteristics", sorry. What if some other vendor would like to add its own flags? For example, mlx5 could add at least 8 optimizing flags for tx_burst and 4 flags for rx_= burst (besides vector related ones). Why not? Why do we decide to add vector flag= s only? Other vendors might come into play and add its own flags describing the bur= st routine features and optimizations. And then say - "hey, these parameters define ou= r internal rxtx tree. It is very critical for performance, user must know abo= ut ones". >=20 > Why 'name -> name' ? Sorry for the MS Outlook (and I'm on the way to Mutt now), it is not community friendly. Correct sentence: "name" to "name, options" > 1.) [v4,4/4] app/testpmd: show the Rx/Tx burst mode description > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F% > 2Fpatchwork.dpdk.org%2Fpatch%2F61198%2F&data=3D02%7C01%7Cviac > heslavo%40mellanox.com%7C0ba4e73594684f944b7608d760525c97%7Ca6 > 52971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637083779173049231&a > mp;sdata=3D2NCHJJpsAYsb07FTEmvr4EiIVudm7ZCVhemh2g1MBG0%3D&r > eserved=3D0 > This is handled by the application itself, not so friendly, many lines of= code to > show. Yes, it does not look nice, as for me. String should be simple and just pro= vided by PMD, without any extra flags/options, IMHO. >=20 >=20 > 2). [PATCH v1 3/3] ethdev: enhance the API for getting burst mode > information > if (rte_eth_tx_burst_mode_get(port_id, queue_id, &mode) =3D=3D 0) > printf("\nBurst mode: %s", mode.alternate_options); >=20 > This design may meet your question above if I understand correctly. > "It is not clear for me why instead of direct replacement/extension > of dladdr > functionality some new names were introduced and then converted to > flags". >=20 >=20 > Last, again, we define the bits 'RTE_ETH_BURST_XXX' for making the log > message > generation process easily if you agree vector type is common, the vector = can > be Simple string returned by PMD eliminates "message process generation" at al= l. No flags/options - no generation needed at all. In my opinion, PMD just sho= uld return strings like "rx_burst_vector_sse", "rx_burst_vector_neon", etc.=20 > used to improve the performance. And if new burst design can be used for > most > PMDs, use it as bit, the API helps to translate it to string. And the app= lication > can use the bit to do other kind of information display. >=20 > We define it a little more than 'simple string' for just making life easy= . In fact, > the patch comes from "simple string", RFC v1, v2, v3, PATCH v1 v2 v3 v4. Applications live OK with dladdr(). The returned name is used for logging. There is NO explicit requirements from application to provide some extra op= tions, besides the name (or, at least, these ones are not visible for me). Sorry, it is not clear for me, how by introducing extra flags and the extra "easy message generation process" we make life easier. If PMD just provides the simple string "rx_burst_vector_sse", everyone seeing this string in the= log understands what and how the named rx_burst is doing, right? Do you think= =20 the message like "rx_burst, Vector SSE" looks better? OK, your PMD is free to return it. Honestly, I do not mind against flags strictly, but I do not see any new me= anings introduced by flags. It requires extra code, it might introduce some ambigu= ity, it would be ridiculous to see something like that: "rx_burst_vector_neon, Vector_AVX"=20 And, the last, the flag field is a potential scarce resource for vendors. =20 With best regards, Slava > > > > > > > Intel PMD can just assign "options", then finally, 'alternate_options= ' will > be > > > "Vector SSE". > > > > As I see from initial patch, Intel PMD has dedicated routines with uniq= ue > names for > > each type of vectorization. Is there some burst routine with single na= me > which could > > operate with different vectorization types, depending on configuration? > > > > With best regards, Slava > > > > > > > > How about the design idea ? Again, this 'options' is not to do > standardization, > > > just want to reduce the duplicated name string things. > > > > > > > With best regards, Slava > > > > > > > > > Haiyue is working with Chenmin to address the issue and with your > > > > > support it will be even better. > > > > > > > > > > Your support will be highly appreciated! > > > > > > > > > > Thanks & Regards, > > > > > Yu Liu > > > > > > > > > > -----Original Message----- > > > > > From: dev On Behalf Of Wang, Haiyue > > > > > Sent: Saturday, November 2, 2019 1:30 PM > > > > > To: Thomas Monjalon > > > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh > > > > > ; jerinjacobk@gmail.com; Ye, Xiaolong > > > > > ; Kinsella, Ray ; > > > > > Sun, Chenmin ; Slava Ovsiienko > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API fo= r > > > > > getting burst mode information > > > > > > > > > > > -----Original Message----- > > > > > > From: Thomas Monjalon > > > > > > Sent: Saturday, November 2, 2019 06:46 > > > > > > To: Wang, Haiyue > > > > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh > > > > > > ; jerinjacobk@gmail.com; Ye, Xiaolong > > > > > > ; Kinsella, Ray = ; > > > > > > Sun, Chenmin ; Slava Ovsiienko > > > > > > > > > > > > Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting > > > > > > burst mode information > > > > > > > > > > > > Thank you for trying to address comments done late. > > > > > > > > > > > > 31/10/2019 18:11, Haiyue Wang: > > > > > > > --- a/lib/librte_ethdev/rte_ethdev.h > > > > > > > +++ b/lib/librte_ethdev/rte_ethdev.h > > > > > > > > > > > > > > > > > +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2) > > > > > > > +#define RTE_ETH_BURST_NEON (1ULL << 3) > > > > > > > +#define RTE_ETH_BURST_SSE (1ULL << 4) > > > > > > > +#define RTE_ETH_BURST_AVX2 (1ULL << 5) > > > > > > > +#define RTE_ETH_BURST_AVX512 (1ULL << 6) > > > > > > > > > > > > Of course, I still believe that giving a special treatment to > > > > > > vector instructions is wrong. > > > > > > You did not justify why it needs to be defined in bits instead = of > > > > > > string. I am not asking again because anyway you don't really > > > > > > reply. I think you are executing an order you received and I do= n't > > > > > > want to blame you more. > > > > > > I suspect a real hidden issue in Intel CPUs that you try to mit= igate. > > > > > > No need to reply to this comment. > > > > > > Anyway I will propose to replace this API in the next release. > > > > > > > > > > Never mind, if this design is truly ugly, drop it all now. I also > > > > > prefer to do the best, that's why open source is amazing, thanks! > > > > > ;-)