From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 55C552B87 for ; Wed, 20 Feb 2019 17:02:24 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2019 08:02:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,391,1544515200"; d="scan'208";a="116412952" Received: from istokes-mobl1.ger.corp.intel.com (HELO [10.237.221.152]) ([10.237.221.152]) by orsmga007.jf.intel.com with ESMTP; 20 Feb 2019 08:02:21 -0800 To: "Ananyev, Konstantin" , =?UTF-8?Q?Morten_Br=c3=b8rup?= , Stephen Hemminger Cc: "dev@dpdk.org" , "Mcnamara, John" , "Kovacevic, Marko" , Thomas Monjalon , "Yigit, Ferruh" , Andrew Rybchenko References: <20180905164157.844-1-stephen@networkplumber.org> <98CBD80474FA8B44BF855DF32C47DC35B4265B@smartserver.smartshare.dk> <20190206081107.41c57bad@hermes.lan> <98CBD80474FA8B44BF855DF32C47DC357BD6@smartserver.smartshare.dk> <2601191342CEEE43887BDE71AB977258012413341F@irsmsx105.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC35B42667@smartserver.smartshare.dk> <2601191342CEEE43887BDE71AB9772580124135478@irsmsx105.ger.corp.intel.com> From: Ian Stokes Message-ID: Date: Wed, 20 Feb 2019 16:02:20 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB9772580124135478@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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, 20 Feb 2019 16:02:24 -0000 On 2/7/2019 12:00 PM, Ananyev, Konstantin wrote: > >>> 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 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 > Hi All, with a view to help progress this I've posted an RFC series based on Stephens work and some of the PMD drivers http://mails.dpdk.org/archives/dev/2019-February/124938.html Any feedback welcome Thanks Ian