DPDK patches and discussions
 help / color / mirror / Atom feed
From: Morten Brørup <mb@smartsharesystems.com>
To: "Matan Azrad" <matan@nvidia.com>,
	"Ferruh Yigit" <ferruh.yigit@intel.com>,
	"Ray Kinsella" <mdr@ashroe.eu>,
	"Neil Horman" <nhorman@tuxdriver.com>,
	"Yong Wang" <yongwang@vmware.com>
Cc: <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 fielddeprecation
Date: Fri, 27 Nov 2020 10:37:40 +0100
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C61454@smartserver.smartshare.dk> (raw)
In-Reply-To: <MW2PR12MB24929A1E8FA2C4A2619AAE9ADFF90@MW2PR12MB2492.namprd12.prod.outlook.com>

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Matan Azrad
> Sent: Thursday, November 26, 2020 7:31 PM
> 
> 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?

If we cannot find a use case requiring different RX and TX packet size limits, I prefer combining them into one. And in this case, "mtu" (Max TRANSMISSION Unit) is not the optimal name.

Furthermore, the conventional use of "MTU" does not count the L2 headers.

> Is it include L2\L3 headers? Vlan?

I once proposed that it should count what goes on the wire, i.e. including L2 and any VLAN headers. But instead, it was decided to mimic what Linux does: Do not count single VLAN headers, but do count double VLAN headers. I don't know if double VLAN headers only count one of the VLAN headers or both. And I don't know if single VLAN headers are counted if VLAN stripping/appending is disabled.

In other words: Matan has a good point here... It should be well defined (and well documented)!

> 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``
> > +

Please note that the vmxnet3 driver behaves different that other NIC drivers regarding when it can be configured in Linux. The interface needs to be running before it accepts many of the configuration parameters. I don't know if it behaves similarly in DPDK.

I have CC'ed the vmxnet3 maintainer, Yong Wang, in case VMware has an opinion regarding this RFC.

> >  * 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
> 


      reply	other threads:[~2020-11-27  9:37 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
2020-11-27  9:37     ` Morten Brørup [this message]

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=98CBD80474FA8B44BF855DF32C47DC35C61454@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerinj@marvell.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=matan@nvidia.com \
    --cc=mdr@ashroe.eu \
    --cc=nhorman@tuxdriver.com \
    --cc=olivier.matz@6wind.com \
    --cc=thomas@monjalon.net \
    --cc=yongwang@vmware.com \
    /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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git