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 AC63DA04B5; Mon, 26 Oct 2020 10:37:20 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 23E1729C6; Mon, 26 Oct 2020 10:37:19 +0100 (CET) Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by dpdk.org (Postfix) with ESMTP id 85AC41D9E for ; Mon, 26 Oct 2020 10:37:18 +0100 (CET) Received: by mail-wm1-f67.google.com with SMTP id 13so10897223wmf.0 for ; Mon, 26 Oct 2020 02:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=KWmD4KouYy5zMdlUJEPezAWrNVfO1mMftgyTND32+iQ=; b=VtunDRmDk3pWktKPF7uWXzlRNOfCKRtHkUD3lHF5xcUyrIYnVklnrSSVDw+YF2zOLx VsGKLcxwKyS7sVpOLNPB1DfoHR0/AHs08qzxAwcRU66ZkXHXEslapilU9bxXWKgWby0L Q6IGKdZo3JENdFne2XmzksVQtOEOMqYTNfMBLs/vnks1jwFmzLZaGOXMINJNJ9K5kY6d e3CC1y8LuyMeCanESB61Mj/ajkQQmlKlT78OHk7VU/OnKVmmkr1QH/WD9j2NcKCf9Xpa oEyvm7OcZdMVARmcCQ6zwatcdDnUI+mdXKRUdphGWSUeOg0piXanjrIDgS86vDPNM/q+ AbIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KWmD4KouYy5zMdlUJEPezAWrNVfO1mMftgyTND32+iQ=; b=SE2tE5MVakRvqCckrzQtj/GIRDlP0iH97QY/3PQp6V5RkrXW5DvMpPsd6S79gDrdW5 FfWSMVG3I4sIQOGhcLkneg9uEUwv/mee60uuy86fByJ98iIsIgrzZQ5iOC3Q/JbS1rhC 9fRh80V3DD2Ypph8Z5qi/FonXJa2QHCEZzdYvLbBz37ZNwZ+FWyYgjHvs4lbgpsM0JA8 od8BIJprTOyYqV35kQJs6A63r17ifDGrv5oqZ60AwPP57cNWEC+/+VhgYg1GQq9r9gC3 u4EeRdMR7IxxpHLkqXN6r6tvoiZsOiia1QOTw/mD71SS+igPcq+do3q4z61O6FNClSUI v8cg== X-Gm-Message-State: AOAM530oh6M8kxfYOTsdyrAoZEG1C07GD4R8qiLkT96NXXRelx5AqTQP +RleNphKO2x7KbUnLj0d3Jxh5w== X-Google-Smtp-Source: ABdhPJwwQXr4lTfQx1JgSbpsDCfjMzibTHDAanxNqbX/YY1y9GkH1SMj8K2TlvYl1QfzzIKpdprkWg== X-Received: by 2002:a1c:b041:: with SMTP id z62mr5214899wme.183.1603705037183; Mon, 26 Oct 2020 02:37:17 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id y185sm19956449wmb.29.2020.10.26.02.37.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Oct 2020 02:37:16 -0700 (PDT) Date: Mon, 26 Oct 2020 10:37:15 +0100 From: Olivier Matz To: Ferruh Yigit Cc: Jeff Guo , jingjing.wu@intel.com, qi.z.zhang@intel.com, beilei.xing@intel.com, dev@dpdk.org, haiyue.wang@intel.com, Bruce Richardson Message-ID: <20201026093715.GJ1898@platinum> References: <20200909025415.6185-1-jia.guo@intel.com> <20201013081734.47507-1-jia.guo@intel.com> <0257ccb2-88eb-a49a-77f9-9e611f3c266a@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0257ccb2-88eb-a49a-77f9-9e611f3c266a@intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH v8] net/iavf: support flex desc metadata extraction 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" Hi, On Wed, Oct 14, 2020 at 01:31:39PM +0100, Ferruh Yigit wrote: > On 10/13/2020 9:17 AM, Jeff Guo wrote: > > Enable metadata extraction for flexible descriptors in AVF, that would > > allow network function directly get metadata without additional parsing > > which would reduce the CPU cost for VFs. The enabling metadata > > extractions involve the metadata of VLAN/IPv4/IPv6/IPv6-FLOW/TCP/MPLS > > flexible descriptors, and the VF could negotiate the capability of > > the flexible descriptor with PF and correspondingly configure the > > specific offload at receiving queues. > > > > Signed-off-by: Jeff Guo > > Acked-by: Haiyue Wang [...] > > +EXPERIMENTAL { > > + global: > > + > > + # added in 20.11 > > + rte_net_iavf_dynfield_proto_xtr_metadata_offs; > > + rte_net_iavf_dynflag_proto_xtr_vlan_mask; > > + rte_net_iavf_dynflag_proto_xtr_ipv4_mask; > > + rte_net_iavf_dynflag_proto_xtr_ipv6_mask; > > + rte_net_iavf_dynflag_proto_xtr_ipv6_flow_mask; > > + rte_net_iavf_dynflag_proto_xtr_tcp_mask; > > + rte_net_iavf_dynflag_proto_xtr_ip_offset_mask; > > As a namespace previously "rte_pmd_xxx" was used for PMD specific APIs, can > you please switch to that? > 'rte_net_' is used by the 'librte_net' library. > > Above list is the dynfield values, what is the correct usage for dynfields, > 1- Put dynfileds names in to the header, and application does a lookup > ('rte_mbuf_dynfield_lookup()') to get the dynfield values. > or > 2- Expose dynfield values to be accessed directly from application, as done above. > > @Oliver, can you please support. > > I can see (1) has advantage of portability if more than one PMD supports > same dynfield names, but that sees not a case for above ones. If I understand the question correctly, this is the same that was discussed here: http://inbox.dpdk.org/dev/20191030165626.w3flq5wdpitpsv2v@platinum/ To me, exporting the variables containing the dynfield offsets is easier to use: we don't need to have additional private variables to store them in each API users (usually one static variable per file, which can be heavy). Olivier