* Pekka Enberg <penberg@xxxxxxxxxx> wrote: > On Fri, 2011-07-01 at 15:46 +0200, Alexander Graf 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 :). > > If we make the buffers large enough, will this matter in practice? > > > > This patch-set turned out to be a *lot* more simple than i first > > > thought it would end up. > > > > > > Simpler also means potentially faster and potentially more secure. > > > > > > ( The lack of ipv6 is not something we should worry about too much, > > > ipv4 should scale up to a couple of hundred thousand virtual > > > machines per box, right? ) > > > > Well, if the system you're trying to connect to supports ipv4, > > sure. If it doesn't, tough luck :). > > Does that mean that the guests would effectively be ipv4-only? > That'd be unfortunate. The guest will effectively be NAT-ed anyway, with it on a private network in essence (where the DHCP server gives a dynamic IP), so it does not matter at all whether it's using ipv4 or ipv6 for its NAT connectivity. ipv6 might matter for TUN-ed connections, where the guest might be visible externally as well. Unless i'm missing some important ipv6 usecase. Also, is there any fundamental reason why ipv6 packets couldnt be recognized with time? So if there's demand, it could be added. 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
