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

Rob Herring robherring2 at gmail.com
Fri Nov 15 17:36:18 UTC 2013

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.


More information about the kernel-team mailing list