DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
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:

  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