All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matan Azrad <matan@nvidia.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
	Ray Kinsella <mdr@ashroe.eu>,
	"Neil Horman" <nhorman@tuxdriver.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>,
	NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	"Olivier Matz" <olivier.matz@6wind.com>,
	Jerin Jacob <jerinj@marvell.com>
Subject: Re: [dpdk-dev] [RFC v2] doc: announce max Rx packet len field deprecation
Date: Thu, 26 Nov 2020 18:30:56 +0000	[thread overview]
Message-ID: <MW2PR12MB24929A1E8FA2C4A2619AAE9ADFF90@MW2PR12MB2492.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20201124173628.1057348-1-ferruh.yigit@intel.com>



Hi

Looks very good direction - it will do some order here.

Will be also good to define what is MTU exactly:
Maximum Rx packet size \ Maximum Tx packet size \ both?
Is it include L2\L3 headers? Vlan?
How is it going together with ``uint32_t max_lro_pkt_size``?

Also when should the user configure DEV_RX_OFFLOAD_SCATTER?

Matan

From: Ferruh Yigit
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> Cc: Thomas Monjalon <thomas@monjalon.net>
> Cc: Andrew Rybchenko <arybchenko@solarflare.com>
> Cc: Konstantin Ananyev <konstantin.ananyev@intel.com>
> Cc: Matan Azrad <matan@nvidia.com>
> Cc: Olivier Matz <olivier.matz@6wind.com>
> Cc: Jerin Jacob <jerinj@marvell.com>
> 
> 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


  parent reply	other threads:[~2020-11-26 18:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-20 12:03 [dpdk-dev] [RFC] doc: announce max Rx packet len field deprecation Ferruh Yigit
2020-10-21 10:18 ` Ananyev, Konstantin
2020-10-21 15:10   ` Andrew Rybchenko
2020-10-21 16:28     ` Ferruh Yigit
2020-10-21 12:40 ` Kinsella, Ray
2020-11-24 17:36 ` [dpdk-dev] [RFC v2] " Ferruh Yigit
2020-11-24 17:47   ` Ajit Khaparde
2020-11-26 11:28   ` Andrew Rybchenko
2020-11-26 12:34     ` Ferruh Yigit
2020-11-27 18:38       ` Thomas Monjalon
2020-11-26 18:30   ` Matan Azrad [this message]
2020-11-27  9:37     ` [dpdk-dev] [RFC v2] doc: announce max Rx packet len fielddeprecation Morten Brørup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MW2PR12MB24929A1E8FA2C4A2619AAE9ADFF90@MW2PR12MB2492.namprd12.prod.outlook.com \
    --to=matan@nvidia.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerinj@marvell.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=mdr@ashroe.eu \
    --cc=nhorman@tuxdriver.com \
    --cc=olivier.matz@6wind.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.