[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111130210454.GC29071@x200.localdomain>
Date: Wed, 30 Nov 2011 13:04:54 -0800
From: Chris Wright <chrisw@...hat.com>
To: Ben Hutchings <bhutchings@...arflare.com>
Cc: Greg Rose <gregory.v.rose@...el.com>,
Roopa Prabhu <roprabhu@...co.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"chrisw@...hat.com" <chrisw@...hat.com>,
"sri@...ibm.com" <sri@...ibm.com>,
"dragos.tatulea@...il.com" <dragos.tatulea@...il.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"arnd@...db.de" <arnd@...db.de>, "mst@...hat.com" <mst@...hat.com>,
"mchan@...adcom.com" <mchan@...adcom.com>,
"dwang2@...co.com" <dwang2@...co.com>,
"shemminger@...tta.com" <shemminger@...tta.com>,
"eric.dumazet@...il.com" <eric.dumazet@...il.com>,
"kaber@...sh.net" <kaber@...sh.net>,
"benve@...co.com" <benve@...co.com>
Subject: Re: [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering
support for passthru mode
* Ben Hutchings (bhutchings@...arflare.com) wrote:
> On Wed, 2011-11-30 at 09:34 -0800, Greg Rose wrote:
> > On 11/29/2011 9:19 AM, Ben Hutchings wrote:
> > > On Tue, 2011-11-29 at 16:35 +0000, Ben Hutchings wrote:
> > >>
> > >> Maybe I missed something!
> [...]
> > >> If not, please explain what the new model *is*.
> >
> > The new model is to incorporate a VEB into the NIC. The current model
> > doesn't address any of the requirements of a VEB in the NIC and this
> > proposed set of patches allow us to set MAC filters for the *ports* on
> > the internal NIC VEB. Consider the PF and each of the VFs as just a
> > port on the VEB. We need the ability to set L2 filters (MAC, MC and
> > VLAN) for each of the ports on that VEB. There is no currently
> > supported method for doing this. So yes, this is a new model although
> > it's a fairly simple one.
>
> Explain precisely how the VEB changes the existing model. Explain how
> the existing MAC filter and VF filter APIs interact with port filters on
> the VEB. Refer to any relevant standards.
I agree that it's confusing. Couldn't you simplify your ascii art
(hopefully removing hw assumptions about receive processing, and
completely ignoring vlans for the moment) to something like:
|RX
v
+------------+-------------+
| +------+--------+ |
| | RX MAC filter | |
| |and port select| |
| +---------------+ |
| /|\ |
| / | \ match 2|
| / v \ |
| /match \ |
| / 1 | \ |
| / | \ |
|match / | \ |
| 0 / | \ |
| v | v |
| | | | |
+----+--------+--------+---+
| | |
PF VF 1 VF 2
And there's an unclear number of ways to update "RX MAC filter and port
select" table.
1) PF ndo_set_mac_addr
I expect that to be implicit to match 0.
2) PF ndo_set_rx_mode
Less clear, but I'd still expect these to implicitly match 0
3) PF ndo_set_vf_mac
I expect these to be an explicit match to VF N (given the interface
specifices which VF's MAC is being programmed).
4) VF ndo_set_mac_addr
This one may or may not be allowed (setting MAC+port if the VF is owned
by a guest is likely not allowed), but would expect an implicit VF N.
5) VF ndo_set_rx_mode
Same as 4) above.
6) PF or VF? ndo_set_rx_filter_addr
The new proposal, which has an explicit VF, although when it's VF_SELF
I'm not clear if this is just the same as 5) above?
Have I missed anything?
thanks,
chris
--
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