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 6107CA04DD; Wed, 21 Oct 2020 18:28:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 90500A99D; Wed, 21 Oct 2020 18:28:42 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 05D64A99C for ; Wed, 21 Oct 2020 18:28:40 +0200 (CEST) IronPort-SDR: bCN4p72R7cU9dPsB45WaMQINSp8lA4RzGvJyC/kNqXJzIWZlkU9kUAxfQHvqM3iaCU01rL1O+M Oaxtl1K7ADwA== X-IronPort-AV: E=McAfee;i="6000,8403,9780"; a="147253311" X-IronPort-AV: E=Sophos;i="5.77,401,1596524400"; d="scan'208";a="147253311" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Oct 2020 09:28:36 -0700 IronPort-SDR: LJXlwMsQa24LPkOyXcwkYLzpB1ue6sH8gPF0llJN9iX5KQoSej1HNMzhcyRAtw77hmeV1bkuXR K/30qQBO397A== X-IronPort-AV: E=Sophos;i="5.77,401,1596524400"; d="scan'208";a="533590289" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.251.86.101]) ([10.251.86.101]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Oct 2020 09:28:33 -0700 To: Andrew Rybchenko , "Ananyev, Konstantin" , Ray Kinsella , Neil Horman Cc: "dev@dpdk.org" , Thomas Monjalon , Matan Azrad , Olivier Matz , Jerin Jacob References: <20201020120305.1516513-1-ferruh.yigit@intel.com> <89fdc248-2d3b-69ac-e08d-a15a043f23d5@oktetlabs.ru> From: Ferruh Yigit Message-ID: Date: Wed, 21 Oct 2020 17:28:30 +0100 MIME-Version: 1.0 In-Reply-To: <89fdc248-2d3b-69ac-e08d-a15a043f23d5@oktetlabs.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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/2020 4:10 PM, Andrew Rybchenko wrote: > 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). > Not sure if we really need it, I had same thought. The benefit of having it is, user can configure the Rx packet size within the ``rte_eth_dev_configure()`` API, without it user will need to call the ``rte_eth_dev_set_mtu()`` API explicitly, which will add another mandatory call to the device initialization, so I think having this fields simplifies the initialization. Having it has the duplication problem, same thing configured by two different APIs. >>> + 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 >