On Thu, 2011-10-20 at 13:43 -0700, Rose, Gregory V wrote: > > -----Original Message----- > > From: Roopa Prabhu [mailto:roprabhu@xxxxxxxxx] [...] > > 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. [...] This would also be good for Solarflare's VF plugin architecture. The VF driver works as a plugin for virtio or xen_netfront and can refuse packets that need to be bridged to another (physically) local address. The PF driver has to tell VFs what the local addresses are and currently relies on some custom scripting to know about those extra addresses. (No, none of that is upstream - I'm preparing for that now.) Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- 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
