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 DF072A04A2; Wed, 6 Nov 2019 01:33:11 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8A6141BFB7; Wed, 6 Nov 2019 01:33:11 +0100 (CET) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id 5B6CC1BFB5 for ; Wed, 6 Nov 2019 01:33:09 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 002275960; Tue, 5 Nov 2019 19:33:08 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 05 Nov 2019 19:33:09 -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=/JXjT4v9MbAV5ovKoBJKX58b2H8yUn+LizJrY4+Ct5o=; b=fRygPPdmnwmo 1OPlq5DlnXEgDzaDnneCP6ZjjRdDrKZBawHklrugboqsbimtqt8/b/M6cx4N4d8e SpJ3HJw7XE7Msl/RTok/3mZaQSLh7x1gpTl74X+o/b5RGnI4KXBUNkbm4C1x4erb BUqz4mnxks9fZlzTCKntVcmwZSe6q70= 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=/JXjT4v9MbAV5ovKoBJKX58b2H8yUn+LizJrY4+Ct 5o=; b=LGEcJ2KapztorbbdI2ykm6TMK4f3GzYI5W4R31T5w15ckJcA3RFYjMVGD 0opx+T3wL7/D++vexFw0nIXHlyxHupp+StcvXcUr378XLltwYq9djaADtbjf+WQV bl1BZVm9vsNk02lXolW27ZNUve81ivTTAwcMWgQY9do7eE3tADz4eEMv/7YgdxQ2 YzU+vIbuRV1SFHkRQo0YuXgfaChHhYwJv4oWH0behMv7LAYkvg8JPwiUd27pUKUK RuzzK+QQWWa1yINbr7u3qO0TNAItYJ8A1LlAYFPxxj9x4STc92YiW5pXC3QehYY+ WyUhI/UTP/Uk0rvuWMGma3E6peAug== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduiedgvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeelfedrvdefrdduleekrdehudenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhm rghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (51.198.23.93.rev.sfr.net [93.23.198.51]) by mail.messagingengine.com (Postfix) with ESMTPA id 3B9C3306005F; Tue, 5 Nov 2019 19:33:05 -0500 (EST) From: Thomas Monjalon To: Haiyue Wang Cc: dev@dpdk.org, jerinjacobk@gmail.com, ferruh.yigit@intel.com, arybchenko@solarflare.com, viacheslavo@mellanox.com, damarion@cisco.com, xiaolong.ye@intel.com, chenmin.sun@intel.com, ray.kinsella@intel.com, yu.y.liu@intel.com Date: Wed, 06 Nov 2019 01:33:42 +0100 Message-ID: <2399300.Xf6G4o05WB@xps> In-Reply-To: <20191104103920.64907-1-haiyue.wang@intel.com> References: <20191104103920.64907-1-haiyue.wang@intel.com> 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" 04/11/2019 11:39, Haiyue Wang: > Change the type of burst mode information from bit field to free string > data, so that each PMD can describe the Rx/Tx busrt functions flexibly. > > Signed-off-by: Haiyue Wang > --- > > v2: - Drop the bit field for burst mode information handling. Please use --in-reply-to, so the versions of a patch can be in the same thread. > --- a/lib/librte_ethdev/rte_ethdev.h > +++ b/lib/librte_ethdev/rte_ethdev.h > /** > - * Burst mode types, values can be ORed to define the burst mode of a driver. > + * Generic Burst mode flag definition, values can be ORed. > + */ > +#define RTE_ETH_BURST_FLAG_PER_QUEUE (1ULL << 0) > +/**< If the queues have different burst mode description, this bit will be set > + * by PMD, then the application can iterate to retrieve burst description for > + * all other queues. > */ I am not sure you can have a doxygen comment before and after the same item. > -enum rte_eth_burst_mode_option { > - RTE_ETH_BURST_SCALAR = (1 << 0), > - RTE_ETH_BURST_VECTOR = (1 << 1), > - > - /**< bits[15:2] are reserved for each vector type */ > - RTE_ETH_BURST_ALTIVEC = (1 << 2), > - RTE_ETH_BURST_NEON = (1 << 3), > - RTE_ETH_BURST_SSE = (1 << 4), > - RTE_ETH_BURST_AVX2 = (1 << 5), > - RTE_ETH_BURST_AVX512 = (1 << 6), > - > - RTE_ETH_BURST_SCATTERED = (1 << 16), /**< Support scattered packets */ > - RTE_ETH_BURST_BULK_ALLOC = (1 << 17), /**< Support mbuf bulk alloc */ > - RTE_ETH_BURST_SIMPLE = (1 << 18), > - > - RTE_ETH_BURST_PER_QUEUE = (1 << 19), /**< Support per queue burst */ > -}; Thank you > /** > * 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)