Hi Ido, > > > > The reason why I chose switchdev here is because: > > > > - this is mostly relevant for switch devices, not so much for NICs (it > > seems), if it was, they would have solved the problem by now > > I don't see any use of switchdev APIs in the driver Ivan is patching. > The cover letter doesn't indicate anything about it either.
There were RFCs for it a few months ago https://patchwork.ozlabs.org/cover/929367/ We decided that rewriting the driver instead of adding switchdev support on the current one is cleaner and preferred, so we'll be posting a new driver for this at some point (most of the work is already done). > > > - this allows to have an unified path from the switch driver perspective > > to program MDB addresses targeting the CPU/management port, no need to > > have X different ways of doing the same operation > > But it's not the same thing. Allowing certain packets to ingress the > device is not the same as having the device send them to the CPU. We > have VLAN filters as well. Allowing VID X to ingress does not mean that > we trap each packet with this VID to CPU. /Ilias
