From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by dpdk.org (Postfix) with ESMTP id 533301B452 for ; Wed, 6 Feb 2019 22:58:30 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2019 22:58:29 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC357BD6@smartserver.smartshare.dk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dpdk-dev] [RFC] ethdev: add min/max MTU to device info Thread-Index: AdS+Np5FFr9S7YhWTKiEQOEQxzo7GgAKi8Mm References: <20180905164157.844-1-stephen@networkplumber.org> <98CBD80474FA8B44BF855DF32C47DC35B4265B@smartserver.smartshare.dk> <20190206081107.41c57bad@hermes.lan> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Stephen Hemminger" Cc: , "John McNamara" , "Marko Kovacevic" , "Thomas Monjalon" , "Ferruh Yigit" , "Andrew Rybchenko" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 21:58:30 -0000 > From: dev on behalf of Stephen Hemminger > On Wed, 6 Feb 2019 14:05:34 +0100 > Morten Br=F8rup wrote: >=20 > > Good work, Stephen. > >=20 > > It should also be documented how PMDs should interpret this MTU. > >=20 > > 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... > >=20 > > 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? >=20 > 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? 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. >=20 > >=20 > > 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? > >=20 >=20 > 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.