Re: [External] Re: [RFC PATCH] virtio-vsock: add description for datagram type

From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Jiang Wang ." <jiang.wang@bytedance.com>
Cc: cong.wang@bytedance.com,
	Xiongchun Duan <duanxiongchun@bytedance.com>,
	cohuck@redhat.com, virtualization@lists.linux-foundation.org,
	xieyongji@bytedance.com, Stefan Hajnoczi <stefanha@redhat.com>,
	Arseny Krasnov <arseny.krasnov@kaspersky.com>,
	asias@redhat.com
Subject: Re: [External] Re: [RFC PATCH] virtio-vsock: add description for datagram type
Date: Mon, 22 Mar 2021 19:10:34 -0400	[thread overview]
Message-ID: <20210322190517-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAP_N_Z-aOds0-DgSYgGLb3AG7kvf=iqmLHojMjh878j8bTBkwg@mail.gmail.com>

On Mon, Mar 22, 2021 at 04:02:14PM -0700, Jiang Wang . wrote:
> After dropping my additional accounting. I think there is still a question
> about if we want to protect the shared dgram virtqueue
> against bad dgram sockets or not. And if so, how to do it, or what to write
> in the spec. For example, if a bad dgram socket keeps sending lots of
> data to a port that no socket is receiving,
> then those packets will only be dropped by the receiver (device or the
> driver), or
> when the virtqueue is full. Other good dgram sockets will compete
> with this bad one on the tx side. In my current implementation, it
> depends on how the Linux scheduler schedules those processes.
> The bad one is unlikely to make the virtqueue full all the time and
> completely block
> other good dgram sockets because the other end is still receiving and
> cleaning the virtqueue. But it will waste a lot of resources. I think
> that is fine and we don't need to add strict requirements about it
> in the spec.
> 
> I don't know if UDP has a similar situation as shared virtqueue or not. The
> net.ipv4.udp_mem looks like just a global accounting. If you have any
> suggestions about this, please let me know.
> 
> Thank you!

Yes I suspect just not doing any accounting isn't going to work well.
Consider that with a NIC, if a socket is sending too much data faster
than destination can consume it, its packets get dropped. So far so
good.

With vsock, if your guest gets too fast, packets are being dropped
which is faster than processing them on the host.
The result is guest goes even faster!

Used to be a problem on linux too before packets inside transmit
queues started being accounted for: a socket would fill
the tx queue then others would just drop their packets.

So we need some kind of accounting to slow down transmitters when
they go too fast, to avoid this kind of positive feedback.

-- 
MST

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization