>This doesn't seem appropriate at all. If anything UC addresses >should be blocked and the Intel driver change reverted. We have >a well defined way to add secondary UC addresses and the MC interfaces >are not it.
As I understand by ‘well defined way’ you mean macvlan feature. But macvlan is more virtualisation thing where an additional netdevice is created and for each skb passed to linux stack hash_lookup is made to find a netdevice to which this skb belongs to based on mac_dst. In case if someone want to have a network protocol on top of physical layer (AF_PACKET) where NIC should allow several uc mac addr without enabling promiscuous mode i am not sure that for this simple task macvlan is needed. >Furthermore, even if this was appropriate, "fixing" this only for >ethernet is definitely not appropriate. The fix would need to be able >to handle any address type. Having a generic interface work >inconsistently for one link type vs. another is a non-starter. Maybe overusing multicast api isn’t the best choice for this purpose, but i noticed that it is already overused by i40 for the same purpose, that is why i suggested this diff. Anyway i can add separate ioctls for add/del secondary uc, if this is worth it.
