On Tue, Aug 16, 2022 at 04:07:55PM -0700, Jakub Kicinski wrote: > On Tue, 16 Aug 2022 07:02:33 +0000 Bobby Eshleman wrote: > > > From a cursory look (and Documentation/ would be nice..) it feels > > > very wrong to me. Do you know of any uses of a netdev which would > > > be semantically similar to what you're doing? Treating netdevs as > > > buildings blocks for arbitrary message passing solutions is something > > > I dislike quite strongly. > > > > The big difference between vsock and "arbitrary message passing" is that > > vsock is actually constrained by the virtio device that backs it (made > > up of virtqueues and the underlying protocol). That virtqueue pair is > > acting like the queues on a physical NIC, so it actually makes sense to > > manage the queuing of vsock's device like we would manage the queueing > > of a real device. > > > > Still, I concede that ignoring the netdev state is a probably bad idea. > > > > That said, I also think that using packet scheduling in vsock is a good > > idea, and that ideally we can reuse Linux's already robust library of > > packet scheduling algorithms by introducing qdisc somehow. > > We've been burnt in the past by people doing the "let me just pick > these useful pieces out of netdev" thing. Makes life hard both for > maintainers and users trying to make sense of the interfaces. > > What comes to mind if you're just after queuing is that we already > bastardized the CoDel implementation (include/net/codel_impl.h). > If CoDel is good enough for you maybe that's the easiest way? > Although I suspect that you're after fairness not early drops. > Wireless folks use CoDel as a second layer queuing. (CC: Toke) > That is certainly interesting to me. Sitting next to "codel_impl.h" is "include/net/fq_impl.h", and it looks like it may solve the datagram flooding issue. The downside to this approach is the baking of a specific policy into vsock... which I don't exactly love either. I'm not seeing too many other of these qdisc bastardizations in include/net, are there any others that you are aware of? > > > Could you recommend where I can learn more about vsocks? > > > > I think the spec is probably the best place to start[1]. > > > > [1]: https://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html > > Eh, I was hoping it was a side channel of an existing virtio_net > which is not the case. Given the zero-config requirement IDK if > we'll be able to fit this into netdev semantics :( It's certainly possible that it may not fit :/ I feel that it partially depends on what we mean by zero-config. Is it "no config required to have a working socket" or is it "no config required, but also no tuning/policy/etc... supported"? Best, Bobby
