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&data=02%7C01
> >
> %7Cdekelp%40mellanox.com%7C9ee87004dc3943b945c908d805ee0bcc%7Ca
> 652971c
> >
> 7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637265867256841029&sdata
> =rf1zYz
> >
> fNLGdqayXLHffO%2FrM%2FeX5op6KO91RDKq%2BYk3Q%3D&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.
next prev parent 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).