From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 988E1A04AD; Mon, 24 Jan 2022 18:46:45 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2170D41172; Mon, 24 Jan 2022 18:46:45 +0100 (CET) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by mails.dpdk.org (Postfix) with ESMTP id 3B1B840040 for ; Mon, 24 Jan 2022 18:46:43 +0100 (CET) Received: by mail-io1-f50.google.com with SMTP id s18so3957173ioa.12 for ; Mon, 24 Jan 2022 09:46:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m3S09qGKRwJvZea/qfCT+Bbeo4c7F74cW6Todp3YnrY=; b=AiJZwQX3Y7Ct0Ej13qR2DI28TRf4dxZ06c8N0pTQcIK2V+YSRPhp5VLGBMZct9d5gw mv0ch/yf71sVdxKALlczIaChuILMCEbpS1PaM8FO3BPSE3SebaoroXtiVoPpmK1VDa9G /PTcalu58wMkxvZuD0xNiFpk/SFn5kPNOybP2kNPP9s/IkSZprcNkfJDQhwaMuwwpqvy sApzeMzSpCrU4k9+lK6HlinRuPjMx/JAdBwUPNcEUA2tYkD0JnGZ5nSGV5DPPP1w2qib Yzh87vGDWgdwNvlD6EQlT9k/BiOOmpzujzzZnUgkZneXIzoHpTVSl7DhIlQAa1D7HxSI XXWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m3S09qGKRwJvZea/qfCT+Bbeo4c7F74cW6Todp3YnrY=; b=65irVIzQoptMNjsnpMD+pP4B31+QeVNh2fZcWcpus/xCD9rwfe0/LRtTusmYkD5vjf LC6JFRAYupgjxefaEmXZ/HwS11syKDz5azId08wZgL+sN2LuAUqNO57OhMR1Db50UQGX hOb1nvJbno3TeHg/7cC6BQ1cbVUQ/mfhC8xmE54ptcZQh1umBgD0YVMh6hpZhfmLkSY1 JEB9hfVmDsATScnojYuvRFZktggihPT+fwS+CAyfhWuLKQxFlUDh/LGP2CrAvrDSlEX+ r+iHsigaeEYiF9FtNVZtGlqitqAWecqac/KVjOOiGkHy/GYeKcoz7rIy0rwYbRKJfW+Q xm+Q== X-Gm-Message-State: AOAM532Y8OGT6gl3d3ZBibKwPQ6oRhWhjivFbykR4icNO24jr/2jeg4l D6AZH60ZJ3Ggcs5rcZpRhRYcNuWC4dPdYBZ6XHU= X-Google-Smtp-Source: ABdhPJyv24JS6OUOvwwzx7yqI4Y2k779/ndDBiOlHMgwHcwgZKAporPL59msibq7fkFVifc0wp5SjsJOKRAbeWUPI/c= X-Received: by 2002:a02:9147:: with SMTP id b7mr7723770jag.266.1643046401934; Mon, 24 Jan 2022 09:46:41 -0800 (PST) MIME-Version: 1.0 References: <20211006044835.3936226-1-akozyrev@nvidia.com> <20220118153027.3947448-2-akozyrev@nvidia.com> <4371468.LvFx2qVVIh@thomas> In-Reply-To: <4371468.LvFx2qVVIh@thomas> From: Jerin Jacob Date: Mon, 24 Jan 2022 23:16:15 +0530 Message-ID: Subject: Re: [PATCH v2 01/10] ethdev: introduce flow pre-configuration hints To: Thomas Monjalon Cc: Alexander Kozyrev , dpdk-dev , Ori Kam , Ivan Malov , Andrew Rybchenko , Ferruh Yigit , mohammad.abdul.awal@intel.com, Qi Zhang , Jerin Jacob , Ajit Khaparde , "Richardson, Bruce" , David Marchand , Olivier Matz , Stephen Hemminger Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, Jan 24, 2022 at 11:05 PM Thomas Monjalon wrote: > > 24/01/2022 15:36, Jerin Jacob: > > On Tue, Jan 18, 2022 at 9:01 PM Alexander Kozyrev wrote: > > > +struct rte_flow_port_attr { > > > + /** > > > + * Version of the struct layout, should be 0. > > > + */ > > > + uint32_t version; > > > > Why version number? Across DPDK, we are using dynamic function > > versioning, I think, that would be sufficient for ABI versioning > > Function versioning is not ideal when the structure is accessed > in many places like many drivers and library functions. > > The idea of this version field (which can be a bitfield) > is to update it when some new features are added, > so the users of the struct can check if a feature is there > before trying to use it. > It means a bit more code in the functions, but avoid duplicating functions > as in function versioning. > > Another approach was suggested by Bruce, and applied to dmadev. > It is assuming we only add new fields at the end (no removal), > and focus on the size of the struct. > By passing sizeof as an extra parameter, the function knows > which fields are OK to use. > Example: http://code.dpdk.org/dpdk/v21.11/source/lib/dmadev/rte_dmadev.c#L476 + @Richardson, Bruce Either approach is fine, No strong opinion. We can have one approach and use it across DPDK for consistency. > >