* Alexander Graf <agraf@xxxxxxx> wrote: > > 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? Do you mean can i remove 100% of fear, uncertainty and doubt about an unknown 'black box' guest OS? No. But the queueing logic of TCP/IP stacks is pretty similar in practice so i'd be very surprised if Windows (which i guess you must be referring to) dropped packets due to TX overflow. It would be very stupid to drop packets on TX: the sending stack has to buffer the TCP stream *anyway* (and has no choice about that, the app cannot resend the socket data), so it achieves nothing from dropping the packet and adding resend complexity to itself. 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
