On Oct. Monday 12 (42) 09:27 PM, Ido Schimmel wrote: > 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? Yes we do remove VLAN entries from the hardware table when switchdev_port_obj_del(SWITCHDEV_OBJ_ID_PORT_VLAN) is called. I may have misunderstood your previous note, I thought we were talking about implementing the flush operation in switchdev drivers. > > > >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
