[SRU][saucy][PATCH] net: calxedaxgmac: add mac address learning

Rob Herring robherring2 at gmail.com
Fri Nov 15 22:41:42 UTC 2013

On 11/15/2013 12:00 PM, Tim Gardner wrote:
> On 11/15/2013 09:36 AM, Rob Herring wrote:
>> On 11/15/2013 11:21 AM, Tim Gardner wrote:
>>> On 11/14/2013 02:01 PM, Rob Herring wrote:
>>>> From: Rob Herring <rob.herring at calxeda.com>
>>>> The Calxeda xgmac must learn secondary mac addresses such as those
>>>> behind a bridge in order to properly receive packets with those mac
>>>> addresses. Add mac address learning on transmit with timestamping of
>>>> entries. The mac addresses are added to the driver's unicast address
>>>> list, so they are visible to user via "bridge fdb show" command.
>>>> Addresses can get disabled when the AE bit is cleared, so address
>>>> registers must be checked for possible removal and update the unicast
>>>> list.
>>>> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
>>>> ---
>>> Rob - I'm curious why you don't just always use the hardware hash filter
>>> table ? Is there a significant performance hit ? Using the hash filter
>>> table means that you don't have to worry about managing a slot array.
>>> You could use a much simpler linked list and just not worry about
>>> collisions or allocations in mac_list.
>> The fabric has to know every exact unicast address to route packets, so
>> the hash filter doesn't really work. While the fabric is kind of switch
>> like, there is no broadcast unknown addresses like an L2 switch. There
>> is a lot of work the management core does here as addresses are added or
>> removed here.
>> Rob
> xgmac_set_rx_mode() falls back to the hash table method when the
> combined number of unicast and multicast addresses exceed the number of
> slots. What happens then ?

We will use all slots for unicast first and then use hash filter if
there are not enough slots left.

But yes, if you exceed 31 unicast addresses things will stop working. We
should fix this for the "bridge fdb add" case, but failure won't be so
noticeable in the learning case. In the learning case, the only way I've
come up with to report errors is incrementing the learning_drop counter
or a printk.


More information about the kernel-team mailing list