lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-Id: <201004220851.05756.arnd@arndb.de> Date: Thu, 22 Apr 2010 08:51:05 +0200 From: Arnd Bergmann <arnd@...db.de> To: Chris Wright <chrisw@...hat.com> Cc: Scott Feldman <scofeldm@...co.com>, davem@...emloft.net, netdev@...r.kernel.org Subject: Re: [net-next,1/2] add iovnl netlink support On Thursday 22 April 2010, Chris Wright wrote: > > > > ip link add link eth0 type macvlan # for a container > > ip link add link eth0 type macvtap # for qemu/vhost > > ip link add link eth0 type vf # for device assignment > > BTW, what do you mean by device assignment? I mean giving an SR-IOV VF to the guest as a native PCI device rather than having qemu or vhost present a virtio-net to the guest. > > There are obviously significant differences between these three, but > > they also share enough of their properties to let us treat them > > in similar ways. > > > > If we integrate the iovnl client into iproute2, the sequence for setting > > up an enic VF and associating it to the port profile could be > > > > # create vf0, pass mac and vlan id to HW, no association yet > > ip link add link eth0 name vf0 type vf mac fe:dc:ba:12:34:56 vlan 78 > > Just to clarify...right now, the normal SR-IOV VF is already there. > And, or course, can have its mac addr/vlan set already. I don't have an SR-IOV card available for testing yet. How is this configured now? > > # associate vf with port profile, mac address must match the one assigned > > # to the interface before. > > ip iov assoc eth0 port-profile "general" host-uuid "dcf2a873-f5ee-41dd-a7ad-802a544e48c2" \ > > mac fe:dc:ba:12:34:56 > > At that point you could just do s/mac fe:.*/link vf0/ My point was that this information should be irrelevant to the code doing the association with the switch. It sort of makes sense when the receiver is enic, but when we send the same data to lldpad, it doesn't care about the slave device name but only about the mac address. Especially since the slave device might not be in the root name space any more, meaning we have no way to find it. Arnd -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists