On Tue, Jul 11, 2023 at 8:29 PM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote: > > > This will slow things down, but not to the point where it's on par > with doing sw checksum. At least in theory. > We can't stay at skb when using AF_XDP. AF_XDP would benefit from having > the offloads. To clarify: yes, AF_XDP needs generalized HW offloads. I just don't see how xdp tx offloads are moving a needle in that direction. > I hope we can both agree that with an api like > mlx5_l4_csum_offload(bool encap) we can't be 100% certain that the > hw is gonna handle any packet layout? So how is that different > from a generic api that also can't work in all cases? If it's hw specific then yes. Will [mlx5|...]_l4_csum_offload apply to other nics? I doubt. > AF_XDP is a generic layer for low-level access and it provides generic > descriptor format, so why suddenly we have this requirement where we have > to do prog rewrite for every new nic? > > Current AF_XDP programs are pretty portable (obviously depend on > a bunch of nic features), it seems like a good idea to try to preserve > this property? (again, with an asterisk, where we should allow some > differentiation, etc, etc) Agree. AF_XDP needs a generic api that will allow user space request HW to do TSO, csum offload, etc. xdp tx and af_xdp are too different to pull under the same framework. xdp progs will interact with the kernel via kfuncs. af_xdp needs a different api to express packet geometry and offload requests. The user space cannot do it with bpf programs. In case of AF_XDP the bpf prog in the kernel is a filter only. For the majority of the cases bpf prog is not necessary and shouldn't be required to express HW offloads.
