Got it. Will do. On Mon, Mar 22, 2021 at 4:10 PM Michael S. Tsirkin <mst@xxxxxxxxxx> 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 > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
