netdev - switchdev and VLAN ranges

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <493168159.229458.1444433451493.JavaMail.zimbra@savoirfairelinux.com>
Date:	Fri, 9 Oct 2015 19:30:51 -0400 (EDT)
From:	Vivien Didelot <vivien.didelot@...oirfairelinux.com>
To:	Jiri Pirko <jiri@...nulli.us>, Scott Feldman <sfeldma@...il.com>
Cc:	netdev <netdev@...r.kernel.org>, stephen@...workplumber.org,
	Florian Fainelli <f.fainelli@...il.com>,
	Andrew Lunn <andrew@...n.ch>
Subject: switchdev and VLAN ranges

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html