Re: [dpdk-dev] [PATCH v8 2/2] doc: annouce deprecation of jumbo frame flag condition

From: Ferruh Yigit <ferruh.yigit@intel.com>
To: "Yang, SteveX" <stevex.yang@intel.com>,
	"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Thomas Monjalon <thomas@monjalon.net>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	Viacheslav Ovsiienko <viacheslavo@nvidia.com>,
	Matan Azrad <matan@nvidia.com>,
	Bruce Richardson <bruce.richardson@intel.com>
Cc: "Xing, Beilei" <beilei.xing@intel.com>,
	"Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
	"Iremonger, Bernard" <bernard.iremonger@intel.com>,
	"Yang, Qiming" <qiming.yang@intel.com>,
	"mdr@ashroe.eu" <mdr@ashroe.eu>,
	"nhorman@tuxdriver.com" <nhorman@tuxdriver.com>
Subject: Re: [dpdk-dev] [PATCH v8 2/2] doc: annouce deprecation of jumbo frame flag condition
Date: Tue, 24 Nov 2020 17:46:31 +0000	[thread overview]
Message-ID: <1e5d6121-0650-3d48-1482-d15f4a598aff@intel.com> (raw)
In-Reply-To: <DM6PR11MB43625C5CF594BEDC9CE479F7F9110@DM6PR11MB4362.namprd11.prod.outlook.com>

On 11/3/2020 9:07 AM, Yang, SteveX wrote:
> 
> 
>> -----Original Message-----
>> From: Ananyev, Konstantin <konstantin.ananyev@intel.com>
>> Sent: Tuesday, November 3, 2020 12:05 AM
>> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Andrew Rybchenko
>> <andrew.rybchenko@oktetlabs.ru>; Yang, SteveX <stevex.yang@intel.com>;
>> dev@dpdk.org
>> Cc: Xing, Beilei <beilei.xing@intel.com>; Lu, Wenzhuo
>> <wenzhuo.lu@intel.com>; Iremonger, Bernard
>> <bernard.iremonger@intel.com>; Yang, Qiming <qiming.yang@intel.com>;
>> 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 <stevex.yang@intel.com>
>>>>> ---
>>>>>    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.