From: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
To: Feifei Wang <feifei.wang2@arm.com>,
Yuying Zhang <Yuying.Zhang@intel.com>,
Beilei Xing <beilei.xing@intel.com>,
Ruifeng Wang <ruifeng.wang@arm.com>
Cc: dev@dpdk.org, nd@arm.com,
Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Subject: Re: [RFC PATCH v1] net/i40e: put mempool cache out of API
Date: Sun, 3 Jul 2022 13:20:13 +0100 [thread overview]
Message-ID: <1e082bfe-9b52-86f0-e7fa-279ef8feaf1a@yandex.ru> (raw)
In-Reply-To: <20220613055136.1949784-1-feifei.wang2@arm.com>
> Refer to "i40e_tx_free_bufs_avx512", this patch puts mempool cache
> out of API to free buffers directly. There are two changes different
> with previous version:
> 1. change txep from "i40e_entry" to "i40e_vec_entry"
> 2. put cache out of "mempool_bulk" API to copy buffers into it directly
>
> Performance Test with l3fwd neon path:
> with this patch
> n1sdp: no perforamnce change
> amper-altra: +4.0%
>
Thanks for RFC, appreciate your effort.
So, as I understand - bypassing mempool put/get itself
gives about 7-10% speedup for RX/TX on ARM platforms,
correct?
About direct-rearm RX approach you propose:
After another thought, probably it is possible to
re-arrange it in a way that would help avoid related negatives.
The basic idea as follows:
1. Make RXQ sw_ring visible and accessible by 'attached' TX queues.
Also make sw_ring de-coupled from RXQ itself, i.e:
when RXQ is stopped or even destroyed, related sw_ring may still
exist (probably ref-counter or RCU would be sufficient here).
All that means we need a common layout/api for rxq_sw_ring
and PMDs that would like to support direct-rearming will have to
use/obey it.
2. Make RXQ sw_ring 'direct' rearming driven by TXQ itself, i.e:
at txq_free_bufs() try to store released mbufs inside attached
sw_ring directly. If there is no attached sw_ring, or not enough
free space in it - continue with mempool_put() as usual.
Note that actual arming of HW RXDs still remains responsibility
of RX code-path:
rxq_rearm(rxq) {
...
- check are there are N already filled entries inside rxq_sw_ring.
if not, populate them from mempool (usual mempool_get()).
- arm related RXDs and mark these sw_ring entries as managed by HW.
...
}
So rxq_sw_ring will serve two purposes:
- track mbufs that are managed by HW (that what it does now)
- private (per RXQ) mbuf cache
Now, if TXQ is stopped while RXQ is running -
no extra synchronization is required, RXQ would just use
mempool_get() to rearm its sw_ring itself.
If RXQ is stopped while TXQ is still running -
TXQ can still continue to populate related sw_ring till it gets full.
Then it will continue with mempool_put() as usual.
Of-course it means that user who wants to use this feature should
probably account some extra mbufs for such case, or might be
rxq_sw_ring can have enable/disable flag to mitigate such situation.
As another benefit here - such approach makes possible to use
several TXQs (even from different devices) to rearm same RXQ.
Have to say, that I am still not sure that 10% RX/TX improvement is
worth bypassing mempool completely and introducing all this extra
complexity in RX/TX path.
But, if we'll still decide to go ahead with direct-rearming, this
re-arrangement, I think, should help to keep things clear and
avoid introducing new limitations in existing functionality.
WDYT?
Konstantin
next prev parent reply other threads:[~2022-07-03 12:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-13 5:51 Feifei Wang
2022-06-13 9:58 ` Morten Brørup
2022-06-22 19:07 ` Honnappa Nagarahalli
2022-07-03 12:20 ` Konstantin Ananyev [this message]
2022-07-06 8:52 ` 回复: " Feifei Wang
2022-07-06 11:35 ` Feifei Wang
2022-07-11 3:08 ` Feifei Wang
2022-07-11 6:19 ` Honnappa Nagarahalli
2022-07-13 18:48 ` Konstantin Ananyev
2022-07-15 21:52 ` Honnappa Nagarahalli
2022-07-21 10:02 ` Konstantin Ananyev
2022-07-15 22:06 ` Honnappa Nagarahalli
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=1e082bfe-9b52-86f0-e7fa-279ef8feaf1a@yandex.ru \
--to=konstantin.v.ananyev@yandex.ru \
--cc=Yuying.Zhang@intel.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=feifei.wang2@arm.com \
--cc=honnappa.nagarahalli@arm.com \
--cc=nd@arm.com \
--cc=ruifeng.wang@arm.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).