From: Konstantin Ananyev <konstantin.ananyev@intel.com>
To: dev@dpdk.org
To: dev@dpdk.org
Cc: Konstantin Ananyev <konstantin.ananyev@intel.com>
Subject: [dpdk-dev] [RFC PATCH 0/3] *** SUBJECT HERE ***
Date: Fri, 1 Dec 2017 14:47:59 +0000 [thread overview]
Message-ID: <1512139682-11114-1-git-send-email-konstantin.ananyev@intel.com> (raw)
The series introduces 2 main changes:
1.Introduce a separate data structure (rte_eth_queue_local)
to store local to given process (i.e. no-shareable) information
for each configured rx/tx queue.
Memory for that structure is allocated/freed dynamically during
rte_eth_dev_configure().
Reserve a space for queue specific (rx|tx)_pkt_burst(),
tx_pkt_prepare() function pointers inside that structure.
Move rx/tx callback related information inside that structure.
That introduces a change in current behavior: all callbacks for
un-configured queues will be automatically removed.
Also as size of struct rte_eth_dev changes that patch is an ABI breakage,
so deprecation notice for 18.05 is filled.
Further suggestions how to introduce the same functionality
without ABI breakage are welcome.
2. Make it safe to remove rx/tx callback at runtime.
Right now it is not possible for the application to figure out
when it is safe to free removed callback handle and
associated with it resources(unless the queue is stopped).
That's probably not a big problem if all callbacks are static
hange through whole application lifetime)
and/or application doesn't allocate any resources for the callback handler.
Though if callbacks have to be added/removed dynamically and
callback handler would require more resources to operate properly -
then it might become an issue.
So patch #2 fixes that problem - now as soon as
rte_eth_remove_(rx|tx)_callback() completes successfully, application
can safely free all associated with the removed callback resources.
Performance impact:
If application doesn't use RX/TX callbacks, then the tests I run didn't
reveal any performance degradation.
Though if application do use RX/TX callbacks - patch #2 does introduce
some slowdown.
To be more specific here, on BDW (E5-2699 v4) 2.2GHz, 4x10Gb (X520-4)
with http://dpdk.org/dev/patchwork/patch/31864/ patch installed I got:
1) testpmd ... --latencystats=1 - slowdown < 1%
2) examples//l3fwd ... --parse-ptype - - slowdown < 1%
3) examples/rxtx_callbacks - slowdown ~8%
All that in terms of packet throughput (Mpps).
Ability to safely remove callbacks at runtime implies
some sort of synchronization.
Even I tried to make it as light as possible,
probably some slowdown is unavoidable.
Of course instead of introducing these changes at rte_ethdev layer
similar technique could be applied on individual callback basis.
In that case it would be up to callback writer/installer to decide
does he/she need a removable at runtime callback or not.
Though in that case, each installed callback might introduce extra
synchronization overhead and slowdown.
Konstantin Ananyev (3):
ethdev: introduce eth_queue_local
ethdev: make it safe to remove rx/tx callback at runtime
doc: ethdev ABI change deprecation notice
doc/guides/rel_notes/deprecation.rst | 5 +
lib/librte_ether/rte_ethdev.c | 390 ++++++++++++++++++++++-------------
lib/librte_ether/rte_ethdev.h | 174 ++++++++++++----
3 files changed, 387 insertions(+), 182 deletions(-)
--
2.13.5
next reply other threads:[~2017-12-01 14:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-01 14:47 Konstantin Ananyev [this message]
2017-12-01 14:48 ` [dpdk-dev] [RFC PATCH 1/3] ethdev: introduce eth_queue_local Konstantin Ananyev
2017-12-01 14:48 ` [dpdk-dev] [RFC PATCH 2/3] ethdev: make it safe to remove rx/tx callback at runtime Konstantin Ananyev
2017-12-01 14:48 ` [dpdk-dev] [RFC PATCH 3/3] doc: ethdev ABI change deprecation notice Konstantin Ananyev
2017-12-12 14:55 ` Kovacevic, Marko
2017-12-01 14:56 ` [dpdk-dev] [RFC PATCH 0/3] *** SUBJECT HERE *** Ananyev, Konstantin
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=1512139682-11114-1-git-send-email-konstantin.ananyev@intel.com \
--to=konstantin.ananyev@intel.com \
--cc=dev@dpdk.org \
/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).