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

[Roopa Prabhu <roprabhu@cisco.com>]

On 2/3/12 7:32 AM, "Roopa Prabhu" <roprabhu@cisco.com> wrote:

> 
> 
> 
> On 2/2/12 10:58 AM, "John Fastabend" <john.r.fastabend@intel.com> wrote:
<snip>..

>> Are you sure they will be good to have? I'm  not so sure you want to be
>> able to manipulate the uc and mc tables from user space. MACVLAN seems to
>> be one type of device where it is useful but doing this to a PF or VF seems
>> hard to use for any real use case. Fun to test the embedded bridge though.
>> 
> 
> I wont say I am sure. Would be nice have to have netlink interfaces to
> ADD/DEL additional uc, mc addrs, filter flags and vlans. I have looked at
> the existing interfaces and nothing seemed straightforward then. But I
> forget and need to take a look again.
> I think vlans and filter flags is somehow possible today. And maybe mc too.
> But if I am right we don't have a way to add additional unicast addresses
> from userspace. 
> 
> I will dig my notes and try and list down the problems with using the
> existing netlink interfaces for this.

There are kernel api's/ops to add/del hw uc/mc/vlan/filter filter flags:
Ndo_set_rx_mode, add/del_vid, dev_uc_add, dev_mc_add and dev_filter_flags.

But there are no straight forward mechanisms to add these from userspace. L2
mc addresses can be added by SIOCADDMULTI. And filter flags maybe via
netlink. Nothing for uc and vlan as far as I know (correct me if I am
wrong). Setting of hw filters is usually done indirectly by the kernel
during creation of vlan devices for example.

There is a netlink msg to create a vlan device. But there is no way to add a
vlan filter directly to the hw. Nothing for secondary uc addrs.
This is ok for all cases except for the virtualization case I am trying to
solve. 

To summarize,

The requirement is to have a mechanism from userspace to populate hw filters
on a device. And this is required to program guest nic filters into the host
device backing the guest nic. In the direct attach case, its the macvtap
device and in turn the macvtap lower device.

Today I cant think of any other use case that would require this (except
that there is a brief chance that this could be used in the hybrid
acceleration stuff that ben and intel have been discussing).

I see the below ways this can be done:
1) TUNSETTXFILTER: My v1 patch, that targets only the above specific macvtap
problem. This works for only uc/mc and flags filter. Possibly requires a new
cmd TUNSETVLANFILTER for vlan filters.


2) rtnetlink ops for setting hw filters: My v2 patch targeting virtual
devices that implement rtnl_link_ops. Example macvtap/macvlan

This netlink interface to set filters follows TUNSETTXFILTER giving the
ability to set filters on these devices. The netlink payload must contain
all the uc, mc, vid's and filter flags that go on the device.


3) netdev_ops for setting hw filters: my v3 and v4 patches. This is same as
2 but moves the ops to netdev, so that it can be used by all devices if
required.


4) v5 (New approach. Not submitted yet):
In 2 and 3 above, the netlink msg could be broken down to have separate msgs
to support add/del of uc/mc/vlan. This should be close to what we have today
for vf vlan and vf mac. (Something similar to what John Fastabend was
suggesting too). Advantage, use existing hw ops. (This slightly varies from
the original goal which was not targeted at getting in to uc,mc lists alone.
The goal was to have macvlan maintain its own filters and use it in fwding
lookups if needed in the future. But I guess if we need this in the future
we could possibly use the macvlan uc, mc lists.)


Netlink msgs to set hw filters (basically for dev_uc_add/del,
dev_mc_add/del, and vlans). The below is not a final cut. Just attempting
something here. Please comment.

[IFLA_FILTER_ADDR] = {
    [IFLA_FILTER_ADD_ADDR] = {
        [IFLA_FILTER_HWADDR]      // Maybe a list here
    }

    [IFLA_FILTER_DEL_ADDR] = {
        [IFLA_FILTER_HWADDR]    // Maybe a list here
    }
}

[IFLA_FILTER_VLAN] = {
    [IFLA_FILTER_ADD_VLAN] = {
        [IFLA_FILTER_VID]          // Maybe a list here too
    }
    [IFLA_FILTER_DEL_VLAN] = {
        [IFLA_FILTER_VID] // Maybe a list here too
    }
}



No additional ops, these will call the dev_uc_add/del and add/del_vid api's
directly.

If people think this might be a better way to go, I can work up a patch for
this.

Or if anyone thinks we can use something existing please let me know.

Again, this is needed for passing guest filters in the virtualization case.
I don't see a need to add support for this in iproute2 too (unless anyone
thinks otherwise)

[Note1: Since the addr is a resource and multiple adds/dels are handled by
reference counts, a thread can really call delete multiple times and delete
all references of a particular addr even if he had not owned it. But this is
possible even with existing code today I think. Except that today the kernel
does not expose an interface to do this to userspace

Note2: We probably will need one for filter flags as well. I am still
thinking maybe we can use an existing interface for that. For symmetry a
IFLA_FILTER_FLAGS would be nice]



Comments ?
Thanks,
Roopa