Florian Kauer <florian.kauer@xxxxxxxxxxxxx> writes:
> 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.
Having multiple entries in the devmap entry corresponds roughly to how
the stack handles VLANs. I.e., when configuring a VLAN, you create a new
netdevice (which you would then put into the devmap). Unfortunately, XDP
doesn't really know how to deal with stacked devices like VLANs, so you
can't actually add a VLAN device into a devmap. But creating an
interface for this would be one way of dealing with a situation like
this, without having to hardcode things into a BPF program.
> 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.
This would work, I think. Something like:
static volatile const vlan_id = 1;
SEC("xdp/devmap")
int replicate_postprocessing_second(struct xdp_md *pkt)
{
int ret = change_vlan(pkt, vlan_id, true);
...
}
and then the loader would replace the value of vlan_id before loading;
using skeletons this would look something like:
skel = xdp_program_skeleton__open();
skel->rodata->vlan_id = 2;
xdp_program_skeleton__load();
/* attach to devmap */
> But can I even reference a xdp/devmap prog from a different loaded
> bpf, especially when it is not attached?
Why do you need to reference it from a different BPF program? The
userspace program just attaches it to the right devmap entry?
> 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).
This could be useful in any case, so I would personally be fine with
adding something like this (for both devmap and cpumap) :)
-Toke
|