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 58681A04DB; Tue, 24 Nov 2020 18:47:39 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 355BCC93C; Tue, 24 Nov 2020 18:47:38 +0100 (CET) Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) by dpdk.org (Postfix) with ESMTP id 3D03BC926 for ; Tue, 24 Nov 2020 18:47:36 +0100 (CET) Received: by mail-oi1-f194.google.com with SMTP id h3so1131806oie.8 for ; Tue, 24 Nov 2020 09:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dwp7iJZxSfk92FkjZFcBZuI9MShqoWVTFMi4RD13k9w=; b=DsJMo+Gu1O/8H+4Qw4rBZ1Ofq8YU9ZwYe1Of3/GFXhYydzLN6ZeALrqMsgOQ70Q+pQ kD3qW5Y6nynuTJ8rzA6ZafD92PQO2lMx1U7xJ9dovDauvxntmtxhmkgmyRmj+pJ+ruu/ WTAiyhF8qpQFmfppgI3wTarnf66CV8NNMT7VQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dwp7iJZxSfk92FkjZFcBZuI9MShqoWVTFMi4RD13k9w=; b=U4GnK9VnU7YKdUaWLJbTX5lG1JvUP9bg0OMEjbiYkbMPQUZLF+I1GQqLM9UFEM59yW eMoL7Yisn4dMsnBaHjbE56bEnhYy9tzMg1yEmdW8IBef/m9BmwkgaQrFeraM8M31JRti R3jVhAVtQdHBLMiLFBsXAO9t4ZAr4dp6enSGaOpWIzvKlSaA9DMI81IYmNUcmD+eoF+m vS1RHB+EMTGEapDALI1uKXPrgISiM4dik4gXwj/JAa0wLGMf5LoPmI6E0j3ZqOfRpdBm 6+AOlMmo3WMJCtpaKYEdgh6TeIEB6xT4lDZ3v9S6j0HralxLXjUdOk3AjKNKYgPck00T 5YHA== X-Gm-Message-State: AOAM530hipTz0h6sKVa3g93/0A0r6abcn3JI+HNy/UZ+MnpVESXgqzPx tnIsyqzd7JsqlLFdb21StTvvaVei+RG0M2FzqQhmlA== X-Google-Smtp-Source: ABdhPJyQIwOSIBdirZyhJv8Px/QbuBFcc2xiaT7Zt0kUBk5dSlvbYGjD8d7zDiCUsX3CTpi1NDB9EQ1PtJ+fa5fy4K4= X-Received: by 2002:aca:5a41:: with SMTP id o62mr3526965oib.179.1606240054491; Tue, 24 Nov 2020 09:47:34 -0800 (PST) MIME-Version: 1.0 References: <20201020120305.1516513-1-ferruh.yigit@intel.com> <20201124173628.1057348-1-ferruh.yigit@intel.com> In-Reply-To: <20201124173628.1057348-1-ferruh.yigit@intel.com> From: Ajit Khaparde Date: Tue, 24 Nov 2020 09:47:18 -0800 Message-ID: To: Ferruh Yigit Cc: Ray Kinsella , Neil Horman , dpdk-dev , Konstantin Ananyev , Thomas Monjalon , Andrew Rybchenko , Matan Azrad , Olivier Matz , Jerin Jacob Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC v2] 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 Tue, Nov 24, 2020 at 9:36 AM Ferruh Yigit wrote: > > Signed-off-by: Ferruh Yigit > Acked-by: Konstantin Ananyev Acked-by: Ajit Khaparde > --- > Cc: Thomas Monjalon > Cc: Andrew Rybchenko > Cc: Konstantin Ananyev > Cc: Matan Azrad > Cc: Olivier Matz > Cc: Jerin Jacob > > v2: > * ``uint32_t mtu`` moved to ``struct rte_eth_conf`` > * The "Driver is responsible from updating ``(struct > rte_eth_dev)->data->mtu``" updated because ethdev layer also can do > this. The intention there was both APIs should update the variable. > > Another open question is from Andrew, if we can remove the ``uint32_t > max_rx_pkt_len`` completely from the ``rte_eth_dev_configure()``. > This may force applications to have one more additional > ``rte_eth_dev_set_mtu()`` call for device initialization, but if > applications are OK with the default values most of times, agree that > removing is easier solution, please comment. > --- > 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 96986fabd598..73e43581d615 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -88,6 +88,31 @@ Deprecation Notices > will be limited to maximum 256 queues. > Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be removed. > > +* ethdev: ``uint32_t max_rx_pkt_len`` field of ``struct rte_eth_rxmode``, will be > + replaced by a new ``uint32_t mtu`` field of ``struct rte_eth_conf`` in v21.11. > + 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.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. > + ``(struct rte_eth_dev)->data->mtu`` should be updated after MTU set successfully, > + either by ``rte_eth_dev_configure()`` or ``rte_eth_dev_set_mtu()``. > + > + An 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 an 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`` > + > * sched: To allow more traffic classes, flexible mapping of pipe queues to > traffic classes, and subport level configuration of pipes and queues > changes will be made to macros, data structures and API functions defined > -- > 2.26.2 >