* 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'.
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
