Re: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering support for passthru mode

[Roopa Prabhu <roprabhu@cisco.com>]

On 10/20/11 1:43 PM, "Rose, Gregory V" <gregory.v.rose@intel.com> wrote:

>> -----Original Message-----
>> From: Roopa Prabhu [mailto:roprabhu@cisco.com]
>> Sent: Wednesday, October 19, 2011 3:30 PM
>> To: Rose, Gregory V; netdev@vger.kernel.org
>> Cc: sri@us.ibm.com; dragos.tatulea@gmail.com; arnd@arndb.de;
>> kvm@vger.kernel.org; mst@redhat.com; davem@davemloft.net;
>> mchan@broadcom.com; dwang2@cisco.com; shemminger@vyatta.com;
>> eric.dumazet@gmail.com; kaber@trash.net; benve@cisco.com
>> Subject: Re: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address
>> filtering support for passthru mode
>> 
>> 
>> 
>> 
>> On 10/19/11 2:06 PM, "Rose, Gregory V" <gregory.v.rose@intel.com> wrote:
>> 
>>>> -----Original Message-----
>>>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org]
>>>> On Behalf Of Roopa Prabhu
>>>> Sent: Tuesday, October 18, 2011 11:26 PM
>>>> To: netdev@vger.kernel.org
>>>> Cc: sri@us.ibm.com; dragos.tatulea@gmail.com; arnd@arndb.de;
>>>> kvm@vger.kernel.org; mst@redhat.com; davem@davemloft.net;
>>>> mchan@broadcom.com; dwang2@cisco.com; shemminger@vyatta.com;
>>>> eric.dumazet@gmail.com; kaber@trash.net; benve@cisco.com
>>>> Subject: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering
>>>> support for passthru mode
>>>> 
>>> 
>>> [snip...]
>>> 
>>>> 
>>>> 
>>>> Note: The choice of rtnl_link_ops was because I saw the use case for
>>>> this in virtual devices that need  to do filtering in sw like macvlan
>>>> and tun. Hw devices usually have filtering in hw with netdev->uc and
>>>> mc lists to indicate active filters. But I can move from rtnl_link_ops
>>>> to netdev_ops if that is the preferred way to go and if there is a
>>>> need to support this interface on all kinds of interfaces.
>>>> Please suggest.
>>> 
>>> I'm still digesting the rest of the RFC patches but I did want to
>> quickly jump
>>> in and push for adding this support in netdev_ops.  I would like to see
>> these
>>> features available in more devices than just macvtap and macvlan.  I can
>>> conceive
>>> of use cases for multiple HW MAC and VLAN filters for a VF device that
>> isn't
>>> owned by a macvlan/macvtap interface and only has netdev_ops support.
>> In this
>>> case it would be necessary to program the filters directly to the VF
>> device
>>> interface or PF interface (or lowerdev as you refer to it) instead of
>> going
>>> through macvlan/macvtap.
>>> 
>>> This work dovetails nicely with some work I've been doing and I'd be
>> very
>>> interested
>>> in helping move this forward if we could work out the details that would
>> allow
>>> support
>>> of the features we (and the community) require.
>> 
>> Great. Thanks. I will definitely be interested to get this patch working
>> for
>> any other use case you have.
>> 
>> Moving the ops to netdev should be trivial. You probably want the ops to
>> work on the VF via the PF, like the existing ndo_set_vf_mac etc.
> 
> That is correct, so we would need to add some way to pass the VF number to the
> op.
> In addition, there are use cases for multiple MAC address filters for the
> Physical
> Function (PF) so we would like to be able to identify to the netdev op that it
> is
> supposed to perform the action on the PF filters instead of a VF.
> 
> An example of this would be when an administrator has created some number of
> VFs
> for a given PF but is also running the PF in bridged (i.e. promiscuous) mode
> so that it
> can support purely SW emulated network connections in some VMs that have low
> network
> latency and bandwidth requirements while reserving the VFs for VMs that
> require the low latency, high throughput that directly assigned VFs can
> provide.  In this case an
> emulated SW interface in a VM is unable to properly communicate with VFs on
> the same
> PF because the emulated SW interface's MAC address isn't programmed into the
> HW filters
> on the PF.  If we could use this op to program the MAC address and VLAN
> filters of
> the emulated SW interfaces into the PF HW a VF could then properly communicate
> across
> the NIC's internal VEB to the emulated SW interfaces.
> 
>> Yes, lets work out the details and I can move this to netdev->ops. Let me
>> know.
> 
> I think essentially if you could add some parameter to the ops to specify
> whether it
> is addressing a VF or the PF and then if it is a VF further specify the VF
> number we
> would be very close to addressing the requirements of many valuable use cases
> in
> addition to the ones you have identified in your RFC.
> 
> Does that sound reasonable?
> 

Thanks for the details Greg. Sounds good. I will change it to provide netdev
ops with a vf argument and respin.

Thanks,
Roopa