>
> > From: dev on behalf of Stephen Hemminger
> > On Wed, 6 Feb 2019 14:05:34 +0100
> > Morten Brørup <[email protected]> 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
>
> I wish details like this were documented... for the benefit of both PMD
> developers and DPDK users. Which is why I CC'ed the
> Documentatation and Ethernet API maintainers.
>
> It reminds me of the previous discussion about some Ethernet PMD's not
> padding to minimum Ethernet frame size... DPDK users expecting a
> certain behavior based on Linux/BSD behavior, but not documented, so the PMD
> developers were unaware (or possibly disagreed).
>
> We all know that the devil is in the details! Which is why documenting such
> details is important.
>
> Outside the DPDK core libraries, the Ethernet PMDs are probably the closest
> to the DPDK core you are going to get.
> The core libraries have a bunch of test cases. Perhaps there should be more
> PMD test cases.
>
> >
> > >
> > > According to Wikipedia
> > > (https://en.wikipedia.org/wiki/Maximum_transmission_unit), MTU describes
> > > the maximum payload size, and is
> not tied to the maximum frame size. However, the Linux kernel (at least the
> older versions I have been working with) incorrectly ties the
> MTU directly to the maximum frame size, so the MTU has to increased to
> support larger headers (e.g. QinQ or an MPLS stack). Do none, all
> or some DPDK PMDs suffer from the same error?
> > >
> >
> > Maximum Transmission Unit and Maximum Receive Unit (MRU) are separate. On
> > most hardware they are the same but
> > there is variation. Some hardware can receive larger sizes than MTU and
> > some have max receive length register.
>
> Yes. This is also not obvious, although the name Maximum Transmission Unit
> strongly indicates that it does not apply to ingress. It took me
> by surprise a few years ago while working with the Linux kernel.
>
>
>
>
