On 10/20/11 1:43 PM, "Rose, Gregory V" <gregory.v.rose@xxxxxxxxx> wrote: >> -----Original Message----- >> From: Roopa Prabhu [mailto:roprabhu@xxxxxxxxx] >> Sent: Wednesday, October 19, 2011 3:30 PM >> To: Rose, Gregory V; netdev@xxxxxxxxxxxxxxx >> Cc: sri@xxxxxxxxxx; dragos.tatulea@xxxxxxxxx; arnd@xxxxxxxx; >> kvm@xxxxxxxxxxxxxxx; mst@xxxxxxxxxx; davem@xxxxxxxxxxxxx; >> mchan@xxxxxxxxxxxx; dwang2@xxxxxxxxx; shemminger@xxxxxxxxxx; >> eric.dumazet@xxxxxxxxx; kaber@xxxxxxxxx; benve@xxxxxxxxx >> 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@xxxxxxxxx> wrote: >> >>>> -----Original Message----- >>>> From: netdev-owner@xxxxxxxxxxxxxxx [mailto:netdev- >> owner@xxxxxxxxxxxxxxx] >>>> On Behalf Of Roopa Prabhu >>>> Sent: Tuesday, October 18, 2011 11:26 PM >>>> To: netdev@xxxxxxxxxxxxxxx >>>> Cc: sri@xxxxxxxxxx; dragos.tatulea@xxxxxxxxx; arnd@xxxxxxxx; >>>> kvm@xxxxxxxxxxxxxxx; mst@xxxxxxxxxx; davem@xxxxxxxxxxxxx; >>>> mchan@xxxxxxxxxxxx; dwang2@xxxxxxxxx; shemminger@xxxxxxxxxx; >>>> eric.dumazet@xxxxxxxxx; kaber@xxxxxxxxx; benve@xxxxxxxxx >>>> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
