Bug 1027

Summary:	mempool cache size parameter is misleading
Product:	DPDK	Reporter:	Morten Brørup (mb)
Component:	core	Assignee:	dev
Status:	UNCONFIRMED ---
Severity:	normal
Priority:	Normal
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	All

Description Morten Brørup 2022-06-07 09:42:03 CEST

A flush threshold for the mempool cache was introduced in DPDK version
1.3. With this modification, the actual size of the mempool cache was multiplied by 1.5, so e.g. a specified size of 512 allows the mempool cache to hold up to 1.5 * 512 = 768 objects.

None of the documentation was updated to reflect this change.

E.g. the Programmer's Guide says:

"The maximum size of the cache is static and is defined at compilation time (RTE_MEMPOOL_CACHE_MAX_SIZE)." But in reality, the maximum size of the cache is RTE_MEMPOOL_CACHE_MAX_SIZE * 1.5.

Also, the "size" field of the rte_mempool_cache structure and the "cache_size" parameter of the rte_mempool_create() function don't mention that the value is 1/1.5 of the actual size.

If we don't want to fix the code, then the documentation needs to be fixed.

Comment 1 Morten Brørup 2023-10-05 10:01:10 CEST

This discrepancy also leads to bugs in applications, where the application developer rightfully assumes that the cache cannot consume more than its size.

E.g. l3fwd-power calculates the number of required mbufs as:

#define NB_MBUF RTE_MAX	( \
	(nb_ports*nb_rx_queue*nb_rxd + \
	nb_ports*nb_lcores*MAX_PKT_BURST + \
	nb_ports*n_tx_queue*nb_txd + \
	nb_lcores*MEMPOOL_CACHE_SIZE), \
	(unsigned)8192)

Note that MEMPOOL_CACHE_SIZE is not multiplied by 1.5 here.

Updating the documentation is not sufficient to prevent application bugs. This needs to be fixed in the mempool library, so I have changed the bug component from "doc" to "core".

Not even the DPDK example application developers take the 1.5 mempool cache size factor into consideration. How can we expect other application developers to do it?