On 04.07.2011, at 11:11, Ingo Molnar wrote: > > * 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'. I see. Can you guarantee that other guests (in case that ever gets implemented) behave the same? Alex -- 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
