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

-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Rose, Gregory V
Sent: Thursday, October 20, 2011 1:44 PM
To: Roopa Prabhu; 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

quoted

-----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" [off-list ref] wrote:

quoted

quoted

-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-

owner@vger.kernel.org]

quoted

quoted

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

quoted

quoted

quoted

support for passthru mode

[snip...]

quoted

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

quoted

quoted

quoted

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

quoted

in and push for adding this support in netdev_ops.  I would like to

see

quoted

these

quoted

features available in more devices than just macvtap and macvlan.  I

can

quoted

quoted

conceive
of use cases for multiple HW MAC and VLAN filters for a VF device that

isn't

quoted

owned by a macvlan/macvtap interface and only has netdev_ops support.

In this

quoted

case it would be necessary to program the filters directly to the VF

device

quoted

interface or PF interface (or lowerdev as you refer to it) instead of

going

quoted

through macvlan/macvtap.

This work dovetails nicely with some work I've been doing and I'd be

very

quoted

interested
in helping move this forward if we could work out the details that

would

quoted

allow

quoted

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

  ^^^
That should be "no", not low...

- Greg