On 2/7/2019 12:00 PM, Ananyev, Konstantin wrote:
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev,
Konstantin
From: dev on behalf of Stephen Hemminger
On Wed, 6 Feb 2019 14:05:34 +0100
Morten Brørup <m...@smartsharesystems.com> wrote:
Good work, Stephen.
It should also be documented how PMDs should interpret this MTU.
Obviously, a VLAN tagged Ethernet frame grows from 1518 to 1522
bytes incl. header and CRC, and should be allowed with an Ethernet
MTU of 1500 bytes. There's even a #define ETHER_MAX_VLAN_FRAME_LEN
for this, but that's as far as it goes...
But how about frames with even larger headers, e.g. 4 MPLS labels
makes a frame 16 bytes longer, i.e. it grows from 1518 to 1534
bytes... is such a frame acceptable with an MTU of 1500 bytes?
No. According to standard practice in Linux and FreeBSD, only the
first VLAN tag is free.
After that any other headers count against MTU.
Thank you for the insights. Just to clarify:
1 VLAN tag is allowed for free.
But on order to support two VLAN tags, the MTU must be increased by
the size of one VLAN tag, because the first VLAN tag is free?
Or must the MTU be increased by the size of two VLAN tags, because
only the special case of exactly one VLAN tag is free?
Can we introduce new function at ehtdev API to query PMD frame size
based on MTU?
Something like: rte_ethdev_mtu_to_frame_size(uint32_t mtu);
Provide default behavior and allow PMD to overwrite it?
Konstantin
This assumes that the Layer 2 headers are fixed size. If you add e.g. an MPLS
stack to the packet, the number of MPLS labels can vary, and
thus the size of the Layer 2 headers varies with each packet.
If all this extra stuff (MPLS labels, etc.) is added by SW - then yes, it will
be SW (upper layer) to take account about such overhead
and it would be accounted by PMD frame-size caluclation.
If these fields would be added by HW/PMD - then it would be PMD responsibility
to take these extras into account when calculating
frame size.
It is a problem if Layer 3/4 offload features make assumptions about the Layer
3/4 MTUs based on the Layer 2 MTU without considering the
size of the actual Ethernet headers of each packet, but simply assume that the
Ethernet header size is fixed.
It might currently be calculated correctly for untagged or single VLAN tagged
packets (assuming the VLAN tag is not already part of the
packet data, but is set in the mbuf for the NIC to add).
That could be a default behavior for that function.
Konstantin
Hi All,
with a view to help progress this I've posted an RFC series based on
Stephens work and some of the PMD drivers
http://mails.dpdk.org/archives/dev/2019-February/124938.html
Any feedback welcome
Thanks
Ian
