On 03.07.2011, at 21:42, Ingo Molnar wrote: > > * Alexander Graf <agraf@xxxxxxx> wrote: > >>> That's pretty impressive (if it does not come at the expensive of >>> features that Qemu's slirp code has) - and the thing is that we >>> don't actually have to implement the vast majority of TCP-IP >>> features, because the transport between the guest and the host is >>> obviously reliable. >> >> 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? 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
