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

[Tim Gardner]

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 ?

rtg
-- 
Tim Gardner tim.gardner at canonical.com