Re: Different packet handling after bpf_redirect_map with BPF_F_BROADCAST

Florian Kauer <[email protected]> writes:

> On 7/4/24 16:51, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>> Florian Kauer <[email protected]> writes:
>>=20
>>>>>>> 3. Extend the kernel with a way to let the xdp/devmap prog know from
>>>>>>> which DEVMAP entry its execution originates (like an additional ent=
ry
>>>>>>> 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) :)
>>>>>
>>>>> Would you prefer a simple u32 (or similar) that could then be used as
>>>>> index for an array or a more complex data structure/void* to fill
>>>>> with arbitrary data?
>>>>
>>>> Well, the API for map indexing specifies a u64 map index, so just
>>>> reusing that would be the simplest :)
>>>
>>> u64? Now I am confused:
>>> "The key type is an unsigned 32-bit integer (4 bytes)"
>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tre=
e/Documentation/bpf/map_array.rst?h=3Dnext-20240703
>>=20
>> That's the documentation for array maps. Devmap is documented here:
>
> Well, an array map would be where I would search for the needed informati=
on
> (like the VLAN tag) after the redirect.
>
> But I guess you meant not just "reusing" the TYPE of the devmap map index
> for another field in bpf_devmap_val, but actually reusing the devmap index
> itself and write it into the xdp_md, right? Then, of course, it would be
> a u64 (and needs to be truncated when indexing the array with the VLAN
> tags).

Yes, exactly. The "you are currently running in this devmap slot"
metadata is something the kernel should provide to the running program
as part of the execution context.

> Makes sense to me. I will try to assemble a patch and send it out for
> discussion.

Cool :)

-Toke