On 10/20/11 1:43 PM, "Rose, Gregory V" <gregory.v.r...@intel.com> wrote:
>> -----Original Message-----
>> From: Roopa Prabhu [mailto:ropra...@cisco.com]
>> Sent: Wednesday, October 19, 2011 3:30 PM
>> To: Rose, Gregory V; net...@vger.kernel.org
>> Cc: s...@us.ibm.com; dragos.tatu...@gmail.com; a...@arndb.de;
>> kvm@vger.kernel.org; m...@redhat.com; da...@davemloft.net;
>> mc...@broadcom.com; dwa...@cisco.com; shemmin...@vyatta.com;
>> eric.duma...@gmail.com; ka...@trash.net; be...@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.r...@intel.com> wrote:
>>
>>>> -----Original Message-----
>>>> From: netdev-ow...@vger.kernel.org [mailto:netdev-
>> ow...@vger.kernel.org]
>>>> On Behalf Of Roopa Prabhu
>>>> Sent: Tuesday, October 18, 2011 11:26 PM
>>>> To: net...@vger.kernel.org
>>>> Cc: s...@us.ibm.com; dragos.tatu...@gmail.com; a...@arndb.de;
>>>> kvm@vger.kernel.org; m...@redhat.com; da...@davemloft.net;
>>>> mc...@broadcom.com; dwa...@cisco.com; shemmin...@vyatta.com;
>>>> eric.duma...@gmail.com; ka...@trash.net; be...@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
--
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
