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 8CE65A04B6; Mon, 12 Oct 2020 12:09:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 24FFC1D66D; Mon, 12 Oct 2020 12:09:52 +0200 (CEST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by dpdk.org (Postfix) with ESMTP id A18C41D66C for ; Mon, 12 Oct 2020 12:09:50 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id B898BCB4; Mon, 12 Oct 2020 06:09:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 12 Oct 2020 06:09:48 -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=fm2; bh= 3LDL97o4KuoU/E/IJJhDInoKVa9p1noLqixvPuXdCMY=; b=Rj+/I4jq+/D+gnQT jfYZklObSHyJ7O6cvx5VxIQLj19qac+ik+bUDhsPMEUrscInFsIbLGorlybBiXrt rY3Eb4+ztnNfUVdXlpmYEoPOPMxg0bKyvv/hf9L/fu+/n5a1El5aF/N9mO1Y1ngQ KHkwjSf0iN9ptslPHyO3v6zl9I5Lq/k233k4isVThjSUDs0a6xaCL7lBTiwzgf78 jeTopdjs+e5Aw4hgtMH9ibcJ77ip4abQtKDLgjI4I7xoh1HpfS5l5SDImriMuVWY o1mOZXJw0+Yt0gUNFBGBk7dX3Zk3cLfTXxLsurFIhlutsTztTZQD1rmuK8479kmS EOu7dw== 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=3LDL97o4KuoU/E/IJJhDInoKVa9p1noLqixvPuXdC MY=; b=oCTiSkz8gXiMEi9d4leC5Ncn4uK/rEgCKydDGphglNw8eL+Gtjb9gW3JG PjLB+Dm6Q4OD2NtPBOdZGdDBpvIfX4EKGWGi4cfz5qrifCD1OnUaDx9/q31ykpfS IjFPnwPzOaS5A/Um6vRDqBVjoYZeGCPLcLjJLQNYdsq8rSTTDPwDKktIpNN8z/vN 5Lyk6qsk1mCZ3IzCcymFjuaZEf6UQR0bbZHv/5/IX3/egWqqoMv9Ru4a+U4pB6QK afLxp+BQmQvxEHDHY7WDXE1gWgi0Xo3OnTw9yIe1VxIUqUEC3Jrtftzv0rFWNNEz yoxzjJrc1mBgxp6VO5uOatDP+UYZg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrheejgddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhgggfgtsehtufertd dttddvnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehm ohhnjhgrlhhonhdrnhgvtheqnecuggftrfgrthhtvghrnhepudeggfdvfeduffdtfeegle fghfeukefgfffhueejtdetuedtjeeuieeivdffgeehnecukfhppeejjedrudefgedrvddt fedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght 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 6F9E23064682; Mon, 12 Oct 2020 06:09:45 -0400 (EDT) From: Thomas Monjalon To: Slava Ovsiienko Cc: "dev@dpdk.org" , "stephen@networkplumber.org" , "ferruh.yigit@intel.com" , "olivier.matz@6wind.com" , "jerinjacobk@gmail.com" , "maxime.coquelin@redhat.com" , "david.marchand@redhat.com" , "arybchenko@solarflare.com" Date: Mon, 12 Oct 2020 12:09:43 +0200 Message-ID: <1950696.BxnD3bV1GU@thomas> In-Reply-To: References: <5451712.xXqzTqBGid@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 1/9] ethdev: introduce Rx buffer split 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" 12/10/2020 11:40, Slava Ovsiienko: > From: Thomas Monjalon > > > int > > > rte_eth_rx_queue_setup_ex(uint16_t port_id, uint16_t rx_queue_id, > > > uint16_t nb_rx_desc, unsigned int socket_id, > > > const struct rte_eth_rxconf *rx_conf, > > > const struct rte_eth_rxseg *rx_seg, > > > uint16_t n_seg) > > > > An alternative name for this function: > > rte_eth_rxseg_queue_setup > M-m-m... Routine name follows patter object_verb: > rx_queue is an object, setup is an action. > rxseg_queue is not an object. > What about "rte_eth_rx_queue_setup_seg"? rte_eth_rxseg is the name of the struct, so it looks natural to me to keep it as prefix (object name). [...] > > > The new offload flag DEV_RX_OFFLOAD_BUFFER_SPLIT in device > > > > The name should start with RTE_ prefix. > > It is an existing pattern for DEV_RX_OFFLOAD_xxxx, no RTE_ for the case. It is a wrong pattern which must be fixed. Please start fresh with the right prefix for new ones. Thinking twice, it should be: RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT [...] > > > Also, the proposed segment description might be used to specify Rx > > > packet split for some other features. For example, provide the way to > > > specify the extra memory pool for the Header Split feature of some > > > Intel PMD. > > > > I don't understand what you are referring in this last paragraph. > > I think explanation above is enough to demonstrate the flexibility. > > > Just noted the segment description is common thing and could be > promoted to be used in some other features. I think it is not needed. And giving Intel as an example is arbitrary.