[dpdk-dev] [RFC] ethdev: add min/max MTU to device info

Morten Brørup mb at smartsharesystems.com
Thu Feb 7 12:10:11 CET 2019


> From: dev [mailto:dev-bounces at 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 <mb at 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.

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

-Morten


More information about the dev mailing list