Message-ID: <CAC5DB6F.376E7%roprabhu@cisco.com>
Date:	Thu, 20 Oct 2011 14:06:39 -0700
From:	Roopa Prabhu <roprabhu@...co.com>
To:	"Rose, Gregory V" <gregory.v.rose@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	"sri@...ibm.com" <sri@...ibm.com>,
	"dragos.tatulea@...il.com" <dragos.tatulea@...il.com>,
	"arnd@...db.de" <arnd@...db.de>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"mst@...hat.com" <mst@...hat.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"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/8 RFC v2] macvlan: MAC Address filtering
 support for passthru mode




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

>> -----Original Message-----
>> From: Roopa Prabhu [mailto:roprabhu@...co.com]
>> Sent: Wednesday, October 19, 2011 3:30 PM
>> To: Rose, Gregory V; netdev@...r.kernel.org
>> Cc: sri@...ibm.com; dragos.tatulea@...il.com; arnd@...db.de;
>> kvm@...r.kernel.org; mst@...hat.com; davem@...emloft.net;
>> mchan@...adcom.com; dwang2@...co.com; shemminger@...tta.com;
>> eric.dumazet@...il.com; kaber@...sh.net; benve@...co.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@...el.com> wrote:
>> 
>>>> -----Original Message-----
>>>> From: netdev-owner@...r.kernel.org [mailto:netdev-
>> owner@...r.kernel.org]
>>>> On Behalf Of Roopa Prabhu
>>>> Sent: Tuesday, October 18, 2011 11:26 PM
>>>> To: netdev@...r.kernel.org
>>>> Cc: sri@...ibm.com; dragos.tatulea@...il.com; arnd@...db.de;
>>>> kvm@...r.kernel.org; mst@...hat.com; davem@...emloft.net;
>>>> mchan@...adcom.com; dwang2@...co.com; shemminger@...tta.com;
>>>> eric.dumazet@...il.com; kaber@...sh.net; benve@...co.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 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