[RFC bpf] Ingress RX queue provenance across cpumap redirect

[Adith-Joshua <adithalex29@gmail.com>]

Hi,

While working with XDP programs using cpumap redirection, I observed that
ctx->rx_queue_index becomes 0 after xdp_buff -> xdp_frame conversion and
execution on the remote CPU.

This is expected since xdp_frame does not carry xdp_rxq_info and cpumap
re-invokes XDP in a new execution context.

---

## Motivation

Some XDP deployments use cpumap as part of a multi-stage packet processing
pipeline, where XDP is effectively used as a distributed processing model
across CPUs rather than a single RX invocation.

In such setups, ingress RX queue identity (rx_queue_index) is sometimes
used beyond the initial hook not only for debugging, but for maintaining
consistent observability and pipeline semantics across stages. This includes:

  - maintaining consistent per-RX-queue accounting across cpumap and later
    XDP stages
  - preserving RSS-based classification identity for traffic analysis and
    validation of NIC steering behavior across a distributed pipeline
  - enabling end-to-end telemetry correlation from hardware queue origin
    through CPU-side processing
  - supporting reproducibility of packet processing paths in asynchronous
    cpumap-driven execution where scheduling and CPU assignment may vary

In these cases, rx_queue_index acts as a stable ingress classification anchor.
Losing this information at the cpumap boundary breaks the assumption that
XDP programs operate on a logically continuous packet context across stages.

---

## Design observation

Current behavior appears intentional:

  - xdp_frame does not carry xdp_rxq_info
  - cpumap executes XDP in a new RX context
  - RX metadata is not considered part of redirected packet state

This suggests that RX provenance is currently scoped strictly to the NIC RX
invocation context, and is not carried across execution boundaries such as
cpumap or devmap.

---

## Question

Is RX queue provenance expected to be part of the XDP execution model across
redirect boundaries, or is it explicitly considered out of scope once a packet
is passed through cpumap/devmap?

---

## Alternative direction (for clarification only)

One possible model could be to treat ingress RX metadata as optional,
non-authoritative context and expose it via a helper-based mechanism
(e.g. ingress queue accessor), rather than embedding it in xdp_frame or
xdp_rxq_info.

However, I am not assuming this is aligned with existing design principles,
and would appreciate clarification on whether such a model is desirable at all.

To be explicit, I am not proposing that rx_queue_index itself be preserved
in xdp_frame or across cpumap, nor any change to existing struct layouts.

The question is whether ingress RX queue identity is intended to be
representable beyond the initial NIC RX invocation, particularly in
redirect-based XDP pipelines.

This question is motivated by cases where cpumap is used as part of a
multi-stage XDP processing pipeline, where loss of ingress queue identity
removes a stable classification signal that can otherwise be useful for:

  - correlating packets across distributed XDP execution stages
  - validating RSS / hardware steering behavior in software datapaths
  - maintaining consistent per-queue observability across cpumap boundaries
  - reconstructing ingress-to-processing paths in asynchronous CPU offload

The intent is to understand whether these requirements are intentionally
out of scope in the current XDP execution model, or whether a helper-based
or metadata-based abstraction is expected for such use cases.

---

## Follow-up

If this aligns with intended design, I would be happy to explore a concrete
proposal or implementation.

Thanks,
Adith