[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC: the plan for the project network virtualization

From: zhengda
Subject: Re: GSoC: the plan for the project network virtualization
Date: Thu, 26 Jun 2008 23:11:12 +0200
User-agent: Thunderbird (X11/20080421)

olafBuddenhagen@gmx.net wrote:
"root could delegate access to the real network interface, and the
user  could run a hypervisor"? How do we do it? create another program
that is run by root and that  communicates with the hypervisor?

To be honest, I don't know the details. In a capability system, it
should always be trivial to delegate access to something. But I do fear
that the Mach device interface does not really fit there -- that it's
not possible to directly hand out a capability for a single kernel

If that is the case, we would again need a proxy for the master device
port, which would forward open() on the network device, but block all
Do you mean something like a translator who open the network interface, and returns the port of the network interface to the socket server such as pfinet?
If you mean keeping the original idea of a hypervisor that does provide
several virtual interfaces *and* enforces policies on each, then no,
this is not more flexible. It is a monolithic beast combining different,
mostly unrelated functionalities. It is un-hurdish; and it can never be
more flexible than individual components that can be combined as
I agree.
The only disadvantage of separate components is that the packets may
need to traverse more servers before they arrive. But, as explained on
IRC, this probably could be optimized with some BPF magic, if it turns
out to be a serious problem.
Last time on IRC, if I understand it correctly, you said the optimization is to make all packets go through the kernel, and the kernel dispatches the packet with the BPF. Now the multiplexer actually works just as the multiplexer (if the part for the network IO in the kernel can be called a multiplexer) except the filtering function is separated. I really don't think it's necessary to make the packet to go through the kernel. But if the multiplexer is responsible to dispatch the packet, I think we go to the original idea (the hypervisor).

By the way, is it possible to provide a mechanism that allows two components to only share the virtual memory (the user of the components can make the choice: to share the memory or not)? maybe it's a bit like the clone with the flag of CLONE_VM in Linux. If it's possible, I think it can much improve the performance issue above. But it's just my imagination.

Zheng Da

reply via email to

[Prev in Thread] Current Thread [Next in Thread]