Re: GSoC: the plan for the project network virtualization

[zhengda]

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
> device.
>
> 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
> others.
>   
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
> necessary.
>   
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.

Best,
Zheng Da