[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130226.171503.1736601811583226926.davem@davemloft.net>
Date: Tue, 26 Feb 2013 17:15:03 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: john.r.fastabend@...el.com
Cc: vyasevic@...hat.com, netdev@...r.kernel.org
Subject: Re: [RFC PATCH] core: Add ioctls to control device unicast hw
addresses
From: John Fastabend <john.r.fastabend@...el.com>
Date: Tue, 26 Feb 2013 13:58:39 -0800
> [...]
>
>>>>
>>>>
>>>> [RFC PATCH] rtnetlink: Add support for adding/removing additional hw
>>>> addresses.
>>>>
>>>> Add an ability to add and remove HW addresses to the device
>>>> unicast and multicast address lists. Right now, we only have
>>>> an ioctl() to manage the multicast addresses and there is no
>>>> way the manage the unicast list.
>>>>
>>>> Signed-off-by: Vlad Yasevich <vyasevic@...hat.com>
>>>
>>> This is a step in the right direction, and you're right that there is
>>> a difficulty in detecting whether support exists or not.
>>>
>>> I am so surprised that we've have ->set_rx_mode() support for multiple
>>> unicast MAC addresses in so many drivers all this time, yet no way
>>> outside of FDB to make use of it at all.
>>
>> And even that is not always available. In most drivers it requires
>> module parameters or other explicit configuration steps. Meanwhile
>> set_rx_mode() doesn't seem to depend on any of those and just does the
>> right thing.
>>
>> For what I was trying to do ioctl() was a really easy way out for both
>> kernel and user space implementation, so I gave is shot.
>>
>> -vlad
>>
>
> Don't we already support this with
The whole point is that these multiple-unicast-address configuration
facilities are inaccessible without FDB, and there is no reason
whatsoever for that.
--
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