Jiang Wang .
2021-Mar-23 02:23 UTC
[External] Re: [RFC PATCH] virtio-vsock: add description for datagram type
Got it. Will do. On Mon, Mar 22, 2021 at 4:10 PM Michael S. Tsirkin <mst at redhat.com> wrote:> > 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 >
Stefan Hajnoczi
2021-Mar-23 08:53 UTC
[External] Re: [RFC PATCH] virtio-vsock: add description for datagram type
On Mon, Mar 22, 2021 at 07:23:14PM -0700, Jiang Wang . wrote:> Got it. Will do.You could look at udp_sendmsg() to see how sockets compete when transmitting to the same net device. I'm not very familiar with this but I guess that the qdisc (like fq_codel) decides which packets to place into the device's tx queue. I guess sk_buffs waiting to be put onto the device's tx queue are accounted for against the socket's sndbuf. Further sendmsg calls will fail with -ENOBUFS when the sndbuf limit is reached. It's not clear to me how much of the existing code can be reused since vsock does not use sk_buff or netdev :(. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20210323/26113a0b/attachment-0001.sig>