On Thu, Jul 18, 2019 at 07:35:46AM -0400, Michael S. Tsirkin wrote:
On Thu, Jul 18, 2019 at 11:37:30AM +0200, Stefano Garzarella wrote:I checked the code better, but it doesn't seem to do that.
On Thu, Jul 18, 2019 at 10:13 AM Michael S. Tsirkin<mst@xxxxxxxxxx> wrote:I think you mean the reverse: even without credits you can copy from
On Thu, Jul 18, 2019 at 09:50:14AM +0200, Stefano Garzarella wrote:Honestly, I don't know the exact reasons for this design, but I suppose
On Wed, Jul 17, 2019 at 4:55 PM Michael S. Tsirkin<mst@xxxxxxxxxx> wrote:Got it. Using workers for xmit is IMHO a bad idea btw.
On Wed, Jul 17, 2019 at 01:30:29PM +0200, Stefano Garzarella wrote:Before this series, the 64K (or bigger) user messages was split in 4K packets
If the packets to sent to the guest are bigger than the bufferSo how does it work right now? If an app
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>
does sendmsg with a 64K buffer and the other
side publishes 4K buffers - does it just stall?
(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)
Why is it done like this?
that the idea was to have only one worker that uses the vring, and
multiple user threads that enqueue packets in the list.
This can simplify the code and we can put the user threads to sleep if
we don't have "credit" available (this means that the receiver doesn't
have space to receive the packet).
user and queue up data, then process it without waking up the user
The .sendmsg callback of af_vsock, check if the transport has space
(virtio-vsock transport returns the credit available). If there is no
space, it put the thread to sleep on the 'sk_sleep(sk)' wait_queue.
When the transport receives an update of credit available on the other
peer, it calls 'sk->sk_write_space(sk)' that wakes up the thread
sleeping, that will queue the new packet.
So, in the current implementation, the TX worker doesn't check the
credit available, it only sends the packets.
Does it help though? It certainly adds up work outside ofI can try to xmit the packet directly in the user thread context, to see
user thread context which means it's not accounted for
Maybe we want more VQs. Would help improve parallelism. The questionYes, more VQs can help but the map question is not simple to answer.
would then become how to map sockets to VQs. With a simple hash
it's easy to create collisions ...
Maybe we can do an hash on the (cid, port) or do some kind of estimation
of queue utilization and try to balance.
Should the mapping be unique?