All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Guo, Jia" <jia.guo@intel.com>
To: "Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Wu, Jingjing" <jingjing.wu@intel.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>,
	"Xing, Beilei" <beilei.xing@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Wang, Haiyue" <haiyue.wang@intel.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [dpdk-dev] [PATCH v8] net/iavf: support flex desc metadata extraction
Date: Thu, 15 Oct 2020 05:26:19 +0000	[thread overview]
Message-ID: <82ad9cd928c24e798de6dd6fe2001099@intel.com> (raw)
In-Reply-To: <0257ccb2-88eb-a49a-77f9-9e611f3c266a@intel.com>


> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Wednesday, October 14, 2020 8:32 PM
> To: Guo, Jia <jia.guo@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Zhang, Qi Z <qi.z.zhang@intel.com>; Xing, Beilei <beilei.xing@intel.com>
> Cc: dev@dpdk.org; Wang, Haiyue <haiyue.wang@intel.com>; Richardson,
> Bruce <bruce.richardson@intel.com>; Olivier Matz <olivier.matz@6wind.com>
> Subject: Re: [PATCH v8] net/iavf: support flex desc metadata extraction
> 
> 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>
> > ---
> > v8:
> > rebase patch for apply issue
> >
> > v7:
> > clean some useless and add doc
> >
> > v6:
> > rebase patch
> >
> > v5:
> > remove ovs configure since ovs is not protocol extraction
> >
> > v4:
> > add flex desc type in rx queue for handling vector path handle ovs
> > flex type
> >
> > v3:
> > export these global symbols into .map
> >
> > v2:
> > remove makefile change and modify the rxdid handling
> > ---
> >   config/rte_config.h                       |   3 +
> >   doc/guides/nics/intel_vf.rst              |  16 +
> >   doc/guides/rel_notes/release_20_11.rst    |   6 +
> >   drivers/net/iavf/iavf.h                   |  24 +-
> >   drivers/net/iavf/iavf_ethdev.c            | 394 ++++++++++++++++++++++
> >   drivers/net/iavf/iavf_rxtx.c              | 252 ++++++++++++--
> >   drivers/net/iavf/iavf_rxtx.h              | 168 +++++----
> >   drivers/net/iavf/iavf_rxtx_vec_common.h   |   3 +
> >   drivers/net/iavf/iavf_vchnl.c             |  22 +-
> >   drivers/net/iavf/meson.build              |   2 +
> >   drivers/net/iavf/rte_pmd_iavf.h           | 250 ++++++++++++++
> >   drivers/net/iavf/rte_pmd_iavf_version.map |  13 +
> >   12 files changed, 1039 insertions(+), 114 deletions(-)
> >   create mode 100644 drivers/net/iavf/rte_pmd_iavf.h
> >
> > diff --git a/config/rte_config.h b/config/rte_config.h index
> > 03d90d78bc..2c53072c3d 100644
> > --- a/config/rte_config.h
> > +++ b/config/rte_config.h
> > @@ -127,6 +127,9 @@
> >   #define RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF 4
> >   #define RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM 4
> >
> > +/* iavf defines */
> > +#undef RTE_LIBRTE_IAVF_16BYTE_RX_DESC
> > +
> 
> Hi Jeff,
> 
> The 'RTE_LIBRTE_IAVF_16BYTE_RX_DESC' was already there, not introduced
> with this patch, so I think better to add this change as different patch.
> 
> Also not sure if we want to add more config options to the 'rte_config.h',
> indeed otherway around and we are trying to get rid of as much as compile
> time optios.
> cc'ed Bruce too.
> 
> >   /* Ring net PMD settings */
> >   #define RTE_PMD_RING_MAX_RX_RINGS 16
> >   #define RTE_PMD_RING_MAX_TX_RINGS 16 diff --git
> > a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst index
> > ade5152595..207f456143 100644
> > --- a/doc/guides/nics/intel_vf.rst
> > +++ b/doc/guides/nics/intel_vf.rst
> > @@ -615,3 +615,19 @@ which belongs to the destination VF on the VM.
> >   .. figure:: img/inter_vm_comms.*
> >
> >      Inter-VM Communication
> > +
> > +
> > +Pre-Installation Configuration
> > +------------------------------
> > +
> > +Config File Options
> > +~~~~~~~~~~~~~~~~~~~
> > +
> > +The following options can be modified in the ``config`` file.
> > +Please note that enabling debugging options may affect system
> performance.
> > +
> > +- ``CONFIG_RTE_LIBRTE_IAVF_16BYTE_RX_DESC`` (default ``n``)
> 
> There is no 'CONFIG_RTE_LIBRTE_IAVF_16BYTE_RX_DESC' anymore, this is
> from make days naming.
> 
> Instead, what do you think not adding the
> 'RTE_LIBRTE_IAVF_16BYTE_RX_DESC' to the 'rte_config.h', but document
> how this flag can be provided by meson during
> build:
> meson -Dc_args="-DRTE_LIBRTE_IAVF_16BYTE_RX_DESC"
> 
> And we should plan for long term to convert this compile time flag to runtime
> devargs.
> 
> What do you think?
> 

Sorry, I miss this comment. And, I agree on. Too more compile time flag is not friendly to use. Do you agree to do the runtime devargs on next separate patch set?

> > +
> > +  Toggle to use a 16-byte RX descriptor, by default the RX descriptor is 32
> byte.
> > +  Configure to 16-byte Rx descriptor may cause a negotiation failure
> > + during VF driver initialization  if the PF driver doesn't support.
> > diff --git a/doc/guides/rel_notes/release_20_11.rst
> > b/doc/guides/rel_notes/release_20_11.rst
> > index e7691ee732..93d3ccc60a 100644
> > --- a/doc/guides/rel_notes/release_20_11.rst
> > +++ b/doc/guides/rel_notes/release_20_11.rst
> > @@ -160,6 +160,12 @@ New Features
> >     packets with specified ratio, and apply with own set of actions with a fate
> >     action. When the ratio is set to 1 then the packets will be 100% mirrored.
> >
> > +* **Updated Intel iavf driver.**
> > +
> > +  Updated iavf PMD with new features and improvements, including:
> > +
> > +  * Added support for flexible descriptor metadata extraction.
> > +
> 
> Can you please move the update to the net drivers block, instead of very
> bottom.
> There is an order in the release notes (as commented in section header) like:
> - core libs
> - ethdev lib related changes
> - ethdev PMDS change
> - ...
> 

Sure, will update it in v10.

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

Make sense.

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

  parent reply	other threads:[~2020-10-15  5:26 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 [this message]
2020-10-15  8:33       ` Ferruh Yigit
2020-10-26  9:37     ` Olivier Matz
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=82ad9cd928c24e798de6dd6fe2001099@intel.com \
    --to=jia.guo@intel.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=jingjing.wu@intel.com \
    --cc=olivier.matz@6wind.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.