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

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> > From: dev [mailto:dev-bounces@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@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