Re: Raw vs. tap

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Oct 15, 2009 at 05:48:19PM +0200, Michael S. Tsirkin wrote:
> On Thu, Oct 15, 2009 at 10:18:18AM -0500, Anthony Liguori wrote:
> > Michael S. Tsirkin wrote:
> >> On Thu, Oct 15, 2009 at 08:32:03AM -0500, Anthony Liguori wrote:
> >>   
> >>> Michael S. Tsirkin wrote:
> >>>     
> >>>> On Wed, Oct 14, 2009 at 05:53:56PM -0500, Anthony Liguori wrote:
> >>>>         
> >>>>> I would be much more inclined to consider  taking raw and 
> >>>>> improving the performance long term if guest<->host  networking 
> >>>>> worked.  This appears to be a fundamental limitation though  and 
> >>>>> I think it's something that will forever plague users if we 
> >>>>> include  this feature.
> >>>>>             
> >>>> In fact, I think it's fixable with a raw socket bound to a macvlan.
> >>>> Would that be enough?
> >>>>         
> >>> What setup does that entail on the part of a user?  Wouldn't we be 
> >>> back  to square one wrt users having to run archaic networking 
> >>> commands in  order to set things up?
> >>>     
> >>
> >> Unlike bridge, qemu could set up macvlan without disrupting
> >> host networking. The only issue would be cleanup if qemu
> >> is killed.
> >>   
> >
> > But this would require additional features in macvlan, correct?
> 
> Not sure: what is the "this" that you are talking about.
> It can already be set up without disturbing host networking.
> 
> > This also only works if a guest uses the mac address assigned to it,  
> > correct?  If a guest was bridging the virtual nic, this would all come  
> > apart?
> 
> Hmm, you could enable promisc mode, but generally this is true:
> if you require bridging, use a bridge.

Just to clarify this statement: if bridge in guest does not
configure mac filtering on guest uplink (linux
bridge by default does not do this now, OTOH macvlan does),
bridge in host will perform better in this setup
because it learns macs from traffic and does mac filtering in host.

> > Regards,
> >
> > Anthony Liguori