On 01.07.2011, at 13:53, Ingo Molnar wrote:
>
> * Asias He <asias.hejun@xxxxxxxxx> wrote:
>
>>> Usermode TCP/IP can be quite cumbersome for users as things like
>>> ping and ip6 won't work properly.
>>
>> Yes, usermode TCP/IP do have limits. But it's more cumbersome for
>> user to setup bridge/nat thing with privileged networking. The
>> network setup is a headache for some users.
>
> That group of 'some users' includes me for example.
>
> The thing is, when i test an existing distro image there's better
> things to do with my time than to figure out that year's preferred
> method of configuring the network and troubleshooting it if it goes
> wrong. So having zero-config networking (assuming we grow some DHCP
> capability as well) would be a real plus.
>
>> This patchset implements things like 'qemu -net user' without the
>> slirp.
>>
>> I just took at a look the LOC in qemu and uip.
>>
>> qemu.git$ cat slirp/*.{c,h} net/slirp.{c,h}| wc -l
>> 11514
>>
>> kernel.git/tools/kvm$ cat uip/*.{c,h} include/kvm/uip.h | wc -l
>> 1312
>
> 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 :).
> 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 :).
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
