Mon, Oct 12, 2015 at 09:15:39PM IDT, vivien.didelot@xxxxxxxxxxxxxxxxxxxx wrote: >Hi, > >On Oct. Monday 12 (42) 08:51 PM, Ido Schimmel wrote: >> Mon, Oct 12, 2015 at 02:41:09PM IDT, razor@xxxxxxxxxxxxx wrote: >> >From: Nikolay Aleksandrov <nikolay@xxxxxxxxxxxxxxxxxxx> >> > >> >As Ido Schimmel pointed out the vlan_vid_del() loop in nbp_vlan_flush is >> >unnecessary (and is actually a remnant of the old vlan code) so we can >> >remove it and combine both br/nbp vlan_flush functions into one. >> Just a small note to Scott and Vivien: >> >> One of the side effects of Nik's recent patchsets is that when VLANs are >> flushed on a port the deletion is propagated to the driver via >> switchdev ops, as __vlan_vid_del is called. >> >> Therefore there is no need to do internal bookkeeping and remove VLANs >> yourself when port is removed from bridge. > >I was thinking about caching VLAN entries in the mv88e6xxx driver to >improve look up on VLAN and FDB operations, but it's a bit prematurate. > >But when VLAN are flushed, we still need to remove them from the >hardware table, right? Hi, Not sure I'm following. You'll simply get a SWITCHDEV_OBJ_ID_PORT_VLAN (del) for each VLAN configured on the port you just removed from the bridge. I guess you remove them from your hardware table in the implementation of these ops? > >Flushing is interesting though, most hardware have flush operations and >it would be interesting to have switchdev fdb_flush and vlan_flush ops. > >Thanks! >-v
