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) > > 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 :(
