Re: [PATCH net-next 0/3] vsock: support network namespace

[Bobby Eshleman <bobbyeshleman@gmail.com>]

On Wed, Mar 05, 2025 at 01:46:54PM +0800, Jason Wang wrote:
> On Wed, Mar 5, 2025 at 8:39 AM Bobby Eshleman <bobbyeshleman@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-f179af79a9da@redhat.com/

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)?

> >
> > 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.

Thanks,
Bobby