From: Dekel Peled <dekelp@nvidia.com>
To: Maxime Leroy <maxime.leroy@6wind.com>
Cc: Ori Kam <orika@nvidia.com>,
NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] ethdev: add VLAN attributes to ETH and VLAN items
Date: Mon, 5 Oct 2020 09:37:19 +0000 [thread overview]
Message-ID: <MN2PR12MB4375B0058CAB229D95605968BB0C0@MN2PR12MB4375.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CAEykdvoEjNRB+F4=c5xV3043Dn-Qgcte2sHCyQ8jYghATbX2Nw@mail.gmail.com>
Thanks, PSB.
> -----Original Message-----
> From: Maxime Leroy <maxime.leroy@6wind.com>
> Sent: Friday, October 2, 2020 3:39 PM
> To: Dekel Peled <dekelp@nvidia.com>
> Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; ferruh.yigit@intel.com;
> arybchenko@solarflare.com; dev@dpdk.org; Dekel Peled
> <dekelp@mellanox.com>
> Subject: Re: [PATCH] ethdev: add VLAN attributes to ETH and VLAN items
>
> Hi Dekel,
>
> On Thu, Oct 1, 2020 at 8:49 PM Dekel Peled <dekelp@nvidia.com> wrote:
> >
> > From: Dekel Peled <dekelp@mellanox.com>
> >
> > This patch implements the change proposes in RFC [1], adding dedicated
> > fields to ETH and VLAN items structs, to clearly define the required
> > characteristic of a packet, and enable precise match criteria.
> >
> > [1]
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > s.dpdk.org%2Farchives%2Fdev%2F2020-
> August%2F177536.html&data=02%7C
> >
> 01%7Cdekelp%40nvidia.com%7Cc12bfd3f662747f7b7c408d866d0376f%7C430
> 83d15
> >
> 727340c1b7db39efd9ccc17a%7C0%7C0%7C637372391779092411&sdata=
> yeOKvc
> > 4r0dL09UZ65%2Bt4qWJqJmcp21VyPSK%2FhbablKI%3D&reserved=0
> >
> > Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> > ---
> > doc/guides/rel_notes/release_20_11.rst | 7 +++++++
> > lib/librte_ethdev/rte_flow.h | 16 +++++++++++++---
> > 2 files changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/release_20_11.rst
> > b/doc/guides/rel_notes/release_20_11.rst
> > index 7f9d0dd..199c60b 100644
> > --- a/doc/guides/rel_notes/release_20_11.rst
> > +++ b/doc/guides/rel_notes/release_20_11.rst
> > @@ -173,6 +173,13 @@ API Changes
> > * ``_rte_eth_dev_callback_process()`` ->
> ``rte_eth_dev_callback_process()``
> > * ``_rte_eth_dev_reset`` -> ``rte_eth_dev_internal_reset()``
> >
> > +* ethdev: Added new field ``vlan_exist`` to structure
> > +``rte_flow_item_eth``,
> > + indicating that at least one VLAN exists in the packet header.
> > +
> > +* ethdev: Added new field ``more_vlans_exist`` to structure
> > + ``rte_flow_item_vlan``, indicating that at least one more VLAN
> > +exists in
> > + packet header, following this VLAN.
> > +
> > * rawdev: Added a structure size parameter to the functions
> > ``rte_rawdev_queue_setup()``, ``rte_rawdev_queue_conf_get()``,
> > ``rte_rawdev_info_get()`` and ``rte_rawdev_configure()``, diff
> > --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > index da8bfa5..39d04ef 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -723,14 +723,18 @@ struct rte_flow_item_raw {
> > * If the @p type field contains a TPID value, then only tagged packets with
> the
> > * specified TPID will match the pattern.
> > * Otherwise, only untagged packets will match the pattern.
> > - * If the @p ETH item is the only item in the pattern, and the @p
> > type field
> > - * is not specified, then both tagged and untagged packets will match
> > the
> > - * pattern.
> > + * The field @p vlan_exist can be used to match specific packet
> > + types, instead
> > + * of using the @p type field.
> > + * This can be used to match any type of tagged packets.
> > + * If the @p type and @p vlan_exist fields are not specified, then
> > + both tagged
> > + * and untagged packets will match the pattern.
> > */
> > struct rte_flow_item_eth {
> > struct rte_ether_addr dst; /**< Destination MAC. */
> > struct rte_ether_addr src; /**< Source MAC. */
> > rte_be16_t type; /**< EtherType or TPID. */
> > + uint32_t vlan_exist:1; /**< At least one VLAN exist in header. */
> > + uint32_t reserved:31; /**< Reserved, must be zero. */
> > };
>
> To resume:
> - type and vlan_exists fields not specified: tag and untagged matched
> - with vlan_exists, match only tag or untagged
> - with type matching specific ethernet type
> - vlan_exists and type should not setted at the same time ?
PMD should validate they don't conflict.
>
> With this new specification, I think you address all the use cases.
> That's great !
>
Glad to see we agree on this.
> >
> > /** Default mask for RTE_FLOW_ITEM_TYPE_ETH. */ @@ -752,10 +756,16
> @@
> > struct rte_flow_item_eth {
> > * the preceding pattern item.
> > * If a @p VLAN item is present in the pattern, then only tagged packets
> will
> > * match the pattern.
> > + * The field @p more_vlans_exist can be used to match specific packet
> > + types,
> > + * instead of using the @p inner_type field.
> > + * This can be used to match any type of tagged packets.
> > */
>
> Could you please specify what the expected behavior when inner_type and
> more_vlans_exist are not specified .
> What is the default behavior ?
>
You wrote above for the eth item, if the user didn't specify it means don't-care.
> > struct rte_flow_item_vlan {
> > rte_be16_t tci; /**< Tag control information. */
> > rte_be16_t inner_type; /**< Inner EtherType or TPID. */
> > + uint32_t more_vlans_exist:1;
> > + /**< At least one more VLAN exist in header, following this VLAN. */
> > + uint32_t reserved:31; /**< Reserved, must be zero. */
> > };
> >
> > /** Default mask for RTE_FLOW_ITEM_TYPE_VLAN. */
> > --
> > 1.8.3.1
> >
>
> I am still wondering, why not using a new item 'NOT' for example to match
> only eth packet not tagged ?
> example: eth / not vlan. It's a more generic solution.
>
> Here in this commit, we add a reference on VLAN fields on ethernet header.
> But tomorrow, we could do the same for mpls by adding mpls_exists in the
> eth item and so on.
>
> In fact, we have the same needs for IPv6 options. To match for example,
> ipv6 packet with no fragment option.
> With a NOT field, it can be easily done: > eth / ipv6 / no ipv6_frag.
>
> Adding new fields 'item'_exists into eth and ipv6 do the jobs, but having a
> NOT attribute is a more generic solution.
>
> It could address many other use cases like matching any udp packets that are
> not vxlan ( eth / ipv4 / vxlan / not udp),
>
> Let me know what you think about that.
I agree with Thomas Monjalon response on this.
>
> Regards,
>
> Maxime
next prev parent reply other threads:[~2020-10-05 9:37 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-01 18:49 Dekel Peled
2020-10-01 19:01 ` [dpdk-dev] [PATCH v2] " Dekel Peled
2020-10-07 18:21 ` [dpdk-dev] [PATCH v3] " Dekel Peled
2020-10-02 12:39 ` [dpdk-dev] [PATCH] " Maxime Leroy
2020-10-02 14:40 ` Thomas Monjalon
2020-10-05 9:37 ` Dekel Peled [this message]
2020-10-07 11:52 ` Maxime Leroy
2020-10-07 12:13 ` Ori Kam
2020-10-07 14:01 ` Dekel Peled
2020-10-14 18:53 ` [dpdk-dev] [PATCH v4 0/2] support VLAN attributes in " Dekel Peled
2020-10-14 18:53 ` [dpdk-dev] [PATCH v4 1/2] ethdev: add VLAN attributes to " Dekel Peled
2020-10-14 20:13 ` Thomas Monjalon
2020-10-15 10:34 ` Andrew Rybchenko
2020-10-15 15:06 ` Dekel Peled
2020-10-14 18:53 ` [dpdk-dev] [PATCH v4 2/2] app/testpmd: support VLAN attributes in " Dekel Peled
2020-10-15 6:09 ` Ori Kam
2020-10-15 15:51 ` [dpdk-dev] [PATCH v5 0/2] " Dekel Peled
2020-10-15 15:51 ` [dpdk-dev] [PATCH v5 1/2] ethdev: add VLAN attributes to " Dekel Peled
2020-10-15 16:11 ` Ori Kam
2020-10-15 15:51 ` [dpdk-dev] [PATCH v5 2/2] app/testpmd: support VLAN attributes in " Dekel Peled
2020-10-15 23:18 ` [dpdk-dev] [PATCH v5 0/2] " 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=MN2PR12MB4375B0058CAB229D95605968BB0C0@MN2PR12MB4375.namprd12.prod.outlook.com \
--to=dekelp@nvidia.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=maxime.leroy@6wind.com \
--cc=orika@nvidia.com \
--cc=thomas@monjalon.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).