Florian Kauer <florian.kauer@xxxxxxxxxxxxx> writes: > 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). 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
|