Am 02.07.2011 um 13:27 schrieb Pekka Enberg <[email protected]>:
>> 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. Interesting. I wouldn't want to ship code like that to paying customers :) > >> 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. I think we're talking about different buffers :) > >>>>> 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. Yup, and for now for most users ipv4 only is good enough. It's really just something to keep in mind. We already are exceeding ipv4 address space - and it's pretty hard to access an ipv6 server address from ipv4. But we have the same issue in slirp. Alex > -- 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
