[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120410143500.GD19556@redhat.com>
Date: Tue, 10 Apr 2012 17:35:00 +0300
From: "Michael S. Tsirkin" <mst@...hat.com>
To: John Fastabend <john.r.fastabend@...el.com>
Cc: roprabhu@...co.com, stephen.hemminger@...tta.com,
davem@...emloft.net, hadi@...erus.ca, bhutchings@...arflare.com,
jeffrey.t.kirsher@...el.com, netdev@...r.kernel.org,
gregory.v.rose@...el.com, krkumar2@...ibm.com, sri@...ibm.com
Subject: Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new
macvlan mode
On Tue, Apr 10, 2012 at 07:25:58AM -0700, John Fastabend wrote:
> > Hmm okay, but this would mean we should convert
> > MACVLAN_MODE_PASSTHRU_NOPROMISC to something
> > that can combined with all modes. E.g.
> > MACVLAN_MODE_BRIDGE | MACVLAN_MODE_FLAG_XXXXX
> >
> > and document that it does not promise to flood
> > multicast.
> >
>
> How about changing MACVLAN_MODE_PASSTHRU_NOPROMISC -> MACVLAN_MODE_NOPORMISC
> for this patch. Then a follow on series can rework bridge
> and VEPA to use it as well.
Right. We probably need a better name if it's going to
affect other things besides promisc though.
> >> If you want
> >> the flood behavior you can create it by adding the addr to all
> >> the devices or just to a subset of them to get the non-flooding
> >> capabilities.
> >>
> >> .John
> >
> > BTW we seem to try to flood in pass-through too, not sure why.
> >
>
> Suppose your looking at macvlan_handle_frame()? It does
> seem unneeded.
>
> .John
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists