> -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Rose, Gregory V > Sent: Thursday, October 20, 2011 1:44 PM > To: Roopa Prabhu; [email protected] > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > 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:[email protected]] > > Sent: Wednesday, October 19, 2011 3:30 PM > > To: Rose, Gregory V; [email protected] > > Cc: [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected] > > 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" <[email protected]> wrote: > > > > >> -----Original Message----- > > >> From: [email protected] [mailto:netdev- > > [email protected]] > > >> On Behalf Of Roopa Prabhu > > >> Sent: Tuesday, October 18, 2011 11:26 PM > > >> To: [email protected] > > >> Cc: [email protected]; [email protected]; [email protected]; > > >> [email protected]; [email protected]; [email protected]; > > >> [email protected]; [email protected]; [email protected]; > > >> [email protected]; [email protected]; [email protected] > > >> 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 ^^^ That should be "no", not low...
- Greg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
