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 80E98A04E7; Mon, 2 Nov 2020 14:18:53 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3D3A5C86C; Mon, 2 Nov 2020 14:18:52 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by dpdk.org (Postfix) with ESMTP id 44D2AC86A for ; Mon, 2 Nov 2020 14:18:51 +0100 (CET) Received: from [192.168.1.192] (unknown [188.242.181.57]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id D7EA67F609; Mon, 2 Nov 2020 16:18:49 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru D7EA67F609 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1604323130; bh=01Cph4jF+eiPeO62dEZNACzhtYEG89XQrjbc3lYZJwc=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Ij8iAbvvQ76eroXrl3MtOcTy8q6LTk7StdVliZLRnLe3AQYky+jv1FM/nAiCWZq8g 0kkIGbuungfcqprBnmDySt64qx1JLdQ+xPdAfjHG96A3bOIgtPxmi4nhMUZFUpqcSZ f6BQ8Z/TkBi6ZXtaP4xW5LixeFp0VICCKIjvpw7c= To: SteveX Yang , dev@dpdk.org Cc: ferruh.yigit@intel.com, 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> From: Andrew Rybchenko Message-ID: <67bb56e7-d12f-d364-1cc4-dfefd20739b0@oktetlabs.ru> Date: Mon, 2 Nov 2020 16:18:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <20201102085234.72779-3-stevex.yang@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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/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?