> > 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
