* Alexander Graf <agraf@xxxxxxx> wrote: > >> I don't see how it would. Once you overrun device buffers, you > >> have to do something. Either you drop packets or you stall the > >> guest. I'd usually prefer the former :). > > > > What scenario do you see where we'd have to drop packets? > > > > When the guest sends packets, we send them over to the host TCP > > socket - no blocking. > > When the guest sends packets, I'd hope you have 2 threads: > > * vcpu > * virtio network queue process > > So those two run in parallel now, with the network queue processing > packets while the vcpu pushes packets into the ring. What if the > network thread is slower than the vcpu fills the ring? You only > have so many entries in a vring. > > > When the host receives packets it should only read data out of > > the host socket(s) if the vring buffer suggests that there's > > space available. > > I agree :). > > > So i don't see we'd need to drop packets or block things - we > > just have to react to packets and to vring space availability in > > a straightforward way. > > Well, the only way for the sending path is to stall the vcpu, > otherwise the guest figures "oh, I can't push packets into the > vring, let's just drop it", no? No, that's not how the Linux TCP/IP implementation works. Filled up TX rings are pretty normal on physical hardware: we do not drop packets but the TCP state machine keeps buffering and filling the device as it can. The same will happen with virtual guests as well - there's no packet dropping nor 'blocking of the whole guest'. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
