DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>
Cc: <dev@dpdk.org>, "Mcnamara, John" <john.mcnamara@intel.com>,
	"Kovacevic, Marko" <marko.kovacevic@intel.com>,
	"Thomas Monjalon" <thomas@monjalon.net>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Andrew Rybchenko" <arybchenko@solarflare.com>
Subject: Re: [dpdk-dev] [RFC] ethdev: add min/max MTU to device info
Date: Thu, 7 Feb 2019 12:10:11 +0100	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35B42667@smartserver.smartshare.dk> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB977258012413341F@irsmsx105.ger.corp.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.

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

  reply	other threads:[~2019-02-07 11:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 16:41 Stephen Hemminger
2018-09-06  5:51 ` Shahaf Shuler
2018-09-06  6:29 ` Andrew Rybchenko
2018-09-06 10:52   ` Stephen Hemminger
2018-11-22  9:58     ` Stokes, Ian
2018-12-19  2:37 ` Thomas Monjalon
2019-01-16 21:30   ` Stephen Hemminger
2019-02-06 13:05 ` Morten Brørup
2019-02-06 16:11   ` Stephen Hemminger
2019-02-06 21:58     ` Morten Brørup
2019-02-07 10:25       ` Ananyev, Konstantin
2019-02-07 11:10         ` Morten Brørup [this message]
2019-02-07 12:00           ` Ananyev, Konstantin
2019-02-20 16:02             ` Ian Stokes
2019-06-24 13:18               ` Nithin Kumar Dabilpuram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=98CBD80474FA8B44BF855DF32C47DC35B42667@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=john.mcnamara@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=marko.kovacevic@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).