From: Shahaf Shuler <shahafs@mellanox.com>
To: Shahaf Shuler <shahafs@mellanox.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] [RFC PATCH 0/4] ethdev new offloads API
Date: Wed, 23 Aug 2017 06:39:02 +0000 [thread overview]
Message-ID: <VI1PR05MB3149686E969483730AA38EBCC3850@VI1PR05MB3149.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <cover.1502096064.git.shahafs@mellanox.com>
Hi,
I would like to get some inputs on the below.
This is a big (and important) work which I want to include on 17.11. I need to understand the current approach is acceptable before I continue.
Monday, August 7, 2017 1:54 PM, Shahaf Shuler:
> Tx offloads configuration is per queue. 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
> configuration is per port. Rx offloads are disabled by default and enabled
> according to bit field in rte_eth_rxmode structure.
>
> Moreover, considering more Tx and Rx offloads will be added over time, the
> cost of managing them all inside the PMD will be tremendous, as the PMD
> will need to check the matching for the entire offload set for each mbuf it
> handles.
> In addition, on the current approach each Rx offload added breaks the ABI
> compatibility as it requires to add entries to existing bit-fields.
>
> The RFC address above issues by defining a new offloads API.
> With the new API, Tx and Rx offloads configuration is per queue.
> The offloads are disabled by default. Each offload can be enabled or disabled
> using the existing DEV_TX_OFFLOADS_* or DEV_RX_OFFLOADS_* flags.
> Such API will enable to easily add or remove offloads, without breaking the
> ABI compatibility.
>
> The new API does not have an equivalent for the below Tx flags:
>
> * ETH_TXQ_FLAGS_NOREFCOUNT
> * ETH_TXQ_FLAGS_NOMULTMEMP
>
> The reason is that those flags are not to manage offloads, rather some
> guarantee from application on the way it uses mbufs, therefore could not be
> present as part of DEV_TX_OFFLOADS_*.
> Such flags are useful only for benchmarks, and therefore provide a non-
> realistic
> performance for DPDK customers using simple benchmarks for evaluation.
> Leveraging the work being done in this series to clean up those flags.
>
> In order to provide a smooth transition between the APIs the following
> actions were taken:
> * The old offloads API is kept for the meanwhile.
> * New capabilities were added for PMD to advertize it has moved to the
> new
> offloads API.
> * Helper function which copy from old to new API and vice versa were
> added to ethdev,
> enabling the PMD to support only one of the APIs, and the application to
> move to
> the new API regardless the underlying device and without extra branching.
>
> Shahaf Shuler (4):
> ethdev: rename Rx and Tx configuration structs
> ethdev: introduce Rx queue offloads API
> ethdev: introduce Tx queue offloads API
> ethdev: add helpers to move to the new offloads API
>
> lib/librte_ether/rte_ethdev.c | 144
> ++++++++++++++++++++++++++++++++++++-
> lib/librte_ether/rte_ethdev.h | 72 +++++++++++++++----
> 2 files changed, 202 insertions(+), 14 deletions(-)
>
> --
> 2.12.0
next prev parent reply other threads:[~2017-08-23 6:39 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-07 10:54 Shahaf Shuler
2017-08-07 10:54 ` [dpdk-dev] [RFC PATCH 1/4] ethdev: rename Rx and Tx configuration structs Shahaf Shuler
2017-08-23 21:39 ` Thomas Monjalon
2017-08-07 10:54 ` [dpdk-dev] [RFC PATCH 2/4] ethdev: introduce Rx queue offloads API Shahaf Shuler
2017-08-23 12:21 ` Ananyev, Konstantin
2017-08-23 13:06 ` Shahaf Shuler
2017-08-23 21:48 ` Thomas Monjalon
2017-08-29 12:50 ` Ferruh Yigit
2017-08-30 6:22 ` Shahaf Shuler
2017-08-29 13:11 ` Ferruh Yigit
2017-08-07 10:54 ` [dpdk-dev] [RFC PATCH 3/4] ethdev: introduce Tx " Shahaf Shuler
2017-08-07 10:54 ` [dpdk-dev] [RFC PATCH 4/4] ethdev: add helpers to move to the new " Shahaf Shuler
2017-08-23 12:28 ` Ananyev, Konstantin
2017-08-23 13:13 ` Shahaf Shuler
2017-08-23 22:06 ` Thomas Monjalon
2017-08-24 7:12 ` Shahaf Shuler
2017-08-25 13:26 ` Thomas Monjalon
2017-08-29 12:55 ` Ferruh Yigit
2017-08-30 6:30 ` Shahaf Shuler
2017-08-30 7:50 ` Ferruh Yigit
2017-08-30 10:16 ` Ananyev, Konstantin
2017-08-30 12:42 ` Ferruh Yigit
2017-08-30 13:25 ` Thomas Monjalon
2017-08-30 14:15 ` Ananyev, Konstantin
2017-08-28 14:12 ` Ananyev, Konstantin
2017-08-29 6:26 ` Shahaf Shuler
2017-08-29 9:43 ` Ananyev, Konstantin
2017-08-23 6:39 ` Shahaf Shuler [this message]
2017-08-23 22:16 ` [dpdk-dev] [RFC PATCH 0/4] ethdev " Thomas Monjalon
2017-08-25 10:31 ` Jerin Jacob
2017-08-27 6:05 ` Shahaf Shuler
2017-08-28 5:00 ` Jerin Jacob
2017-08-28 10:57 ` Thomas Monjalon
2017-09-05 7:07 ` Jerin Jacob
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=VI1PR05MB3149686E969483730AA38EBCC3850@VI1PR05MB3149.eurprd05.prod.outlook.com \
--to=shahafs@mellanox.com \
--cc=dev@dpdk.org \
--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 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).