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 05B14A04DB; Fri, 16 Oct 2020 11:37:20 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 915391D5C9; Fri, 16 Oct 2020 11:37:18 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 050371D50E for ; Fri, 16 Oct 2020 11:37:16 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 776BA5C012A; Fri, 16 Oct 2020 05:37:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 16 Oct 2020 05:37:15 -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= B85i2gWETVrpF8Agu2U/hVlDcaAi9jpnNqsGB3fPbUc=; b=YsMOGds1F0zXCgRs T9xI3OqtkMcwZsbDhEbtdccgD3d2SCDuT82fdBr0IHlTOsiKASlbKLz5CPBXVYVA T/AsW/ha9hwgRVIPRSblN58K8v6FQUHkmN+RonB1GzOu1hKbz08bmPqRitSr4eFU pm77sNuNJs06dfPwcSfVCEzbFLvvgpWyCMBE8PJaZ8tNdoIUAe1kqeuLebMO2Fu8 NQ7qNSGRkFLdF8Stk8LoJ2VXv1duY4Lciavvu3ae9MyMYC6mZU91v0LxZ5K7gS6W IC0cI9oU22WybqMXiLEfs/MAEz09NEfjoM0K9MR/rRlayqV+7pP1eKphWBRwF68z jjPHEQ== 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=B85i2gWETVrpF8Agu2U/hVlDcaAi9jpnNqsGB3fPb Uc=; b=mHXjrpJdez/hUEN+TTNo2jKa7ldoQaVIqEtwc2QbPCVwu/HlCOhMBwnT9 4WauM7nIFGkPZkj1QjtkEveNKak9cTZAZeH7YkKqbbpApXC8It0f2PskRSIt2fo/ lO9ht64JrVPLMkZJyWQoVkSIjn/uj35GbbkL4+/Sf/6JsYyZa4OyKqFNkRxERmER 1401GrRP83vX1SAtYp0M/BlnMy2Jk+KhAi9wGt6rMCC6z/QnF3JzGnIegXbfR3EU Yv8C5clhPS8ZIBAq4gATtmAnFN+wCSi07gyn8reAehuA3OHSY8L2APF+o123ymGJ RKKtBtgDJ9f038gcUGasLQ6DGSrIg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieehgddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth 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 EBC623064674; Fri, 16 Oct 2020 05:37:12 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko , 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" Date: Fri, 16 Oct 2020 11:37:10 +0200 Message-ID: <2107416.BS4W9YiMui@thomas> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v8 1/6] 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" 16/10/2020 11:15, Slava Ovsiienko: > From: Andrew Rybchenko > > On 10/16/20 10:48 AM, Viacheslav Ovsiienko wrote: > > > /** > > > + * Ethernet device Rx buffer segmentation capabilities. > > > + */ > > > +__extension__ > > > +struct rte_eth_rxseg_capa { > > > + uint16_t max_seg; /**< Maximum amount of segments to split. */ > > > > May be 'max_segs' to avoid confusing vs maximum segment length. > > > OK, max_nseg would be more appropriate. > > > > + uint16_t multi_pools:1; /**< Supports receiving to multiple pools.*/ > > > + uint16_t offset_allowed:1; /**< Supports buffer offsets. */ > > > + uint16_t offset_align_log2:4; /**< Required offset alignment. */ > > > > 4 bits are even insufficient to specify cache-line alignment. > > IMHO at least 8 bits are required. > > 4 bits seems to be quite sufficient. It is a log2, tells how many lsbs in offset should be zeroes. > 2^15 is 32K, it covers all reasonable alignments for uint16_t type. bitfields with uint16_t is not standard I think, we could experience build issues. If I remember well uint32_t is safer.