From: Ben Hutchings <bhutchings@solarflare.com>
To: Greg Rose <gregory.v.rose@intel.com>
Cc: Roopa Prabhu <roprabhu@cisco.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"chrisw@redhat.com" <chrisw@redhat.com>,
"sri@us.ibm.com" <sri@us.ibm.com>,
"dragos.tatulea@gmail.com" <dragos.tatulea@gmail.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"arnd@arndb.de" <arnd@arndb.de>,
"mst@redhat.com" <mst@redhat.com>,
"mchan@broadcom.com" <mchan@broadcom.com>,
"dwang2@cisco.com" <dwang2@cisco.com>,
"shemminger@vyatta.com" <shemminger@vyatta.com>,
"eric.dumazet@gmail.com" <eric.dumazet@gmail.com>,
"kaber@trash.net" <kaber@trash.net>,
"benve@cisco.com" <benve@cisco.com>
Subject: Re: [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering support for passthru mode
Date: Tue, 29 Nov 2011 17:19:30 +0000 [thread overview]
Message-ID: <1322587170.2684.26.camel@bwh-desktop> (raw)
In-Reply-To: <1322584544.2684.20.camel@bwh-desktop>
On Tue, 2011-11-29 at 16:35 +0000, Ben Hutchings wrote:
> On Mon, 2011-11-21 at 09:41 -0800, Greg Rose wrote:
> > On 11/18/2011 9:40 AM, Ben Hutchings wrote:
> [...]
> > > What concerns me is that this seems to be a workaround rather than a fix
> > > for over-use of promiscuous mode, and it changes the semantics of
> > > filtering modes in ways that haven't been well-specified.
> >
> > I feel the opposite is true. It allows a known set of receive filters
> > so that you don't have to use promiscuous mode, which cuts down on
> > overhead from processing packets the upper layer stack isn't really
> > interested in.
> >
> > >
> > > What if there's a software bridge between two net devices corresponding
> > > to separate physical ports, so that they really need to be promiscuous?
> > > What if the administrator runs tcpdump and really wants the (PF) net
> > > device to be promiscuous?
> >
> > I don't believe there is anything in this patch set that removes
> > promiscuous mode operation as it is commonly used. Perhaps I've missed
> > something.
> [...]
>
> Maybe I missed something!
>
> Let's be clear on what our models are for filtering. At the moment we
> have MAC filters set through ndo_set_rx_mode and VF filters set through
> ndo_set_vf_{mac,vlan}.
>
> Ignoring anti-spoofing for the moment, should the currently defined
> filters look like this (a):
>
> TX ^ | RX
> | v
> +------------------+---+-----------------+
> | | ++------------+ |
> | | |RX MAC filter| |
> | | ++------------+ |
> | | |match |
> | ^ v |
> | | ++------------+ |
> | | |RX VF filters| |
> | | +-------+-----+ |
> | /|\ no /|\ |
> | | | \ match/ | |match 2 |
> | | ^ \ / v | |
> | | | \ /match| |
> | | \ \/ 1/ | |
> | | \ /\ / | |
> | ^ \/ \/ v |
> | | /\ /\ | |
> | | / || \ | |
> | | / || \ | |
> | | / || \ | |
> | || || || |
> +----------------++-----++-----++--------+
> || || ||
> PF VF 1 VF 2
>
> or like this (b):
>
> TX ^ | RX
> | v
> +------------------+---+-----------------+
> | | ++------------+ |
> | | |RX VF filters| |
> | | ++--------+---+ |
> | | no|match /| |
> | ^ v | | |
> | | +-+----+ | | |
> | | |RX MAC| | | |
> | | |filter| | | |
> | | +------+ | | |
> | | |match | | |
> | /|\ | | | |
> | | | \ | match| |match 2 |
> | | ^ \/ 1 v | |
> | | | /\ | | |
> | | \/ \ / | |
> | | /\ \ / | |
> | ^ / \ \/ v |
> | || \ /\ | |
> | || || \ | |
> | || || \ | |
> | || || \ | |
> | || || || |
> +----------------++-----++-----++--------+
> || || ||
> PF VF 1 VF 2
>
> I think the current model is (a); do you agree?
>
> So is the proposed new model something like this (c):
Corrected diagram:
TX ^ | RX
| v
+------------------+---+-----------------+
| | ++------------+ |
| | |RX MAC filter| |
| ^ ++------------+ |
| | |match |
| no match| v |
| +----------------+ ++------------+ |
| |loopback filters| |RX VF filters| |
| +---------+-----++ +-------+-----+ |
| /|\ /|\ match /|\ |
| v | `-+>+-+-.2 / | | |
| \ \ | |m \ \ / | | |
| match 0\ `-+-+.a \ \ / v | |
| \ | | \t \ X / | |
| \ | \ \c X \ / | |
| \| \ \h \ X | |
| \ \/\1 X \ v |
| || /\ |/ \ \ | |
| |v / || \ \| |
| || / ^| \ | |
| ||/ |v || |
| || || || |
+----------------++-----++-----++--------+
|| || ||
PF VF 1 VF 2
> (I've labelled the new filters as loopback filters here, and I'm still
> leaving out anti-spoofing.)
>
> If not, please explain what the new model *is*.
>
> Ben.
>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2011-11-29 17:19 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-09 7:55 [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering support for passthru mode Roopa Prabhu
2011-11-09 7:55 ` [net-next-2.6 PATCH 1/6 v4] rtnetlink: Netlink interface for setting MAC and VLAN filters Roopa Prabhu
2011-11-18 0:17 ` Ben Hutchings
2011-11-09 7:55 ` [net-next-2.6 PATCH 2/6 v4] net: Add netdev_ops to set and get MAC/VLAN rx filters Roopa Prabhu
2011-11-09 7:55 ` [net-next-2.6 PATCH 3/6 v4] rtnetlink: Add support to set MAC/VLAN filters Roopa Prabhu
2011-11-09 7:55 ` [net-next-2.6 PATCH 4/6 v4] rtnetlink: Add support to get " Roopa Prabhu
2011-11-09 7:56 ` [net-next-2.6 PATCH 5/6 v4] macvlan: Add support to for netdev ops to set " Roopa Prabhu
2011-11-09 7:56 ` [net-next-2.6 PATCH 6/6 v4] macvlan: Add support to get MAC/VLAN filter netdev ops Roopa Prabhu
2011-11-18 0:15 ` [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering support for passthru mode Ben Hutchings
2011-11-18 0:32 ` Greg Rose
2011-11-18 0:44 ` Ben Hutchings
2011-11-18 16:58 ` Greg Rose
2011-11-18 17:40 ` Ben Hutchings
2011-11-21 17:41 ` Greg Rose
2011-11-29 16:35 ` Ben Hutchings
2011-11-29 17:19 ` Ben Hutchings [this message]
2011-11-30 17:34 ` Greg Rose
2011-11-30 18:48 ` Ben Hutchings
2011-11-30 21:04 ` Chris Wright
2011-11-30 21:34 ` Ben Hutchings
2011-11-30 23:00 ` Chris Wright
2011-11-30 23:19 ` Rose, Gregory V
2011-11-30 23:30 ` Sridhar Samudrala
2011-11-30 23:39 ` Chris Wright
2011-11-20 16:30 ` Roopa Prabhu
2012-02-02 7:24 ` Michael S. Tsirkin
2012-02-02 8:46 ` John Fastabend
2012-02-02 8:50 ` Michael S. Tsirkin
2012-02-02 9:04 ` John Fastabend
2012-02-02 18:07 ` Roopa Prabhu
2012-02-02 18:58 ` John Fastabend
2012-02-03 15:32 ` Roopa Prabhu
2012-02-05 16:54 ` Roopa Prabhu
2012-02-09 2:03 ` John Fastabend
2012-02-02 20:38 ` Ben Hutchings
2012-02-02 21:18 ` John Fastabend
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1322587170.2684.26.camel@bwh-desktop \
--to=bhutchings@solarflare.com \
--cc=arnd@arndb.de \
--cc=benve@cisco.com \
--cc=chrisw@redhat.com \
--cc=davem@davemloft.net \
--cc=dragos.tatulea@gmail.com \
--cc=dwang2@cisco.com \
--cc=eric.dumazet@gmail.com \
--cc=gregory.v.rose@intel.com \
--cc=kaber@trash.net \
--cc=kvm@vger.kernel.org \
--cc=mchan@broadcom.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=roprabhu@cisco.com \
--cc=shemminger@vyatta.com \
--cc=sri@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).