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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <43F901BD926A4E43B106BF17856F075501A19FF1D8@orsmsx508.amr.corp.intel.com>
Date:	Thu, 20 Oct 2011 13:43:39 -0700
From:	"Rose, Gregory V" <gregory.v.rose@...el.com>
To:	Roopa Prabhu <roprabhu@...co.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

> -----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,

- Greg

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