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 7EF9CA32A8 for ; Sat, 26 Oct 2019 00:27:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6E45F1C122; Sat, 26 Oct 2019 00:27:25 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id 00D961C120 for ; Sat, 26 Oct 2019 00:27:23 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 2FF0F665B; Fri, 25 Oct 2019 18:27:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 25 Oct 2019 18:27:23 -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=8G931FwbyT+SBl6lVO4WH1Z/3dmyr6U2Us1g9tEpkYE=; b=d1TEI8lIQzwT 2kSSeZWlJjuzyMmiDfAA6wNQ4nyPcQa2GVHfGs29Ymk83AMz/xJUXe+4HMxbfL+V 3OVmgN7kaO7/yrdU0hwGbJTz0LfoVyN9yg8ex7eZ4kUrbJ0+PqOSxgP09ywqo0nJ q77FXkknZNYLeAYnDYzMJKhAidfoCwU= 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=8G931FwbyT+SBl6lVO4WH1Z/3dmyr6U2Us1g9tEpk YE=; b=gUdos2ichaEifH+4BksoqM4CnWo4DbpPeXpF3vrLhXQ3SBJpO2wAt1HDh StJMcwB3kiAee70uleHI0B1hjo2QxDkEDkS1RM6BNAB8M5fPxgnNYTDAaEMGTgMu j6de3xmMBNZIvwrEMUlLGVONhDnfcir26+mZ8mwg93XOlsusX1cLeyq3xsdFCuN7 ZDNpOjINOWzaSmMrEo+8bWM6sly4p6twfrR8oJ9vhLgKDZLkUZzZrgq3MmyZnfZ1 gsr4bew95Gs51xCwl/MZKc27YsVknb+bl9VMGjMSMlgUTnHieAo0KukWrbem9WT+ OotY4jTI024q462x/bxUb9zFccKdg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrleeggdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd 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 279E6D60057; Fri, 25 Oct 2019 18:27:21 -0400 (EDT) From: Thomas Monjalon 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 Date: Sat, 26 Oct 2019 00:27:20 +0200 Message-ID: <12001140.UMXFOKstgs@xps> In-Reply-To: References: <20191015075133.38560-1-haiyue.wang@intel.com> <1811898.7XjjD7ZjLQ@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" 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?