From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D7D4CA0524; Fri, 27 Nov 2020 13:19:49 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EDFD9C930; Fri, 27 Nov 2020 13:19:47 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by dpdk.org (Postfix) with ESMTP id F2A0DC92A for ; Fri, 27 Nov 2020 13:19:45 +0100 (CET) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 249D07F572; Fri, 27 Nov 2020 15:19:44 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 249D07F572 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1606479584; bh=EKqAmRpk3LqcH65njjZshHW0eKhkaNsvP+/0CWB0evI=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Zd75BM7aHshW/MUiMI/BH7he34jYveO8lokWwQDqvoTs4gRnhpfciPWZSW/i7YDy8 3Ist6JLrusiDgkyjSmrAtFgTJ4mgkH5mc4V/cKjVcsKziRovFYBKooiZOAoJXSl+a3 jwcuWACaAliriyxatFD5IC69AEACKw2eR7HmXRIo= To: Ferruh Yigit , "Yang, SteveX" , "Ananyev, Konstantin" , "dev@dpdk.org" , Thomas Monjalon , "Zhang, Qi Z" , Ajit Khaparde , "jerinj@marvell.com" , Viacheslav Ovsiienko , Matan Azrad , Bruce Richardson Cc: "Xing, Beilei" , "Lu, Wenzhuo" , "Iremonger, Bernard" , "Yang, Qiming" , "mdr@ashroe.eu" , "nhorman@tuxdriver.com" References: <20201028030334.30300-1-stevex.yang@intel.com> <20201102085234.72779-1-stevex.yang@intel.com> <20201102085234.72779-3-stevex.yang@intel.com> <67bb56e7-d12f-d364-1cc4-dfefd20739b0@oktetlabs.ru> <8721bb8d-e361-f815-257f-08d531e23fba@intel.com> <1e5d6121-0650-3d48-1482-d15f4a598aff@intel.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Fri, 27 Nov 2020 15:19:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <1e5d6121-0650-3d48-1482-d15f4a598aff@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v8 2/2] doc: annouce deprecation of jumbo frame flag condition 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 11/24/20 8:46 PM, Ferruh Yigit wrote: > On 11/3/2020 9:07 AM, Yang, SteveX wrote: >>> -----Original Message----- >>> From: Ananyev, Konstantin >>> Sent: Tuesday, November 3, 2020 12:05 AM >>> To: Yigit, Ferruh ; Andrew Rybchenko >>> ; Yang, SteveX ; >>> dev@dpdk.org >>> Cc: Xing, Beilei ; Lu, Wenzhuo >>> ; Iremonger, Bernard >>> ; Yang, Qiming ; >>> mdr@ashroe.eu; nhorman@tuxdriver.com >>> Subject: RE: [dpdk-dev] [PATCH v8 2/2] doc: annouce deprecation of jumbo >>> frame flag condition >>> >>>> On 11/2/2020 1:18 PM, Andrew Rybchenko wrote: >>>>> On 11/2/20 11:52 AM, SteveX Yang wrote: >>>>>> Annouce to replace 'RTE_ETHER_MAX_LEN' with 'RTE_ETHER_MTU' as type >>>>>> condition of jumbo frame. Involved scopes: >>>>>> - rte_ethdev; >>>>>> - app, e.g.: test-pmd, test-eventdev; >>>>>> - examples, e.g.: ipsec-secgw, l3fwd, vhost; >>>>>> - net PMDs which support VLAN tag(s) within overhead, e.g.: i40e, >>>>>> ixgbe; >>>>>> >>>>>> Signed-off-by: SteveX Yang >>>>>> --- >>>>>>    doc/guides/rel_notes/deprecation.rst | 12 ++++++++++++ >>>>>>    1 file changed, 12 insertions(+) >>>>>> >>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst >>>>>> b/doc/guides/rel_notes/deprecation.rst >>>>>> index 2e082499b..fae139f01 100644 >>>>>> --- a/doc/guides/rel_notes/deprecation.rst >>>>>> +++ b/doc/guides/rel_notes/deprecation.rst >>>>>> @@ -138,6 +138,18 @@ Deprecation Notices >>>>>>      will be limited to maximum 256 queues. >>>>>>      Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be removed. >>>>>> +* ethdev: Offload flag ``DEV_RX_OFFLOAD_JUMBO_FRAME`` will be set >>>>>> +according to >>>>>> +  ``RTE_ETHER_MTU`` in next release. Currently, the jumbo frame >>>>>> +uses the >>>>>> +  ``RTE_ETHER_MAX_LEN`` as boundary condition. When the MTU (1500) >>>>>> +set, the >>>>>> +  frame type of rx packet will be different if used different >>>>>> +overhead, it will >>>>>> +  cause the consistency issue. Hence, using fixed value >>>>>> +``RTE_ETHER_MTU`` can >>>>>> +  avoid this issue. >>>>>> +  Following scopes will be changed: >>>>>> +  - ``rte_ethdev`` >>>>>> +  - ``app``, e.g.: ``test-pmd``, ``test-eventdev``; >>>>>> +  - ``examples``, e.g.: ``ipsec-secgw``, ``l3fwd``, ``vhost``; >>>>>> +  - net PMDs which support VLAN tag(s) within overhead, e.g.: >>>>>> +``i40e``; >>>>>> + >>>>>>    * cryptodev: support for using IV with all sizes is added, J0 >>>>>> still can >>>>>>      be used but only when IV length in following structs >>>>>> ``rte_crypto_auth_xform``, >>>>>>      ``rte_crypto_aead_xform`` is set to zero. When IV length is >>>>>> greater or equal >>>>>> >>>>> >>>>> If so, what's the point to have the offload? May be just deprecate >>>>> and later remove it? >>>>> >>> >>> Same thought actually, can we remove DEV_RX_OFFLOAD_JUMBO_FRAME >>> flag completely? >>> PMD can decide based on provided MTU size does segmentation, etc. is >>> needed. >>> >> >> Yes, it seems can be removed when base on MTU size. >> I've checked related code of using DEV_RX_OFFLOAD_JUMBO_FRAME. >> Most of them use for checking boundary of max packet length and set >> 'dev->data->mtu'. >> > > Steve already sent the RFC for above fix: > https://patches.dpdk.org/patch/84486/ > > We can consider removing 'DEV_RX_OFFLOAD_JUMBO_FRAME' but anyway it is > for 21.11. > > This deprecation notice is required to fix the ethdev in next release, > as in the above RFC. > > I cc'ed a few more relevant people, can you please review this > deprecation notice. > > Thanks, > ferruh > > >>>> >>>> Above just changes the condition of what is called jumbo frame, nothing more. >>>> >>>> ethdev assumes max frame size (without jumbo frame support) can be >>>> 'RTE_ETHER_MAX_LEN' (1518) >>>> >>>> But a PMD can support double VLAN, and it can have RTE_ETHER_MAX_LEN + >>>> 8 bytes frame size and still may not support jumbo frame. >>>> >>>> In that case ethdev overwrites the frame size as RTE_ETHER_MAX_LEN, >>>> and this will reduce the supported MTU to 1492 (instead of expected >>>> 1500). >>>> Above deprecation notice is to fix this. My problem with the deprecation notice is that I don't actually understand what will be done to address it. The idea explained by Ferruh in details makes sense. But I don't understand how the deprecation notice description corresponding to it. I read "Offload flag ``DEV_RX_OFFLOAD_JUMBO_FRAME`` will be set.." as an enforcement of the offload flag based on other parameters. I think it is incorrect. Or I still don't understand something... Looking at [1] adds more confusion since I don't understand why we care about dev_conf->rxmode.max_rx_pkt_len when JUMBO_FRAME offload is disabled. As far as I know JUMBO_FRAME offload enable means that driver should take a look at it and apply. Otherwise, just ignore it. [1] http://lxr.dpdk.org/dpdk/v20.08/source/lib/librte_ethdev/rte_ethdev.c#L1345