On Thu, Jul 18, 2019 at 09:50:14AM +0200, Stefano Garzarella wrote: > On Wed, Jul 17, 2019 at 4:55 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > > On Wed, Jul 17, 2019 at 01:30:29PM +0200, Stefano Garzarella wrote: > > > If the packets to sent to the guest are bigger than the buffer > > > available, we can split them, using multiple buffers and fixing > > > the length in the packet header. > > > This is safe since virtio-vsock supports only stream sockets. > > > > > > Signed-off-by: Stefano Garzarella <sgarzare@xxxxxxxxxx> > > > > So how does it work right now? If an app > > does sendmsg with a 64K buffer and the other > > side publishes 4K buffers - does it just stall? > > Before this series, the 64K (or bigger) user messages was split in 4K packets > (fixed in the code) and queued in an internal list for the TX worker. > > After this series, we will queue up to 64K packets and then it will be split in > the TX worker, depending on the size of the buffers available in the > vring. (The idea was to allow EWMA or a configuration of the buffers size, but > for now we postponed it) Got it. Using workers for xmit is IMHO a bad idea btw. Why is it done like this? > Note: virtio-vsock only supports stream socket for now. > > Thanks, > Stefano
