Hi Volodymyr,
Volodymyr Bendiuga [off-list ref] 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.
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.
Thanks,
Vivien
On 12/15/2016 09:21 AM, Vivien Didelot wrote:
Hi Volodymyr,
Volodymyr Bendiuga [off-list ref] writes:
quoted
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.
quoted
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
On 15/12/2016 18:21, Vivien Didelot wrote:
Hi Volodymyr,
Volodymyr Bendiuga [off-list ref] writes:
quoted
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.
quoted
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.
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.
QCA switches allow defining a port mask in a fdb search/iterate
operation. just had a look in the brcm driver and it filters in software
John