On Tue, Mar 11, 2025 at 08:59:44AM +0800, Jason Wang wrote: > On Tue, Mar 11, 2025 at 4:14 AM Bobby Eshleman <bobbyeshleman@xxxxxxxxx> 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 <bobbyeshleman@xxxxxxxxx> 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@xxxxxxxxxx/ > > 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)? > If we were going to add a seqnum and start bringing in other systems, we would probably want to add support into iproute2. For example, when I played with qdisc, using ip seemed like the best from the user side. The iproute2 changes weren't bad at all[1]. We'd probably need the device to carry a new feature bit too. That said, all of this still creates the problem of adding new system-level ways to disrupt AF_VSOCK users. I think we could offer this in a way that is orthogonal to prior vsock, possibly AF_VSOCK2, a sockopt, or ioctl to opt-in to using net features... so that we aren't violating commitment to existing users that vsock should work regardless of network configuration? letting the user that holds the fd of the socket make the choice might be the best way to safeguard the contract? [1]: https://github.com/beshleman/iproute2/commit/55fd8a6c133335cda4ede6f8928eb3cea54534b8 Best, Bobby
