On Mon, Apr 08, 2019 at 05:17:35PM +0200, Stefano Garzarella wrote: > On Mon, Apr 08, 2019 at 10:57:44AM -0400, Michael S. Tsirkin wrote: > > On Mon, Apr 08, 2019 at 04:55:31PM +0200, Stefano Garzarella wrote: > > > > Anyway, any change to this behavior requires compatibility so new guest > > > > drivers work with old vhost_vsock.ko. Therefore we should probably just > > > > leave the limit for now. > > > > > > I understood your point of view and I completely agree with you. > > > But, until we don't have a way to expose features/versions between guest > > > and host, > > > > Why not use the standard virtio feature negotiation mechanism for this? > > > > Yes, I have this in my mind :), but I want to understand better if we can > use virtio-net also for this mechanism. > For now, I don't think limiting the packets to 64 KiB is a big issue. > > What do you think if I postpone this when I have more clear if we can > use virtio-net or not? (in order to avoid duplicated work) Yes, I agree. VIRTIO has feature negotiation and we can use it to change this behavior cleanly. However, this will require a spec change and this patch series delivers significant performance improvements that can be merged sooner than VIRTIO spec changes. Let's defer the max packet size change via VIRTIO feature bits. It can be done separately if we decide to stick to the virtio-vsock device design and not virtio-net. Stefan
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
