Cong Wang wrote: > On Tue, Aug 24, 2021 at 4:47 PM Martin KaFai Lau <kafai@xxxxxx> wrote: > > Please explain more on this. What is currently missing > > to make qdisc in struct_ops possible? > > I think you misunderstand this point. The reason why I avoid it is > _not_ anything is missing, quite oppositely, it is because it requires > a lot of work to implement a Qdisc with struct_ops approach, literally > all those struct Qdisc_ops (not to mention struct Qdisc_class_ops). > WIth current approach, programmers only need to implement two > eBPF programs (enqueue and dequeue). > > Thanks. Another idea. Rather than work with qdisc objects which creates all these issues with how to work with existing interfaces, filters, etc. Why not create an sk_buff map? Then this can be used from the existing egress/ingress hooks independent of the actual qdisc being used. You mention skb should not be exposed to userspace? Why? Whats the reason for this? Anyways we can make kernel only maps if we want or scrub the data before passing it to userspace. We do this already in some cases. IMO it seems cleaner and more general to allow sk_buffs to be stored in maps and pulled back out later for enqueue/dequeue. I think one trick might be how to trigger the dequeue event on transition from stopped to running net_device or other events like this, but that could be solved with another program attached to those events to kick the dequeue logic. .John
