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 CBFA4A04E7; Mon, 2 Nov 2020 15:04:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 12057C8B0; Mon, 2 Nov 2020 15:04:26 +0100 (CET) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 224ACC8A6 for ; Mon, 2 Nov 2020 15:04:23 +0100 (CET) IronPort-SDR: emkxc908duXeABv8j+NeuCTBiwgr7sD4YiVb/oKLaVRcjFNSUJrlx8bnpbkwOlh7tEF7RlNCo+ a+Oqdjz1r3fA== X-IronPort-AV: E=McAfee;i="6000,8403,9792"; a="253595264" X-IronPort-AV: E=Sophos;i="5.77,445,1596524400"; d="scan'208";a="253595264" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Nov 2020 06:03:14 -0800 IronPort-SDR: lRsWXK4F1bw9tJYuqEq3/Xi/nj58jC2MYdimT8dmXoRmjVijsitgO7kQXEcFh+/2ClBg+tVmjW LCZI0KPKcC3Q== X-IronPort-AV: E=Sophos;i="5.77,445,1596524400"; d="scan'208";a="538030375" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.219.143]) ([10.213.219.143]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Nov 2020 05:58:45 -0800 To: Andrew Rybchenko , SteveX Yang , dev@dpdk.org Cc: konstantin.ananyev@intel.com, beilei.xing@intel.com, wenzhuo.lu@intel.com, bernard.iremonger@intel.com, qiming.yang@intel.com, 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> From: Ferruh Yigit Message-ID: <8721bb8d-e361-f815-257f-08d531e23fba@intel.com> Date: Mon, 2 Nov 2020 13:58:40 +0000 MIME-Version: 1.0 In-Reply-To: <67bb56e7-d12f-d364-1cc4-dfefd20739b0@oktetlabs.ru> Content-Type: text/plain; charset=utf-8; format=flowed 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/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? > 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.