From: Dekel Peled <dekelp@mellanox.com>
To: Matan Azrad <matan@mellanox.com>,
Slava Ovsiienko <viacheslavo@mellanox.com>
Cc: Ori Kam <orika@mellanox.com>, Asaf Penso <asafp@mellanox.com>,
Eli Britstein <elibr@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: [dpdk-dev] [RFC] net/mlx5: support match on IPv4 and IPv6 fragment fields
Date: Wed, 18 Mar 2020 16:50:55 +0000 [thread overview]
Message-ID: <AM4PR05MB3460E75E0B52716013BB86C0B6F70@AM4PR05MB3460.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <AM4PR05MB346043CD1A77B2204BB92A2AB6F70@AM4PR05MB3460.eurprd05.prod.outlook.com>
In order to send a packet that is larger than the path MTU<https://en.wikipedia.org/wiki/Maximum_transmission_unit>, the sending node splits the packet into fragments.
IPv4 Flags and Fragment Offset header fields , and IPv6 fragment extension header fields, contain the required
Information to indicate that a packet is a fragment of a large, fragmented packet.
They also indicate the fragment packet location in the fragmented packet (first, last or other), and the offset of
this fragment in the fragmented packet.
In IPv4 header, the relevant fields are:
1. Flags.MF (More Fragments):
Set if More fragments follow..
2. Fragment Offset (13 bits):
Offset of fragment, in 8-bytes blocks, from the beginning of the original packet data.
In IPv6 header of fragmented packet, a Fragment extension header is present, identified by Next Header value of 44.
This extension header includes:
1. M flag, with the same function as IPv4 MF flag.
2. Fragment Offset, same as IPv4 Fragment Offset.
The following table shows the expected values of these fields.
Packet type
M/MF flag
Fragment Offset
Unfragmented packet
0
0
Fragmented packet, first fragment
1
0
Fragmented packet, following fragments
1
Larger than 0
Fragmented packet, last fragment
0
Larger than 0
This RFC introduces, in MLX5 PMD, the support of matching on the header fields mentioned above.
The matching on M/MF flag, and Fragment Offset=0, is plain and straight forward.
The matching on Fragment Offset > 0 will be specified by range from item.spec=1 to maximal value item.last=(2^13-1).
Following rte_flow update [1], IPv6 item validation and translation will be enhanced, to check the Next Header field,
and look for the fragment extension header to process.
Testpmd code will be updated to support the use of added items and fields.
The command line option to match on IPv6 fragment extension item and it's fields will be added.
[1] http://patches.dpdk.org/patch/66849/
Signed-off-by: Dekel Peled <dekelp@mellanox.com<mailto:dekelp@mellanox.com>>
parent reply other threads:[~2020-03-18 16:50 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <AM4PR05MB346043CD1A77B2204BB92A2AB6F70@AM4PR05MB3460.eurprd05.prod.outlook.com>]
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=AM4PR05MB3460E75E0B52716013BB86C0B6F70@AM4PR05MB3460.eurprd05.prod.outlook.com \
--to=dekelp@mellanox.com \
--cc=asafp@mellanox.com \
--cc=dev@dpdk.org \
--cc=elibr@mellanox.com \
--cc=matan@mellanox.com \
--cc=orika@mellanox.com \
--cc=viacheslavo@mellanox.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 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).