On 04/18/2011 11:05 PM, Arnd Bergmann wrote: > On Monday 18 April 2011, Asias He wrote: >> We do need "guest appearing on the same network as the host" support as >> well. The reason I am considering using macvatp instead of tap plus >> brctl is that it simplifies the bridge configuration and it is more >> efficient. > > Right, you certainly don't need to consider tap/brctl any more. > >> However, IMHO, the interface of macvtap is not user friendly, at least >> for me. I have no idea about the technical reasons that make the >> low-level device inaccessible. But if it is accessible, a lot of >> configuration can be eliminated. I know virtualbox's bridge mode has >> this kind of restriction, while VMware's bridge mode does not. > > The main reason is that having a MAC address scan in the regular > networking core would make the common TX case where there is no > macvlan device more complex. Macvtap is derived from the plain > macvlan driver, which used to support only sending out to the > wire until I added the optional bridge mode. > > If you want a regular device to be able to send to a macvlan > port, that would require at least these changes: > > * Add an option to put a plain device into macvlan-bridge mode > * Add support for that option into iproute2 > * Add a hook into dev_queue_xmit() to check for macvlan ports Cool! Arnd, mind to add this feature to macvtap? -- Best Regards, Asias He -- 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
