* Alexander Graf <[email protected]> wrote:
>
> On 04.07.2011, at 11:11, Ingo Molnar wrote:
>
> >
> > * Alexander Graf <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
