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 D7162A04B5; Tue, 27 Oct 2020 17:25:44 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 35DC16A15; Tue, 27 Oct 2020 17:25:43 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 5F5595AB9 for ; Tue, 27 Oct 2020 17:25:40 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 0389D5C00D9; Tue, 27 Oct 2020 12:25:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 27 Oct 2020 12:25:39 -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= TBfkKtPW4GYhA4CGlPW8m08RN4hub0KQ3e8El1gh850=; b=PynUrV/+1sy7F6al dUTFZ04hYpTIbq3sjVO2+EToeP+2tVEZvCfy03mg68OfJT3QX2ZP6S5GgH6eyz0c h7h0CF9CyQZ7K0j4fj5qA6sl6BMFm2nH0WzX2VelNSksHwjhzeuIRHHP8PQhZcwu 5MBnaHkJoH1tYLewzPbL31FQcB+fJbYE/mdR4QLNjOhNrF66uYf5YdcTekFOOd+Q V2J/BZ88mxH4EXjuk2v6gMgL8kkEks8Kxc9v0ZxR+xwOR6ld9uc0Btt7XZSDe8s9 rpJVW9drULHmko0s2OFHZdSaSWoHE/k4WnxNxu9TVqV5gw67YVZiaBUF8ws9wdnv TARPvw== 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=TBfkKtPW4GYhA4CGlPW8m08RN4hub0KQ3e8El1gh8 50=; b=RaOh9SF93EXXL/XO71AMxG3SGQnHQzsguWlYRHlVg3mEw5A7sXrTI5xF/ fvlot/WUr1bJq0UNA/oWz/rHz2huLdwiVnNDabM0owhmg5yxbFtV4K+G53xXlw2M gAeofuARPFANpoCmeefqhEQzYj7X9ztpZ5uJmBh39JZnBlcLZjJlm4uaF25SXdnT uGK5cO8n9fWqccgFK6slA5gFhDKz9UtPy5Sw3vzcZzRh6kqoEcUYEAtyohRZldEN 68f3EDTvkcCK77KnDKW9EfQJ3BCOvxfBytBnPtcw5Yo+rrL8pGZunShZXA+OnKDU yuuwoi4Eadz0yJowucYabDqFWlsxw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkeelgdekjecutefuodetggdotefrodftvf 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 E0B1B3064682; Tue, 27 Oct 2020 12:25:36 -0400 (EDT) From: Thomas Monjalon To: Olivier Matz Cc: dev@dpdk.org, ferruh.yigit@intel.com, david.marchand@redhat.com, bruce.richardson@intel.com, andrew.rybchenko@oktetlabs.ru, akhil.goyal@nxp.com, Yong Wang Date: Tue, 27 Oct 2020 17:25:36 +0100 Message-ID: <2464752.bik2qvyLj3@thomas> In-Reply-To: <20201027104545.GR1898@platinum> References: <20201026052105.1561859-1-thomas@monjalon.net> <20201026222013.2147904-10-thomas@monjalon.net> <20201027104545.GR1898@platinum> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 09/15] net/vmxnet3: switch MSS hint to dynamic mbuf field 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" 27/10/2020 11:45, Olivier Matz: > On Mon, Oct 26, 2020 at 11:20:07PM +0100, Thomas Monjalon wrote: > > The segment count, used for MSS guess, > > was stored in the deprecated mbuf field udata64. > > It is moved to a dynamic field in order to allow removal of udata64. > > > > Signed-off-by: Thomas Monjalon > > After seeing this commit, I wonder if we shouldn't introduce an > enhancement in the dynamic field API. > > Previously, the driver used udata64 only internally, so without any > risk. The risky usages of udata64 were when the mbuf goes out of a > module. > > Changing to dynamic field makes the code safe for any use, but consumes > more memory. > > I wonder if we shouldn't (later) introduce a flag RTE_MBUF_DYN_F_SHARED, > or something similar, to say that this field is only used inside a > module, and that its memory can be shared with other dynamic fields. Yes can be a later improvement if the sharing limitations are properly defined. We can also share some offsets which are used differently in Rx and Tx.