On Tue, May 26, 2015 at 12:50:52AM +0300, Or Gerlitz wrote: > On Tue, May 26, 2015 at 12:14 AM, Jason Gunthorpe > <jguntho...@obsidianresearch.com> wrote: > > On Mon, May 25, 2015 at 11:04:41PM +0300, Or Gerlitz wrote: > > > >> OK, so rewinding a bit, the IB VF [1] identity is their 8 bytes port > >> GUID, and as Jason noted the user/kernel API allows to deliver up to > >> 32 bytes between user and kernel under the set_vf_mac flow > >> (do_setvfinfo() in net/core/rtnetlink.c). Trying it out through > >> **non-modified** ip tool and net/core/rtnetlink.c things just work - > >> I can set eight bytes value to be the virtual port GUID : > > > > Was I not perfectly clear? You have to use the 20 byte LLADDR format here: > > > >> # ip link set dev ib0 vf 1 mac aa:bb:cc:dd:ee:ff:11:22 > > Jason, > > I am aiming to provision the VF IB end-node address == port GUID (vGUID) > in the same manner that VF Eth end-node address is their MAC, not > more, not less.
I perfectly understand what you are trying to do. I care about the design and consistency of netlink - and that means there is one LLADDR definition for a net device, and every single netlink message that touches a LLADDR uses that definition - for IPoIB that is 20 bytes. To violate that design invariant needs an incredibly strong argument, and you haven't made it. This allows generic code to work with the LLADDR - for instance 'ip link set vf mac' should have checked the size of the IFLA_ADDRESS and demanded that the address argument is the same number of bytes. It is very broken the command happily accepts an 8 byte and 6 byte argument for the same device. Yes, it is ugly that the PF side's ndo_get_vf_config cannot return the same 20 byte address of the VF's ipoib interface, but I think that is less ugly than forcing a different address format just for the vf calls. If you have doubts then *ask netdev*. Ask them if ndo_set_vf_mac must follow the same address size and format as IFLA_ADDRESS, or if we can use something else. Such a netlink architecture choice is beyond the authority of linux-rdma. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
