DPDK patches and discussions
 help / color / mirror / Atom feed
From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: Shahaf Shuler <shahafs@mellanox.com>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>,
	Olivier Matz <olivier.matz@6wind.com>,
	Tomasz Kulasek <tomaszx.kulasek@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change on ethdev
Date: Tue, 9 May 2017 15:40:04 +0200	[thread overview]
Message-ID: <20170509134004.GO16218@6wind.com> (raw)
In-Reply-To: <20170501065812.5185-1-shahafs@mellanox.com>

On Mon, May 01, 2017 at 09:58:12AM +0300, Shahaf Shuler wrote:
> This is an ABI change notice for DPDK 17.08 in librte_ether
> about changes in rte_eth_txmode structure.
> 
> Currently Tx offloads are enabled by default, and can be disabled
> using ETH_TXQ_FLAGS_NO* flags. This behaviour is not consistent with
> the Rx side where the Rx offloads are disabled by default and enabled
> according to bit field in rte_eth_rxmode structure.
> 
> The proposal is to disable the Tx offloads by default, and provide
> a way for the application to enable them in rte_eth_txmode structure.
> Besides of making the Tx configuration API more consistent for
> applications, PMDs will be able to provide a better out of the
> box performance.
> Finally, as part of the work, the ETH_TXQ_FLAGS_NO* will
> be superseded as well.
> 
> Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>

Basically, TX mbuf flags like TSO and checksum offloads won't have to be
honored by PMDs unless applications request them first while configuring the
device, just like RX offloads.

Considering more and more TX offloads will be added over time, I do not
think expecting them all to be enabled by default is sane. There will always
be an associated software cost in PMDs, and this solution allows
applications to selectively enable them as needed for maximum performance.

Konstantin/Olivier/Tomasz, I do not want to resume the thread about
tx_prepare(), however this could provide an alternative means to benefit
from improved performance when applications do not need TSO (or any other
offload for that matter), while adding consistency to device configuration.

What's your opinion?

In any case I'm fine with this change:

Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>

> ---
>  doc/guides/rel_notes/deprecation.rst | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index a3e7c720c..0920b4766 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -81,3 +81,11 @@ Deprecation Notices
>  
>    - ``rte_crpytodev_scheduler_mode_get``, replaced by ``rte_cryptodev_scheduler_mode_get``
>    - ``rte_crpytodev_scheduler_mode_set``, replaced by ``rte_cryptodev_scheduler_mode_set``
> +
> +* ethdev: in 17.08 ABI changes are planned:
> +  Tx offloads will no longer be enabled by default.
> +  Instead, the ``rte_eth_txmode`` structure will be extended with bit field to enable
> +  each Tx offload.
> +  Besides of making the Rx/Tx configuration API more consistent for the
> +  application, PMDs will be able to provide a better out of the box performance.
> +  as part of the work, ``ETH_TXQ_FLAGS_NO*`` will be superseded as well.
> -- 
> 2.12.0
> 

-- 
Adrien Mazarguil
6WIND

  parent reply	other threads:[~2017-05-09 13:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-01  6:58 Shahaf Shuler
2017-05-09 10:24 ` Shahaf Shuler
2017-05-09 13:40 ` Adrien Mazarguil [this message]
2017-05-09 17:04   ` Jerin Jacob
2017-05-10 23:17     ` Thomas Monjalon
2017-05-09 13:49 ` Ferruh Yigit
2017-05-09 16:55   ` Shahaf Shuler
2017-05-09 18:09 ` Ananyev, Konstantin
2017-05-10 14:29 ` Bruce Richardson

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=20170509134004.GO16218@6wind.com \
    --to=adrien.mazarguil@6wind.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    --cc=olivier.matz@6wind.com \
    --cc=shahafs@mellanox.com \
    --cc=tomaszx.kulasek@intel.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).