From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: Shahaf Shuler <shahafs@mellanox.com>,
Konstantin Ananyev <konstantin.ananyev@intel.com>,
Olivier Matz <olivier.matz@6wind.com>,
Tomasz Kulasek <tomaszx.kulasek@intel.com>,
dev@dpdk.org
Subject: Re: [PATCH] doc: announce ABI change on ethdev
Date: Tue, 9 May 2017 22:34:13 +0530 [thread overview]
Message-ID: <20170509170412.GA14727@jerin> (raw)
In-Reply-To: <20170509134004.GO16218@6wind.com>
-----Original Message-----
> Date: Tue, 9 May 2017 15:40:04 +0200
> 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
>
> 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>
Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
next prev parent reply other threads:[~2017-05-09 17:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-01 6:58 [PATCH] doc: announce ABI change on ethdev Shahaf Shuler
2017-05-09 10:24 ` Shahaf Shuler
2017-05-09 13:40 ` Adrien Mazarguil
2017-05-09 17:04 ` Jerin Jacob [this message]
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=20170509170412.GA14727@jerin \
--to=jerin.jacob@caviumnetworks.com \
--cc=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 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.