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 E714CA32A8 for ; Sat, 26 Oct 2019 18:23:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 10B171BF55; Sat, 26 Oct 2019 18:23:11 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 6AC3D1BEA4 for ; Sat, 26 Oct 2019 18:23:09 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id BC5475D68; Sat, 26 Oct 2019 12:23:06 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sat, 26 Oct 2019 12:23:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=R1wDAPIWUHnKDBTjgS+NfaEaCJoxTBOF40hC1Gx6Sl0=; b=Sxwlztjzehr+ Kd/nN3csljmkKPhIg3ekLA6BXGS2mFc2bE6Rx20W0EztXvAe33fGJCQZQR6KHW2w KK8bpEyrJOOdbXATrtzQ0ZFUgbuCOUSwdfLObBxrqXc0P1GEDZd5X9zM9s3IBgHo 9F4mvyJrkybHpBFkdaTLtGSF2jk4yeE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=R1wDAPIWUHnKDBTjgS+NfaEaCJoxTBOF40hC1Gx6S l0=; b=uXeXOAgBkL2nA65YQoppomxKzowaM4hlwcwzt0fCujg+42mM0z+VPxa0m G75RwKU1lS/RO7I4WqV3xgF9iVE8EwRlFASt9fXfQRzHhvZ+MvumAPLxKj/P256I Lhuwnz9oVhaRrCh6TyvfDGrhHhJLWT1yt/M+t8/rkVVKADT3P5yyR+te4O5l1FB7 +mRtA3OdrNOMUIBL4Qkxxt4KziKEKxNoJU/HiDNNxduuZCw1xoJF6J4QSOT/YYSa toYgWsU+PrtAsBHsTt9Qw8coPOC+pl3PGCS0T3Fm7NbOG/3ajUVaswn6nP7oXueQ 7sA72PeMhDCrSgYscgs2HhgCSmFCA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrleehgddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D4F40D6005A; Sat, 26 Oct 2019 12:23:03 -0400 (EDT) From: Thomas Monjalon To: "Wang, Haiyue" Cc: Jerin Jacob , "Yigit, Ferruh" , dpdk-dev , "Ye, Xiaolong" , "Kinsella, Ray" , "Iremonger, Bernard" , "Sun, Chenmin" , Andrew Rybchenko , Slava Ovsiienko , Stephen Hemminger , David Marchand , Jerin Jacob , edwin.verplanke@intel.com Date: Sat, 26 Oct 2019 18:23:02 +0200 Message-ID: <14832014.5GoLVrWRzY@xps> In-Reply-To: References: <20191015075133.38560-1-haiyue.wang@intel.com> <4392076.GEpbuJ9hXI@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 26/10/2019 11:23, Wang, Haiyue: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 26/10/2019 06:40, Wang, Haiyue: > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > 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 information 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 before 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 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 notification > > > > > > 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 structure. > > > > > > > >> + * 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 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 implemented in Intel PMDs. > > > > And this is a complicate solution. > > > > Why not just returning a name for the selected Rx/Tx mode? > > > > > > Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC, > > > 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit > > > that consists of libraries to accelerate packet processing workloads running on a wide > > > variety of CPU architectures." > > > > How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic? > > They just match some features of the Intel PMDs. > > Why not exposing other optimizations of the Rx/Tx implementations? > > You totally missed the point of generic burst mode description. > > > > > If understand these new experimental APIs from above, then bit options is the 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 running by > > > just simple bit test. > > > > > > If PMDs missed these, they can update them in future roadmaps to enhance their PMDs, > > > like MLX5 supports ARM NEON, x86 SSE. > > > > I have no word! > > You really think other PMDs should learn from Intel how to "enhance" their PMD? > > You talk about mlx5, did you look at its code? Did you see the burst modes > > depending on which specific hardware path is used (MPRQ, EMPW, inline)? > > Or depending on which offloads are handled? > > > > Again, the instruction set used by the function is a small part > > of the burst mode optimization. > > > > So you did not reply to my question: > > Why not just returning a name for the selected Rx/Tx mode? > > In fact, RFC v1/v2 returns the *name*, but the *name* is hard for > application to do further processing, strcmp, strstr ? Not so nice > for C code, and it is not so standard, So switch it to bit definition. Again, please answer my question: why do you need it? I think it is just informative, that's why a string should be enough. I am clearly against the bitmap because it is way too much restrictive. I disagree that knowing it is using AVX2 or AVX512 is so interesting. What you would like to know is whether it is processing packets 4 by 4, for instance, or to know which offload is supported, or what hardware trick is used in the datapath design. There are so many options in a datapath design that it cannot be represented with a bitmap. And it makes no sense to have some design criterias more important than others. I Cc an Intel architect (Edwin) who could explain you how much a datapath design is more complicate than just using AVX instructions. > If the API is not bad, but the data is not so good, then accept below ? ;-) No, the API is bad.