On 7/4/24 16:51, Toke Høiland-Jørgensen wrote:
> Florian Kauer <florian.kauer@xxxxxxxxxxxxx> writes:
>
>>>>>> 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) :)
>>>>
>>>> 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/tree/Documentation/bpf/map_array.rst?h=next-20240703
>
> That's the documentation for array maps. Devmap is documented here:
Well, an array map would be where I would search for the needed information
(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).
Makes sense to me. I will try to assemble a patch and send it out for discussion.
Thanks,
Florian
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/bpf/map_devmap.rst?h=next-20240703
>
> The text doesn't say anything explicitly about the key type, but the
> function signature for the redirect function has not been updated, it
> seems. The key type was changed to u64 in commit:
>
> 32637e33003f ("bpf: Expand map key argument of bpf_redirect_map to u64")
>
> -Toke
>
>
|