[dpdk-dev] [PATCH 2/6] mempool: add namespace prefix to flags

[David Marchand]

On Mon, Oct 18, 2021 at 4:49 PM Andrew Rybchenko
<andrew.rybchenko at oktetlabs.ru> wrote:
>
> Fix the mempool flgas namespace by adding an RTE_ prefix to the name.
> The old flags remain usable, but a deprecation warning is issued at
> compilation.

We have a build failure in CI for SPDK.
This is most probably (I can't find the full compilation error in
logs..) because of the deprecation of MEMPOOL_F_NO_IOVA_CONTIG.


$ git grep-all -E
'\<(MEMPOOL_F_NO_IOVA_CONTIG|MEMPOOL_F_POOL_CREATED|MEMPOOL_F_SC_GET|MEMPOOL_F_SP_PUT|MEMPOOL_F_NO_CACHE_ALIGN|MEMPOOL_F_NO_SPREAD)\>'
BESS/core/packet_pool.cc:  pool_->flags |= MEMPOOL_F_NO_IOVA_CONTIG;
gatekeeper/cps/main.c:        socket_id, MEMPOOL_F_SP_PUT | MEMPOOL_F_SC_GET);
gatekeeper/cps/main.c:        socket_id, MEMPOOL_F_SP_PUT | MEMPOOL_F_SC_GET);
mTcp/mtcp/src/dpdk_module.c:                rte_socket_id(), MEMPOOL_F_SP_PUT |
mTcp/mtcp/src/dpdk_module.c:                MEMPOOL_F_SC_GET);
mTcp/mtcp/src/memory_mgt.c:                MEMPOOL_F_NO_SPREAD);
OpenDataplane/platform/linux-generic/pktio/dpdk.c:#define
MEMPOOL_FLAGS MEMPOOL_F_NO_IOVA_CONTIG
SPDK/lib/env_dpdk/env.c:                socket_id, MEMPOOL_F_NO_IOVA_CONTIG);
Trex/src/pal/linux_dpdk/mbuf.cpp:    unsigned flags = is_hugepages ? 0
: MEMPOOL_F_NO_IOVA_CONTIG;
Trex/src/pal/linux_dpdk/mbuf.cpp:        flags = (MEMPOOL_F_SP_PUT |
MEMPOOL_F_SC_GET);
Trex/src/pal/linux_dpdk/mbuf.cpp:        flags |= MEMPOOL_F_NO_IOVA_CONTIG;
Warp17/inc/tpg_memory.h:#define MEM_MBUF_POOL_FLAGS (MEMPOOL_F_SP_PUT
| MEMPOOL_F_SC_GET)
Warp17/inc/tpg_memory.h:#define MEM_TCB_POOL_FLAGS (MEMPOOL_F_SP_PUT |
MEMPOOL_F_SC_GET)
Warp17/inc/tpg_memory.h:#define MEM_UCB_POOL_FLAGS (MEMPOOL_F_SP_PUT |
MEMPOOL_F_SC_GET)
Warp17/src/ring_if/tpg_ring_if.c:static_assert(!(MEM_MBUF_POOL_FLAGS &
MEMPOOL_F_SP_PUT),
Warp17/src/ring_if/tpg_ring_if.c:              "MEM_MBUF_POOL_FLAGS
contains MEMPOOL_F_SP_PUT! This will corrupt memory when using Ring
Interfaces!");


If we had announced such a deprecation, I would not question the change.
I think we should postpone the deprecation part to 22.02.

Thomas, what do you think?


-- 
David Marchand