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

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

these

quoted

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

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

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

quoted

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