All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: Jeff Guo <jia.guo@intel.com>,
	jingjing.wu@intel.com, qi.z.zhang@intel.com,
	beilei.xing@intel.com, dev@dpdk.org, haiyue.wang@intel.com,
	Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] [PATCH v8] net/iavf: support flex desc metadata extraction
Date: Mon, 26 Oct 2020 10:37:15 +0100	[thread overview]
Message-ID: <20201026093715.GJ1898@platinum> (raw)
In-Reply-To: <0257ccb2-88eb-a49a-77f9-9e611f3c266a@intel.com>

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 <jia.guo@intel.com>
> > Acked-by: Haiyue Wang <haiyue.wang@intel.com>

[...]

> > +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

  parent reply	other threads:[~2020-10-26  9:37 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-09  2:54 [dpdk-dev] [PATCH v1] net/iavf: support flex desc metadata extraction Jeff Guo
2020-09-17  3:00 ` Wang, Haiyue
2020-09-18  2:41   ` Guo, Jia
2020-09-23  7:45 ` [dpdk-dev] [PATCH v2] " Jeff Guo
2020-09-23  7:52 ` [dpdk-dev] [PATCH v3] " Jeff Guo
2020-09-23  8:10   ` Wang, Haiyue
2020-09-23  8:22     ` Guo, Jia
2020-09-23 15:36 ` [dpdk-dev] [PATCH v4] " Jeff Guo
2020-09-25  6:23 ` [dpdk-dev] [PATCH v5] " Jeff Guo
2020-09-25  6:33   ` Wang, Haiyue
2020-09-27  2:08 ` [dpdk-dev] [PATCH v6] " Jeff Guo
2020-09-27  3:00   ` Zhang, Qi Z
2020-09-28 15:59   ` Ferruh Yigit
2020-09-28 16:17     ` Wang, Haiyue
2020-09-28 16:21       ` Bruce Richardson
2020-09-28 16:29         ` Wang, Haiyue
2020-09-29  2:27     ` Guo, Jia
2020-09-29  6:10 ` [dpdk-dev] [PATCH v7] " Jeff Guo
2020-09-29  6:12 ` Jeff Guo
2020-10-13  8:17 ` [dpdk-dev] [PATCH v8] " Jeff Guo
2020-10-13 10:10   ` Zhang, Qi Z
2020-10-14 12:31   ` Ferruh Yigit
2020-10-14 14:03     ` Bruce Richardson
2020-10-15  3:40       ` Guo, Jia
2020-10-15  5:26     ` Guo, Jia
2020-10-15  8:33       ` Ferruh Yigit
2020-10-26  9:37     ` Olivier Matz [this message]
2020-10-26 11:41       ` Wang, Haiyue
2020-10-15  3:41 ` [dpdk-dev] [PATCH v9] " Jeff Guo
2020-10-27  5:04 ` [dpdk-dev] [PATCH v10] " Jeff Guo
2020-10-27  5:21   ` Wang, Haiyue
2020-10-27  8:27     ` Guo, Jia
2020-10-27 11:55     ` Zhang, Qi Z
2020-10-30  2:54 ` [dpdk-dev] [PATCH v11] " Jeff Guo
2020-10-30  8:34 ` [dpdk-dev] [PATCH v12] " Jeff Guo
2020-10-30  8:40 ` Jeff Guo
2020-10-30  9:35   ` Zhang, Qi Z
2020-10-30 10:51   ` Ferruh Yigit
2020-10-30 11:14     ` Zhang, Qi Z
2020-10-30 16:03       ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201026093715.GJ1898@platinum \
    --to=olivier.matz@6wind.com \
    --cc=beilei.xing@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=haiyue.wang@intel.com \
    --cc=jia.guo@intel.com \
    --cc=jingjing.wu@intel.com \
    --cc=qi.z.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.