netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 16:35:44 +0000	[thread overview]
Message-ID: <1322584544.2684.20.camel@bwh-desktop> (raw)
In-Reply-To: <4ECA8D50.9080603@intel.com>

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):

                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 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.


  reply	other threads:[~2011-11-29 16:35 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 [this message]
2011-11-29 17:19               ` Ben Hutchings
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=1322584544.2684.20.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).