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 DB707A04A2; Wed, 6 Nov 2019 09:19:43 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 073281C01F; Wed, 6 Nov 2019 09:19:43 +0100 (CET) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id 1FC101C01E for ; Wed, 6 Nov 2019 09:19:41 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 498557161; Wed, 6 Nov 2019 03:19:40 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 06 Nov 2019 03:19:40 -0500 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=Qu28uoD/BBakNqaHKYDWkcRFk4kxx9nw28JS+j1iIy4=; b=ckB5mWU0b0fz XmhUgvARIswY64WoY1E6XQuex/UucuZYAXLKtWu4D9Uzf46riSI03bgB7yeK97t5 nCYT0D0xGc6KAN1ENW3SkTBgYUl+2ejT81gS/Zz+8c/OkawRvo930EwAKO++gsbB xFBacxqrMrlLoap2Dgt/oQZsyQxhMKQ= 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=Qu28uoD/BBakNqaHKYDWkcRFk4kxx9nw28JS+j1iI y4=; b=aHVOzRcrE+Z3KSjhVWYuJUPc7+3M3niH/sy862gAXRkddPw5SRg763hSQ Fmhkkeb9aexjR0AZFK07uUQigvqcBh9Fbkk6/5cQedVF3Ch067LWjrXIPwQWbWjK uIeJTI4rEyXCeTQw5TUK080Hya5bw8w4lKuU7IaiFbciRbOWDb+5UX70RxFuJXEt LG9iKqoVEVtLaH667k9WffaSb0EQDSauMWrb9yzRvGvfo53COXEX18y5D/78rNmM 4sEfGYYbw9L+FLhd3CbzX0uxwxdIwzxh2u+CWuyNiNhk00i15E7xwyDUerAclvn/ M4tAw+QMp8hVWrdMTxGyu3nsn12Wg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduiedguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ffohhmrghinhepughpughkrdhorhhgnecukfhppeelfedrvdefrddutdehrddvfedunecu rfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (231.105.23.93.rev.sfr.net [93.23.105.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 850FA80062; Wed, 6 Nov 2019 03:19:35 -0500 (EST) From: Thomas Monjalon To: "Wang, Haiyue" Cc: "dev@dpdk.org" , "jerinjacobk@gmail.com" , "Yigit, Ferruh" , "arybchenko@solarflare.com" , "viacheslavo@mellanox.com" , "damarion@cisco.com" , "Ye, Xiaolong" , "Sun, Chenmin" , "Kinsella, Ray" , "Liu, Yu Y" Date: Wed, 06 Nov 2019 09:19:32 +0100 Message-ID: <3663289.PNCOYS1eAT@xps> In-Reply-To: References: <20191104103920.64907-1-haiyue.wang@intel.com> <2399300.Xf6G4o05WB@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] 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" 06/11/2019 02:21, Wang, Haiyue: > From: Thomas Monjalon > > 04/11/2019 11:39, Haiyue Wang: > > > /** > > > * 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; > > > + uint64_t flags; /**< The ORed values of RTE_ETH_BURST_FLAG_xxx */ > > > + > > > +#define RTE_ETH_BURST_MODE_INFO_SIZE 1024 /**< Maximum size for information */ > > > + char info[RTE_ETH_BURST_MODE_INFO_SIZE]; /**< burst mode information */ > > > }; > > > > I think the API can be simpler by passing the flags as function parameter. > > > > In my understanding the burst mode name is fixed per Rx/Tx function, > > so it can be a constant string referenced with a simple char*. > > > > This is the current API: > > > > int rte_eth_rx_burst_mode_get(uint16_t port_id, uint16_t queue_id, > > struct rte_eth_burst_mode *mode); > > > > I wonder what do you think of such API? (just a proposal for comments): > > > > char *rte_eth_rx_burst_mode_get(uint16_t port_id, uint16_t queue_id, uint64_t flags); > > > > Or is there some cases where you want to build the string with snprintf? > > (I cannot think about a case, given it should mapped to a C-function) > > > > 1. 'a constant string' is hard for PMD expanding if it wants to make the string > dynamic according to the setting, like: http://patchwork.dpdk.org/patch/62352/ > (although based on bit options design). Yes, constant string is less flexible in the PMD implementation. > 2. And for dynamic string, if it is *return type*, then the PMD needs to > handle the memory allocation, and the application frees it. And 'uint64_t flags' > is output parameter, so it should be like 'uint64_t *flags', but this needs the > application to declare it or not, and needs PMDs to check whether it is passed > or not, then set it. > > So for making things easy, the 'struct rte_eth_burst_mode' may be nice, then the > application just declares one line : 'struct rte_eth_burst_mode mode', then all > things are filled by PMD in one place. I agree it is a lot simpler to use a struct.