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 C4A9EA04DD; Wed, 21 Oct 2020 17:10:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1C5EAA9FF; Wed, 21 Oct 2020 17:10:30 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by dpdk.org (Postfix) with ESMTP id 78827A9FA for ; Wed, 21 Oct 2020 17:10:27 +0200 (CEST) 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) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id DAF677F676; Wed, 21 Oct 2020 18:10:25 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru DAF677F676 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1603293026; bh=FFPyFfPiY3K8dOSTCKl1AnkJaFKosVXQd6Rex6xf7Q4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=oPSKHAHSluxpudi2i8WcMaBxa1tRImfIqkANL5f/ls4ZrfXVsSq0rbAa2TCaRI1Ni lPNUnxNlBogkQUMCedU2H8QhoQxXvJVjzwqoMBmaYZTgVEnbvGaUsVBenx4YwuEua/ GmJZj2ytCbsoqU49YcMtfsrZytaouky6gGcC97u4= To: "Ananyev, Konstantin" , "Yigit, Ferruh" , Ray Kinsella , Neil Horman Cc: "dev@dpdk.org" , Thomas Monjalon , Matan Azrad , Olivier Matz , Jerin Jacob References: <20201020120305.1516513-1-ferruh.yigit@intel.com> From: Andrew Rybchenko Message-ID: <89fdc248-2d3b-69ac-e08d-a15a043f23d5@oktetlabs.ru> Date: Wed, 21 Oct 2020 18:10:25 +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: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC] doc: announce max Rx packet len field deprecation 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 10/21/20 1:18 PM, Ananyev, Konstantin wrote: > > >> Signed-off-by: Ferruh Yigit >> --- >> Cc: Thomas Monjalon >> Cc: Andrew Rybchenko >> Cc: Konstantin Ananyev >> Cc: Matan Azrad >> Cc: Olivier Matz >> Cc: Jerin Jacob >> --- >> doc/guides/rel_notes/deprecation.rst | 25 +++++++++++++++++++++++++ >> 1 file changed, 25 insertions(+) >> >> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst >> index 8ceb385141..d4a31392d3 100644 >> --- a/doc/guides/rel_notes/deprecation.rst >> +++ b/doc/guides/rel_notes/deprecation.rst >> @@ -149,6 +149,31 @@ Deprecation Notices >> will be limited to maximum 256 queues. >> Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be removed. >> >> +* ethdev: In ``struct rte_eth_rxmode``, ``uint32_t max_rx_pkt_len`` will be >> + replaced by a new ``uint32_t mtu`` in v21.11. > Probably no point to keep mtu value in rte_eth_rxmode. > Better to move it to rte_eth_conf. > Apart from that: +1 for this change. > Acked-by: Konstantin Ananyev Do we really need the field in either rte_eth_rxmode or rte_eth_conf? What's the point of duplication? We have dedicated API to get/set which could be called in stopped state, set value saved in data->mtu and used by the driver at start up and Rx queues setup (to check scatter vs data room in mbuf consistency). >> + The new ``mtu`` field will be used to configure the initial device MTU via >> + ``rte_eth_dev_configure()`` API. >> + Later MTU can be changed by ``rte_eth_dev_set_mtu()`` API as done now. >> + The existing ``(struct rte_eth_dev)->data->mtu`` variable will be used to store >> + the configured ``mtu`` value, >> + and this new ``(struct rte_eth_dev)->data->dev_conf.rxmode.mtu`` variable will >> + be used to store the user configuration request. >> + Unlike ``max_rx_pkt_len``, which was valid only when ``JUMBO_FRAME`` enabled, >> + ``mtu`` field will be always valid. >> + When ``mtu`` config is not provided by the application, default ``RTE_ETHER_MTU`` >> + value will be used. >> + Driver is responsible from updating ``(struct rte_eth_dev)->data->mtu`` after MTU >> + set successfully, either by ``rte_eth_dev_configure()`` or ``rte_eth_dev_set_mtu()``. >> + >> + Application may need to configure device for a specific Rx packet size, like for >> + cases ``DEV_RX_OFFLOAD_SCATTER`` is not supported and device received packet size >> + can't be bigger than Rx buffer size. >> + To cover these cases application needs to know the device packet overhead to be >> + able to calculate the ``mtu`` corresponding to a Rx buffer size, for this >> + ``(struct rte_eth_dev_info).max_rx_pktlen`` will be kept, >> + the device packet overhead can be calculated as: >> + ``(struct rte_eth_dev_info).max_rx_pktlen - (struct rte_eth_dev_info).max_mtu`` >> + >> * 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 >> -- >> 2.26.2