Question about namespace requirements for UCX `posix` shm in a host <-> isolated-container deployment

[reverseW]

Hi UCX maintainers,

I would like to ask a few design questions about namespace requirements in UCX
shared-memory transports, especially the posix transport.

Context

I am using a "host <-> isolated-container" shared-memory communication model in
which:

• one UCX process runs on the host
• another UCX process runs inside an isolated container
• the container keeps its own PID and IPC namespaces, without --pid=host or
  --ipc=host
• both sides are configured with UCX_POSIX_DIR=<mount-dir> and
  UCX_POSIX_USE_PROC_LINK=n

The reason for asking is that in some production environments, --pid=host and
--ipc=host are not acceptable, while bind-mounting an approved directory is
acceptable.

In this deployment model, ucx_perftest reports failures.

Reproduction Steps

UCX version: latest

Environment: Ubuntu 24.04

1. In the UCX root directory, build UCX.

2. In shell 1, run:

UCX_TLS=posix UCX_LOG_LEVEL=debug UCX_POSIX_DIR=./examples/ UCX_POSIX_USE_PROC_LINK=n ./src/tools/perf/ucx_perftest -t ucp_am_lat -n 10000000

3. In shell 2, run:

docker run --rm -it \
  --network host \
  --cap-add SYS_PTRACE \
  --security-opt seccomp=unconfined \
  --user "$(id -u):$(id -g)" \
  -v "${UCX_ROOT}:/ucx" \
  -w /ucx \
  -e "UCX_TLS=posix" \
  -e "UCX_LOG_LEVEL=debug" \
  -e "UCX_POSIX_DIR=./examples/" \
  -e "UCX_POSIX_USE_PROC_LINK=n" \
  "${IMAGE_NAME}" \
  ./src/tools/perf/ucx_perftest -t ucp_am_lat "${SERVER_ADDR}" -n 10000000

Shell 2 reports errors like:

select.c:657  UCX  ERROR   no active messages transport to <no debug data>: posix/memory - different host id local 18313175406712172313 vs 9089803369857396505

My understanding of the current behavior

From reading the code, it seems UCX currently assumes namespace compatibility at
the following levels:

• uct_mm_iface_is_reachable_v2() checks shared-memory reachability based on
  local/peer namespace-related information
• uct_ep_keepalive_init() and uct_ep_keepalive_check() logic may depend on
  visibility of the remote PID through /proc

Main questions

I would really appreciate maintainer guidance on the following:

1. Why does UCX require strict IPC and PID namespace compatibility for posix
   shared-memory communication?

2. What do you think about using Linux memfd as an alternative mechanism for
   the shared-memory transport? My understanding is that, in theory, memfd
   should avoid those limitations of pathname-based shared-memory
   objects.