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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
