From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <konstantin.ananyev@intel.com>
Received: from mga18.intel.com (mga18.intel.com [134.134.136.126])
 by dpdk.org (Postfix) with ESMTP id A99131B454
 for <dev@dpdk.org>; Thu,  7 Feb 2019 11:25:48 +0100 (CET)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga002.jf.intel.com ([10.7.209.21])
 by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 07 Feb 2019 02:25:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.58,343,1544515200"; d="scan'208";a="132258907"
Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159])
 by orsmga002.jf.intel.com with ESMTP; 07 Feb 2019 02:25:46 -0800
Received: from irsmsx105.ger.corp.intel.com ([169.254.7.72]) by
 IRSMSX104.ger.corp.intel.com ([169.254.5.56]) with mapi id 14.03.0415.000;
 Thu, 7 Feb 2019 10:25:43 +0000
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: =?iso-8859-1?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>, "Stephen
 Hemminger" <stephen@networkplumber.org>
CC: "dev@dpdk.org" <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>
Thread-Topic: [dpdk-dev] [RFC] ethdev: add min/max MTU to device info
Thread-Index: AdRFN4K5/8ohluZqSYi41TybH7coywAKi8MmHltWzZA=
Date: Thu, 7 Feb 2019 10:25:43 +0000
Message-ID: <2601191342CEEE43887BDE71AB977258012413341F@irsmsx105.ger.corp.intel.com>
References: <20180905164157.844-1-stephen@networkplumber.org>
 <98CBD80474FA8B44BF855DF32C47DC35B4265B@smartserver.smartshare.dk>
 <20190206081107.41c57bad@hermes.lan>
 <98CBD80474FA8B44BF855DF32C47DC357BD6@smartserver.smartshare.dk>
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC357BD6@smartserver.smartshare.dk>
Accept-Language: en-IE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODRmNzk2ZDItZWVkMi00NzE3LWFkZDYtMzM3YTkxNGZhOWU0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiaGxSZHAxY2didkdieXJmbStZc1pTVWZvTTFYcVwveWlLNVZ5eTNaYzdMcEp4ZCswMFY2M1VHc0lHSm03cTRiVVAifQ==
x-ctpclassification: CTP_NT
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
x-originating-ip: [163.33.239.182]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [RFC] ethdev: add min/max MTU to device info
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 10:25:49 -0000



>=20
> > From: dev on behalf of Stephen Hemminger
> > On Wed, 6 Feb 2019 14:05:34 +0100
> > Morten Br=F8rup <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 th=
is, but that's as far as it goes...
> > >
> > > But how about frames with even larger headers, e.g. 4 MPLS labels mak=
es 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.
>=20
> 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 s=
ize 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 t=
he special case of exactly one VLAN tag is free?

Can we introduce new function at ehtdev API to query PMD frame size based o=
n MTU?
Something like: rte_ethdev_mtu_to_frame_size(uint32_t mtu);
Provide default behavior and allow PMD to overwrite it?
Konstantin=20

>=20
> I wish details like this were documented... for the benefit of both PMD d=
evelopers and DPDK users. Which is why I CC'ed the
> Documentatation and Ethernet API maintainers.
>=20
> It reminds me of the previous discussion about some Ethernet PMD's not pa=
dding 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).
>=20
> We all know that the devil is in the details! Which is why documenting su=
ch details is important.
>=20
> Outside the DPDK core libraries, the Ethernet PMDs are probably the close=
st to the DPDK core you are going to get.
> The core libraries have a bunch of test cases. Perhaps there should be mo=
re PMD test cases.
>=20
> >
> > >
> > > According to Wikipedia (https://en.wikipedia.org/wiki/Maximum_transmi=
ssion_unit), MTU describes the maximum payload size, and is
> not tied to the maximum frame size. However, the Linux kernel (at least t=
he older versions I have been working with) incorrectly ties the
> MTU directly to the maximum frame size, so the MTU has to increased to su=
pport 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.
>=20
> Yes. This is also not obvious, although the name Maximum Transmission Uni=
t strongly indicates that it does not apply to ingress. It took me
> by surprise a few years ago while working with the Linux kernel.
>=20
>=20
>=20
>=20