Re: [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering support for passthru mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux