On Tue, Mar 11, 2025 at 4:14 AM Bobby Eshleman <bobbyeshle...@gmail.com> wrote: > > On Wed, Mar 05, 2025 at 01:46:54PM +0800, Jason Wang wrote: > > On Wed, Mar 5, 2025 at 8:39 AM Bobby Eshleman <bobbyeshle...@gmail.com> > > wrote: > > > > > > On Tue, Apr 28, 2020 at 06:00:52PM +0200, Stefano Garzarella wrote: > > > > On Tue, Apr 28, 2020 at 04:13:22PM +0800, Jason Wang wrote: > > > > > > WRT netdev, do we foresee big gains beyond just leveraging the netdev's > > > namespace? > > > > It's a leverage of the network subsystem (netdevice, steering, uAPI, > > tracing, probably a lot of others), not only its namespace. It can > > avoid duplicating existing mechanisms in a vsock specific way. If we > > manage to do that, namespace support will be a "byproduct". > > > [...] > > > > Yes, it can. I think we need to evaluate both approaches (that's why I > > raise the approach of reusing netdevice). We can hear from others. > > > > I agree it is worth evaluating. If netdev is being considered, then it > is probably also worth considering your suggestion from a few years back > to add these capabilities by building vsock on top of virtio-net [1]. > > [1] > https://lore.kernel.org/all/2747ac1f-390e-99f9-b24e-f179af79a...@redhat.com/
Yes. I think having a dedicated netdev might be simpler than reusing the virito-net. > > Considering that the current vsock protocol will only ever be able to > enjoy a restricted feature set of these other net subsystems due to its > lack of tolerance for packet loss (e.g., no multiqueue steering, no > packet scheduling), I wonder if it would be best to a) wait until a user > requires these capabilities, and b) at that point extend vsock to tolerate > packet loss (add a seqnum)? Maybe, a question back to this proposal. What's the plan for the userspace? For example, do we expect to extend iproute2 and other and how (e.g having a new vsock dedicated tool)? > > > > > > > Some other thoughts I had: netdev's flow control features would all have > > > to be ignored or disabled somehow (I think dev_direct_xmit()?), because > > > queueing introduces packet loss and the vsock protocol is unable to > > > survive packet loss. > > > > Or just allow it and then configuring a qdisc that may drop packets > > could be treated as a misconfiguration. > > > > That is possible, but when I was playing with vsock qdisc the only one > that worked was pfifo_fast/pfifo, as the others that I tested async drop > packets. I guess it should work with qdiscs with TCQ_F_CAN_BYPASS. Or if it turns out to be hard we can just bypass the qdisc layer as you said. Thanks > > Thanks, > Bobby >
