netdev - Re: [PATCH net-next 1/3] net:dsa:mv88e6xxx: use hashtable to store multicast entries

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <be3b69b7-b6a3-a939-cf77-c62e5a1fe719@gmail.com>
Date:   Thu, 15 Dec 2016 09:32:45 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Volodymyr Bendiuga <volodymyr.bendiuga@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     Volodymyr Bendiuga <valdr.linuxnext@...il.com>,
        netdev@...r.kernel.org,
        Volodymyr Bendiuga <volodymyr.bendiuga@...termo.se>,
        John Crispin <john@...ozen.org>
Subject: Re: [PATCH net-next 1/3] net:dsa:mv88e6xxx: use hashtable to store
 multicast entries

On 12/15/2016 09:21 AM, Vivien Didelot wrote:
> Hi Volodymyr,
> 
> Volodymyr Bendiuga <volodymyr.bendiuga@...il.com> writes:
> 
>> Hi Andrew,
>>
>> I have tested the approach you wrote in previous mails, the one
>> with setting next.mac to address we are looking for -1. It seems
>> to be as slow as the original implementation, unfortunately.
> 
> Hum, that is what I was expecting... The ATU GetNext operation
> (alongside an ether_addr_equal() call) should be quite fast.
> 
>> We use 6097 and 6352 chips, and both of them can not do any port
>> filtering in hardware for fdb dump operation. Seems like they would
>> benefit from cache. But I am not sure about other switches.
>>
>> Does anyone know about such feature in other switches?
> 
> Marvell switches cannot filter ATU entries for a specific port, they
> contain a port vector.
> 
> I guess Florian might answer for Broadcom switches, and John might
> answer for Qualcomm switches.

For Broadcom switches, we use the ARL search and then apply software
filtering to discard entries that are not for the target port bridge fdb
show was called with.

> 
> In all cases *if caching is really needed*, I think it won't hurt to do
> it in DSA core even if a switch support FDB dump operations on a
> per-port basis, as Andrew mentioned.

Agreed, and there does not appear to be any need to new dsa_switch_ops
operations to be introduced?
-- 
Florian