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