All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wang, Haiyue" <haiyue.wang@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
	"Ye, Xiaolong" <xiaolong.ye@intel.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [PATCH v9] net/ice: optimize protocol extraction by dynamic mbuf API
Date: Fri, 8 Nov 2019 14:08:16 +0000	[thread overview]
Message-ID: <E3B9F2FDCB65864C82CD632F23D8AB8773D90554@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <1962515.WBHSJCFqR1@xps>

Hi Thomas,

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, November 8, 2019 20:34
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: dev@dpdk.org; olivier.matz@6wind.com; Ye, Xiaolong <xiaolong.ye@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v9] net/ice: optimize protocol extraction by dynamic mbuf API
> 
> Hi,
> 
> I see this patch is already merged in next-net-intel,
> but please I would prefer to have below improvements first.
> 
> 07/11/2019 11:44, Haiyue Wang:
> > The original design is to use rte_mbuf::udata64 to save the metadata of
> > protocol extraction which has network protocol data fields and type, a
> > private API is used to decode this metadata.
> >
> > Use the dynamic mbuf field and flags to register the needed fields in
> > mbuf, to avoid overwriting 'rte_mbuf::udata64' if the application uses
> > it. It only needs 4B size to save the protocol extraction data, and its
> 
> Yes using a dynamic field is definitely more correct.
> 
> > type and validity is indicated by related bit in 'rte_mbuf::ol_flags'.
> 
> Better to say explicitly it uses a dynamic flag.
> 

Will update doc to make the description be better.

> > --- a/drivers/net/ice/rte_pmd_ice.h
> > +++ b/drivers/net/ice/rte_pmd_ice.h
> > +/**
> > + * @file rte_pmd_ice.h
> > + *
> > + * ice PMD specific functions.
> > + *
> > + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> > + *
> > + */
> 
> Adding the file in doxygen is good.
> I think it could be a separate patch for doxygen + cleanups.
> 
> > +/**
> > + * The supported network protocol extraction metadata format.
> > + */
> > +union proto_xtr_metadata {
> > -struct proto_xtr_flds {
> 
> Please add a prefix rte_ice_ or rte_net_ice_ as you wish.
> 

Missed, will be updated.

> [...]
> > +/**
> > + * The mbuf dynamic flag for VLAN protocol extraction metadata, it is valid
> > + * when dev_args 'proto_xtr' has 'vlan' specified.
> > + */
> > +#define PKT_RX_DYNF_PROTO_XTR_VLAN \
> > +	(rte_net_ice_dynflag_proto_xtr_vlan_mask)
> > +
> > +/**
> > + * The mbuf dynamic flag for IPv4 protocol extraction metadata, it is valid
> > + * when dev_args 'proto_xtr' has 'ipv4' specified.
> > + */
> > +#define PKT_RX_DYNF_PROTO_XTR_IPV4 \
> > +	(rte_net_ice_dynflag_proto_xtr_ipv4_mask)
> > +
> > +/**
> > + * The mbuf dynamic flag for IPv6 protocol extraction metadata, it is valid
> > + * when dev_args 'proto_xtr' has 'ipv6' specified.
> > + */
> > +#define PKT_RX_DYNF_PROTO_XTR_IPV6 \
> > +	(rte_net_ice_dynflag_proto_xtr_ipv6_mask)
> > +
> > +/**
> > + * The mbuf dynamic flag for IPv6 with flow protocol extraction metadata, it is
> > + * valid when dev_args 'proto_xtr' has 'ipv6_flow' specified.
> > + */
> > +#define PKT_RX_DYNF_PROTO_XTR_IPV6_FLOW \
> > +	(rte_net_ice_dynflag_proto_xtr_ipv6_flow_mask)
> > +
> > +/**
> > + * The mbuf dynamic flag for TCP protocol extraction metadata, it is valid
> > + * when dev_args 'proto_xtr' has 'tcp' specified.
> > + */
> > +#define PKT_RX_DYNF_PROTO_XTR_TCP \
> > +	(rte_net_ice_dynflag_proto_xtr_tcp_mask)
> 
> Those fields and flags are missing a RTE_ prefix.
> (Yes I know we are missing such prefix in rte_mbuf.f)
> 

The "PKT_RX_" in ' lib/librte_mbuf/rte_mbuf_core.h' will be changed to
"RTE_PKT_RX_" ?

Or keep the above as it is now, to keep the same ol_flags style, until all
the "PKT_RX_" are changed ?





  reply	other threads:[~2019-11-08 14:08 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-26 17:44 [dpdk-dev] [PATCH v1] net/ice: use dynamic mbuf API to handle protocol extraction Haiyue Wang
2019-10-29  7:34 ` [dpdk-dev] [PATCH v2] net/ice: optimize protocol extraction by dynamic mbuf API Haiyue Wang
2019-10-30 16:56   ` Olivier Matz
2019-10-31  1:16     ` Wang, Haiyue
2019-11-01  3:17   ` [dpdk-dev] [PATCH v3] " Haiyue Wang
2019-11-01 12:53     ` [dpdk-dev] [PATCH v4] " Haiyue Wang
2019-11-01 16:19       ` [dpdk-dev] [PATCH v5] " Haiyue Wang
2019-11-05  1:19         ` [dpdk-dev] [PATCH v6] " Haiyue Wang
2019-11-05  1:26           ` [dpdk-dev] [PATCH v7] " Haiyue Wang
2019-11-07  5:35           ` [dpdk-dev] [PATCH v8] " Haiyue Wang
2019-11-07  9:08             ` Ye Xiaolong
2019-11-07 10:38               ` Wang, Haiyue
2019-11-07 10:44           ` [dpdk-dev] [PATCH v9] " Haiyue Wang
2019-11-08  2:35             ` Ye Xiaolong
2019-11-08 12:34             ` Thomas Monjalon
2019-11-08 14:08               ` Wang, Haiyue [this message]
2019-11-08 14:39                 ` Thomas Monjalon
2019-11-08 15:04                   ` Wang, Haiyue
2019-11-08 15:03               ` Ye Xiaolong
2019-11-08 12:55             ` Thomas Monjalon
2019-11-08 14:01               ` Wang, Haiyue
2019-11-08 14:38                 ` Thomas Monjalon
2019-11-08 15:44           ` [dpdk-dev] [PATCH v10 0/2] " Haiyue Wang
2019-11-08 15:44             ` [dpdk-dev] [PATCH v10 1/2] " Haiyue Wang
2019-11-08 15:44             ` [dpdk-dev] [PATCH v10 2/2] doc: add the ice PMD doxygen Haiyue Wang
2019-11-08 15:58             ` [dpdk-dev] [PATCH v10 0/2] net/ice: optimize protocol extraction by dynamic mbuf API Thomas Monjalon
2019-11-09  1:31               ` Ye Xiaolong

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=E3B9F2FDCB65864C82CD632F23D8AB8773D90554@shsmsx102.ccr.corp.intel.com \
    --to=haiyue.wang@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=olivier.matz@6wind.com \
    --cc=thomas@monjalon.net \
    --cc=xiaolong.ye@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.