> On 02.07.2011, at 11:45, Pekka Enberg <[email protected]> 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?
On Sat, Jul 2, 2011 at 2:19 PM, Alexander Graf <[email protected]> wrote: > Would you trust a system based on statistics? :) Yes, absolutely, for my particular use cases (unless the odd out cases crash my computer and eat my data). The question is if we can make it good enough as a sensible default for most users or not. > Also, I'm not sure you can easily change the size of the buffers. If your > emulated network adapter has a buffer of n bytes for sg lists, that's what > you get. No more, no less. I simply meant making the buffers large enough when we set everything up. >>>> 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. > > Well, for starters, yeah. Unless you also implement ipv6 in the user > networking or add networking support an osi level below (tap, macvtap, ...). > > User networking is great for quick testing, but it's by no means able to > replace network forwarding on the link layer. It's really a matter of use > cases. Just imagine you want to use kvm-tool to test an ipx/spx stack :). You can use the existing tap support for that no? I don't think we should attempt to cover *everything* with our userspace IP stack, not for 'power users' anyway. Pekka -- 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
