From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id A99131B454 for ; 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" To: =?iso-8859-1?Q?Morten_Br=F8rup?= , "Stephen Hemminger" CC: "dev@dpdk.org" , "Mcnamara, John" , "Kovacevic, Marko" , Thomas Monjalon , "Yigit, Ferruh" , "Andrew Rybchenko" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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