DPDK patches and discussions
 help / color / mirror / Atom feed
From: Dekel Peled <dekelp@mellanox.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
	"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
	Ori Kam <orika@mellanox.com>,
	"john.mcnamara@intel.com" <john.mcnamara@intel.com>,
	"marko.kovacevic@intel.com" <marko.kovacevic@intel.com>,
	Asaf Penso <asafp@mellanox.com>, Matan Azrad <matan@mellanox.com>,
	Eli Britstein <elibr@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC] ethdev: add fragment attribute to IPv6 item
Date: Mon, 1 Jun 2020 06:11:15 +0000	[thread overview]
Message-ID: <VI1PR05MB53906B3CA2B769422E11FBA7B68A0@VI1PR05MB5390.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <20200531223832.1cbcd75b@hermes.lan>

Thanks, PSB.

> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Monday, June 1, 2020 8:39 AM
> To: Dekel Peled <dekelp@mellanox.com>
> Cc: ferruh.yigit@intel.com; arybchenko@solarflare.com; Ori Kam
> <orika@mellanox.com>; john.mcnamara@intel.com;
> marko.kovacevic@intel.com; Asaf Penso <asafp@mellanox.com>; Matan
> Azrad <matan@mellanox.com>; Eli Britstein <elibr@mellanox.com>;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC] ethdev: add fragment attribute to IPv6 item
> 
> On Sun, 31 May 2020 17:43:29 +0300
> Dekel Peled <dekelp@mellanox.com> wrote:
> 
> > Using the current implementation of DPDK, an application cannot match
> > on fragmented/non-fragmented IPv6 packets in a simple way.
> >
> > In current implementation:
> > IPv6 header doesn't contain information regarding the packet
> > fragmentation.
> > Fragmented IPv6 packets contain a dedicated extension header, as
> > detailed in RFC [1], which is not yet supported in rte_flow.
> > Non-fragmented packets don't contain the fragment extension header.
> > For an application to match on non-fragmented IPv6 packets, the
> > current implementation doesn't provide a suitable solution.
> > Matching on the Next Header field is not sufficient, since additional
> > extension headers might be present in the same packet.
> > To match on fragmented IPv6 packets, the same difficulty exists.
> >
> > Proposed update:
> > An additional value will be added to IPv6 header struct.
> > This value will contain the fragmentation attribute of the packet,
> > providing simple means for identification of fragmented and
> > non-fragmented packets.
> >
> > This update changes ABI, and is proposed for the 20.11 LTS version.
> >
> > [1]
> >
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails
> > .dpdk.org%2Farchives%2Fdev%2F2020-
> March%2F160255.html&amp;data=02%7C01
> >
> %7Cdekelp%40mellanox.com%7C9ee87004dc3943b945c908d805ee0bcc%7Ca
> 652971c
> >
> 7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637265867256841029&amp;sdata
> =rf1zYz
> >
> fNLGdqayXLHffO%2FrM%2FeX5op6KO91RDKq%2BYk3Q%3D&amp;reserved
> =0
> >
> > Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> > ---
> >  lib/librte_ethdev/rte_flow.h | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index b0e4199..3bc8ce1 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -787,6 +787,8 @@ struct rte_flow_item_ipv4 {
> >   */
> >  struct rte_flow_item_ipv6 {
> >  	struct rte_ipv6_hdr hdr; /**< IPv6 header definition. */
> > +	uint32_t is_frag:1; /**< Is IPv6 packet fragmented/non-fragmented.
> */
> > +	uint32_t reserved:31; /**< Reserved, must be zero. */
> >  };
> 
> You can't do this in the 20.08 release it would be an ABI breakage.
Please see above, I noted in the commit log that this is proposed for 20.11.

  reply	other threads:[~2020-06-01  6:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-31 14:43 Dekel Peled
2020-06-01  5:38 ` Stephen Hemminger
2020-06-01  6:11   ` Dekel Peled [this message]
2020-06-02 14:32 ` Andrew Rybchenko
2020-06-02 18:28   ` Ori Kam
2020-06-02 19:04     ` Adrien Mazarguil
2020-06-03  8:16       ` Ori Kam
2020-06-03 12:10         ` Dekel Peled
2020-06-18  6:58           ` Dekel Peled
2020-06-28 14:52             ` Dekel Peled
2020-07-05 13:13       ` Andrew Rybchenko
2020-08-03 17:01 ` [dpdk-dev] [RFC v2] ethdev: add extensions attributes " Dekel Peled
2020-08-03 17:11   ` [dpdk-dev] [RFC v3] " Dekel Peled

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=VI1PR05MB53906B3CA2B769422E11FBA7B68A0@VI1PR05MB5390.eurprd05.prod.outlook.com \
    --to=dekelp@mellanox.com \
    --cc=arybchenko@solarflare.com \
    --cc=asafp@mellanox.com \
    --cc=dev@dpdk.org \
    --cc=elibr@mellanox.com \
    --cc=ferruh.yigit@intel.com \
    --cc=john.mcnamara@intel.com \
    --cc=marko.kovacevic@intel.com \
    --cc=matan@mellanox.com \
    --cc=orika@mellanox.com \
    --cc=stephen@networkplumber.org \
    /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).