> From: Heng Qi <hen...@linux.alibaba.com> > Sent: Monday, March 20, 2023 11:56 PM
> > the same flow? If enough people agree this is needed we can accept this > > but did you at all consider using something programmable like BPF for > > I think the problem is that our virtio device cannot support ebpf, we > can also ask Alvaro, Parav if their virtio devices can support ebpf > offloading. :) tc qdisc offload for qos is a better choice than ebpf to me given the role is more than just drop action. It requires many calculations across many queues. But such qos is orthogonal to what is being proposed here. One (this proposal) is solving spread to different RSS queues. Another one is finding out which exact packet to drop/pass when queue usage is high. (ebpf/tc other ways to solve it). Ebpf sounds cooler than the real offload implementation in the hw device at the current level. I remember Jason's good talk on the ebpf a few years back, which is possible when done in sw on the hypervisor. On mlx5 device inner hash is supported for IPnIP and GRE tunnels. None of the existing users see tunnel attacks when used as forwarding plane.
