Hi All, I understand that specifying a VLAN range on the command line is nice for the user, and it makes no big deal for software implementation.
However, AFAICT a VLAN range does not make sense at all for hardware such as Ethernet switch chips. Am I wrong? I would suggest to make switchdev directly answer to a bridge request that the operation is not supported when the user asks for a VLAN range. That way, we can simply use a single "vid" member in struct switchdev_obj_port_vlan instead of "vid_begin" and "vid_end" and thus avoid making drivers heavier with iteration loops on such range. I have two concerns in mind: a) if we imagine that drivers like Rocker allocate memory in the prepare phase for each VID, preparing a range like 100-4000 would definitely not be recommended. b) imagine that you have two Linux bridges on a switch, one using the hardware VLAN 100. If you request the VLAN range 99-101 for the other bridge members, it is not possible for the driver to say "I can accelerate VLAN 99 and 101, but not 100". It must return OPNOTSUPP for the whole range. That's why I think that avoiding VLAN range at the switchdev level would be a good idea. Thanks, -v -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
