Is mempool-cache-size effective in DPDK mode in Suricata?

Developers
, ,
1

Suricata: 8.0.1
DPDK: 24.11.3

DPDK mempool per-lcore local cache uses rte_lcore_id() to get the index. This value is set in EAL worker threads, but is invalid in Suricata worker threads.

Suricata add log:

static TmEcode ReceiveDPDKThreadInit(ThreadVars *tv, const void *initdata, void **data)
{
/**/
// Add log
SCLogConfig("Dpdk lcore_id=%u", rte_lcore_id());
/**/
}

Ouputs:

Config: dpdk: Dpdk lcore_id=4294967295

DPDK add log:

static __rte_always_inline struct rte_mempool_cache *
rte_mempool_default_cache(struct rte_mempool *mp, unsigned lcore_id)
{
	if (mp->cache_size == 0) 
		return NULL;

	if (lcore_id >= RTE_MAX_LCORE) {
       // Add log
		RTE_MEMPOOL_LOG(ERR, "%s: lcore_id %u out of range", mp->name, lcore_id);
		return NULL;
	}

	rte_mempool_trace_default_cache(mp, lcore_id,
		&mp->local_cache[lcore_id]);
	return &mp->local_cache[lcore_id];
}

Outputs:

MEMPOOL: mempool_0000:00:13.0: lcore_id 4294967295 out of range

Suricata yaml dpdk config:

dpdk:
  eal-params:
    proc-type: primary
    log-level:
      - debug
      - bus.*:debug

  interfaces:
    - interface: 0000:00:13.0 
      threads: 1
      promisc: true 
      multicast: true 
      checksum-checks: false 
      checksum-checks-offload: true 
      mtu: 1500 
      mempool-size: 4096
      mempool-cache-size: 256
      rx-descriptors: 1024
      tx-descriptors: 1024
2

Hi gongziw,

Thanks for reaching out. It does indeed look like it is not used, so converting threads to EAL-initialized threads makes sense. Since in 8, each thread has their own mempool, I don’t expect a big bump in performance, though I think it makes sense to convert to EAL threads anyway.

Ticket formed in Feature #8084: dpdk: in dpdk runmode initiialize EAL threads - Suricata - Open Information Security Foundation