Different packet handling after bpf_redirect_map with BPF_F_BROADCAST

[Florian Kauer <florian.kauer@xxxxxxxxxxxxx>]

Hi,
we are currently using bpf_redirect_map with BPF_F_BROADCAST to replicate frames for sending traffic over redundant paths.

See for example https://www.rfc-editor.org/rfc/rfc8655.html#section-3.2.2.2 for background
and https://github.com/EricssonResearch/xdpfrer/blob/5f0845cb2e4c4da325f0e77df3020526ad992aff/src/xdpfrer.bpf.c#L393 for the current implementation.

However, we want to modify the frame after the replication. In the easiest case this means to change the VLAN tag to route the traffic over different VLANs. This is currently done by taking a different egress_ifindex into account after the replication and that works well so far ( https://github.com/EricssonResearch/xdpfrer/blob/5f0845cb2e4c4da325f0e77df3020526ad992aff/src/xdpfrer.bpf.c#L399 ).

BUT there are cases where the egress_interface for both replicated packets shall be the same and the different path of the replicated frames is only taken on a subsequent switch based on a different VLAN tag. So how could the XDP program differentiate between the different replicated frames if the egress_interface is the same?

So my basic idea would be to add two (or more) DEVMAP entries with the same ifindex into the same map. And then either

1. Add several xdp/devmap progs to the same loaded bpf and reference them in the DEVMAP entry, like

SEC("xdp/devmap")
int replicate_postprocessing_first(struct xdp_md *pkt)
{
    int ret = change_vlan(pkt, 0, true);
    ...
}

SEC("xdp/devmap")
int replicate_postprocessing_second(struct xdp_md *pkt)
{
    int ret = change_vlan(pkt, 1, true);
    ...
}

This, however, would be quite unflexible.

2. Load the same bpf several times without attaching it to an interface and set e.g. a const to a different value after loading. But can I even reference a xdp/devmap prog from a different loaded bpf, especially when it is not attached?

3. Extend the kernel with a way to let the xdp/devmap prog know from which DEVMAP entry its execution originates (like an additional entry in the bpf_devmap_val that is then set in the xdp_md).

Any other ideas?

By the way: We likely need the same for CPUMAP, too (see https://lore.kernel.org/xdp-newbies/c8072891-6d5c-42c3-8b13-e8ca9ab6c43c@xxxxxxxxxxxxx/T/#u for why).

Thanks,
Florian