19/10/2021 10:52, David Marchand: > On Mon, Oct 18, 2021 at 4:49 PM Andrew Rybchenko > <andrew.rybche...@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?
Yes it is too early for such deprecation. OK to introduce new names, but please keep full compatibility.
