From: "Morten Brørup" <mb@smartsharesystems.com>
To: <bruce.richardson@intel.com>,
"Konstantin Ananyev" <konstantin.v.ananyev@yandex.ru>,
"Vipin Varghese" <vipin.varghese@amd.com>
Cc: <dev@dpdk.org>, "Leyi Rong" <leyi.rong@intel.com>,
<qi.z.zhang@intel.com>, <wenzhuo.lu@intel.com>,
<ferruh.yigit@intel.com>, <bruce.richardson@intel.com>,
<beilei.xing@intel.com>
Subject: AVX512 block copy performance?
Date: Mon, 20 Jul 2026 12:10:34 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F6597E@smartserver.smartshare.dk> (raw)
In-Reply-To: <20210114063951.2580-4-leyi.rong@intel.com>
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Leyi Rong
> Sent: Thursday, 14 January 2021 07.40
>
> Optimize Tx path by using AVX512 instructions and vectorize the
> tx free bufs process.
>
> Signed-off-by: Leyi Rong <leyi.rong@intel.com>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
[...]
> +static __rte_always_inline int
> +i40e_tx_free_bufs_avx512(struct i40e_tx_queue *txq)
> +{
> + struct i40e_vec_tx_entry *txep;
> + uint32_t n;
> + uint32_t i;
> + int nb_free = 0;
> + struct rte_mbuf *m, *free[RTE_I40E_TX_MAX_FREE_BUF_SZ];
> +
> + /* check DD bits on threshold descriptor */
> + if ((txq->tx_ring[txq->tx_next_dd].cmd_type_offset_bsz &
> + rte_cpu_to_le_64(I40E_TXD_QW1_DTYPE_MASK)) !=
> + rte_cpu_to_le_64(I40E_TX_DESC_DTYPE_DESC_DONE))
> + return 0;
> +
> + n = txq->tx_rs_thresh;
> +
> + /* first buffer to free from S/W ring is at index
> + * tx_next_dd - (tx_rs_thresh-1)
> + */
> + txep = (void *)txq->sw_ring;
> + txep += txq->tx_next_dd - (n - 1);
> +
> + if (txq->offloads & DEV_TX_OFFLOAD_MBUF_FAST_FREE && (n & 31) ==
> 0) {
> + struct rte_mempool *mp = txep[0].mbuf->pool;
> + void **cache_objs;
> + struct rte_mempool_cache *cache =
> rte_mempool_default_cache(mp,
> + rte_lcore_id());
> +
> + if (!cache || cache->len == 0)
> + goto normal;
> +
> + cache_objs = &cache->objs[cache->len];
> +
> + if (n > RTE_MEMPOOL_CACHE_MAX_SIZE) {
> + rte_mempool_ops_enqueue_bulk(mp, (void *)txep, n);
> + goto done;
> + }
> +
> + /* The cache follows the following algorithm
> + * 1. Add the objects to the cache
> + * 2. Anything greater than the cache min value (if it
> + * crosses the cache flush threshold) is flushed to the
> ring.
> + */
> + /* Add elements back into the cache */
> + uint32_t copied = 0;
> + /* n is multiple of 32 */
> + while (copied < n) {
> + const __m512i a = _mm512_load_si512(&txep[copied]);
> + const __m512i b = _mm512_load_si512(&txep[copied +
> 8]);
> + const __m512i c = _mm512_load_si512(&txep[copied +
> 16]);
> + const __m512i d = _mm512_load_si512(&txep[copied +
> 24]);
> +
> + _mm512_storeu_si512(&cache_objs[copied], a);
> + _mm512_storeu_si512(&cache_objs[copied + 8], b);
> + _mm512_storeu_si512(&cache_objs[copied + 16], c);
> + _mm512_storeu_si512(&cache_objs[copied + 24], d);
> + copied += 32;
> + }
Do you have any indications about how this copy loop performs, compared to e.g. the 64-byte block copy in rte_memcpy() [1]?
[1]: https://github.com/DPDK/dpdk/blob/v26.07-rc4/lib/eal/x86/include/rte_memcpy.h#L657
I'm wondering if it would be worth adding something similar to the mempool library, for speeding up mbuf alloc/free.
> + cache->len += n;
> +
> + if (cache->len >= cache->flushthresh) {
> + rte_mempool_ops_enqueue_bulk
> + (mp, &cache->objs[cache->size],
> + cache->len - cache->size);
> + cache->len = cache->size;
> + }
> + goto done;
> + }
> +
> +normal:
next prev parent reply other threads:[~2026-07-20 10:10 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-15 2:19 [dpdk-dev] [PATCH 0/3] AVX512 vPMD on i40e Leyi Rong
2020-12-15 2:19 ` [dpdk-dev] [PATCH 1/3] net/i40e: remove devarg use-latest-supported-vec Leyi Rong
2020-12-15 2:19 ` [dpdk-dev] [PATCH 2/3] net/i40e: add AVX512 vector path Leyi Rong
2020-12-15 2:19 ` [dpdk-dev] [PATCH 3/3] net/i40e: optimize Tx by using AVX512 Leyi Rong
2021-01-07 7:44 ` [dpdk-dev] [PATCH v2 0/3] AVX512 vPMD on i40e Leyi Rong
2021-01-07 7:44 ` [dpdk-dev] [PATCH v2 1/3] net/i40e: remove devarg use-latest-supported-vec Leyi Rong
2021-01-13 6:12 ` Lu, Wenzhuo
2021-01-13 13:40 ` Ferruh Yigit
2021-01-07 7:44 ` [dpdk-dev] [PATCH v2 2/3] net/i40e: add AVX512 vector path Leyi Rong
2021-01-13 6:13 ` Lu, Wenzhuo
2021-01-07 7:44 ` [dpdk-dev] [PATCH v2 3/3] net/i40e: optimize Tx by using AVX512 Leyi Rong
2021-01-13 6:12 ` Lu, Wenzhuo
2021-01-13 9:53 ` [dpdk-dev] [PATCH v2 0/3] AVX512 vPMD on i40e Zhang, Qi Z
2021-01-14 6:39 ` [dpdk-dev] [PATCH v3 " Leyi Rong
2021-01-14 6:39 ` [dpdk-dev] [PATCH v3 1/3] net/i40e: remove devarg use-latest-supported-vec Leyi Rong
2021-01-15 13:36 ` Ferruh Yigit
2021-01-14 6:39 ` [dpdk-dev] [PATCH v3 2/3] net/i40e: add AVX512 vector path Leyi Rong
2021-01-14 6:39 ` [dpdk-dev] [PATCH v3 3/3] net/i40e: optimize Tx by using AVX512 Leyi Rong
2026-07-20 10:10 ` Morten Brørup [this message]
2026-07-20 10:19 ` AVX512 block copy performance? Bruce Richardson
2021-01-14 7:37 ` [dpdk-dev] [PATCH v3 0/3] AVX512 vPMD on i40e Zhang, Qi Z
2021-01-17 11:26 ` Odi Assli
2021-01-18 13:58 ` Rong, Leyi
2021-01-18 14:24 ` Ferruh Yigit
2021-01-18 14:53 ` Odi Assli
2021-01-18 16:36 ` Ferruh Yigit
2021-01-19 13:46 ` Ali Alnubani
2021-01-20 6:25 ` Tal Shnaiderman
2021-01-20 8:36 ` David Marchand
2021-01-20 9:18 ` Ferruh Yigit
2021-01-20 9:23 ` Thomas Monjalon
2021-01-20 9:53 ` David Marchand
2021-01-20 10:05 ` Ali Alnubani
2021-01-20 17:51 ` Ferruh Yigit
2021-01-20 18:04 ` Ferruh Yigit
2021-01-21 5:01 ` Kadam, Pallavi
2021-01-25 14:35 ` David Marchand
2021-01-26 16:17 ` Rong, Leyi
2021-01-26 16:22 ` Thomas Monjalon
2021-01-26 16:39 ` Ferruh Yigit
2021-01-26 16:48 ` Thomas Monjalon
2021-01-26 16:51 ` Ferruh Yigit
2021-01-28 20:35 ` Dmitry Kozlyuk
2021-01-28 21:24 ` Thomas Monjalon
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=98CBD80474FA8B44BF855DF32C47DC35F6597E@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=beilei.xing@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=konstantin.v.ananyev@yandex.ru \
--cc=leyi.rong@intel.com \
--cc=qi.z.zhang@intel.com \
--cc=vipin.varghese@amd.com \
--cc=wenzhuo.lu@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