> On 02.07.2011, at 11:45, 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?
On Sat, Jul 2, 2011 at 2:19 PM, Alexander Graf <agraf@xxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
