Hi,
What happens if a FDB entry is added manually to an offloaded LAG
interface? Does DSA core simply call .port_fdb_add with the member
ports in the LAG?
I'm asking because there is a trunk field in struct
mv88e6xxx_atu_entry, when it is true, the portvec is actually the
trunk ID.
As the current implementation (mv88e6xxx_port_db_load_purge) does not
use this field, it probably won't work.
Regards,
Qingfang
Hi Qingfang,
On Mon, Jul 19, 2021 at 08:22:01PM +0800, DENG Qingfang wrote:
Hi,
What happens if a FDB entry is added manually to an offloaded LAG
interface? Does DSA core simply call .port_fdb_add with the member
ports in the LAG?
I'm asking because there is a trunk field in struct
mv88e6xxx_atu_entry, when it is true, the portvec is actually the
trunk ID.
As the current implementation (mv88e6xxx_port_db_load_purge) does not
use this field, it probably won't work.
Regards,
Qingfang
This is not supported at the moment.
Coincidentally or not, I am currently working on refactoring the DSA
handler for SWITCHDEV_FDB_ADD_TO_DEVICE to remove some of the technical
debt (in particular, local FDB entries pointing towards the bridge do
not work in all situations when combined with FDB replays). One of the
extra features of the new implementation will be a new .lag_fdb_add()
method in struct dsa_switch_ops.