On Tue, Aug 31, 2021 at 10:45 PM John Fastabend <john.fastabend@xxxxxxxxx> wrote: > > 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. Because it is pointless to expose them to user-space in this context. For example, what is the point of dropping a packet from user-space in the context of Qdisc? And I don't think there is a way for user-space to read those skb's inside a map, which makes it more pointless. > > 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. I am not aware of any kernel-only map. For starters, we can't create a map from kernel-space. > > IMO it seems cleaner and more general to allow sk_buffs > to be stored in maps and pulled back out later for enqueue/dequeue. Which exact map are you referring to? The queue map? It would only provide FIFO. We want to give users as much freedom to order the skbs as we can, I doubt hashmap could offer such freedom. > > 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. I think we can still use current enqueue/dequeue eBPF program except we need to transfer skb ownership and storage to map. Thanks.
