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

On Wed, 2011-11-30 at 13:04 -0800, Chris Wright wrote:

* Ben Hutchings (bhutchings@solarflare.com) wrote:

quoted

On Wed, 2011-11-30 at 09:34 -0800, Greg Rose wrote:

quoted

On 11/29/2011 9:19 AM, Ben Hutchings wrote:

quoted

On Tue, 2011-11-29 at 16:35 +0000, Ben Hutchings wrote:

quoted

Maybe I missed something!

[...]

quoted

quoted

quoted

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

I'm not sure whether this is supposed to implicitly add to the MAC
filter or whether that has to be changed too.  That's the main
difference between my models (a) and (b).

There's also PF ndo_set_vf_vlan.

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.

So this is where we are today.

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?

Any physical port can be bridged to a mixture of guests with and without
their own VFs.  Packets sent from a guest with a VF to the address of a
guest without a VF need to be forwarded to the PF rather than the
physical port, but none of the drivers currently get to know about those
addresses.

Packets sent from a guest with a VF to the address of another guest with
a VF need to be forwarded similarly, but the driver should be able to
infer that from (3).

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.