netdev - DSA: Exposing CPU port [Was: Re: [PATCH 3/3] net: dsa: Allow configuration of CPU & DSA port speeds/duplex]

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>] [day] [month] [year] [list]

Date:	Wed, 17 Jun 2015 11:40:10 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Cc:	Andrew Lunn <andrew@...n.ch>, David <davem@...emloft.net>,
	Guenter Roeck <linux@...ck-us.net>,
	Cory Tusar <cory.tusar@...1solutions.com>,
	netdev <netdev@...r.kernel.org>
Subject: DSA: Exposing CPU port [Was: Re: [PATCH 3/3] net: dsa: Allow
 configuration of CPU & DSA port speeds/duplex]

2015-06-17 11:09 GMT-07:00 Vivien Didelot <vivien.didelot@...oirfairelinux.com>:
> Hi Andrew, All,
>
> On 12/06/15 10:18, Andrew Lunn wrote:
>> By default, DSA and CPU ports are configured to the maximum speed the
>> switch supports. However there can be use cases where the peer device
>> port is slower. Allow a fixed-link property to be used with the DSA
>> and CPU port in the device tree, and use this information to configure
>> the port.
>
> Would it be a good idea for DSA to expose the "cpu" port to userspace as well?
> That way, it'd be possible to use ethtool to set the port speed and duplex
> mode, or dump registers (this would have saved me quite some time in dev).

My problem with that approach would be that we would expose a "cpu"
net_device in a way that it is not usable beyond statistics and
control knobs. In terms of data-path, you would not really want to
have it usable (sending data from the CPU to other ports, that's
already what other net_devices do), as it would be a duplicate
interface with respect to how the "master" net_device in DSA (aka
unmodified Ethernet driver) works. Having e.g: eth0 send DSA-tagged
packets today is already very confusing to users (they do not
necessarily understand why this interface does or how it works), so
having a "cpu" interface would cause more trouble here.

>
> Also, in my RFC for 802.1Q support [1], I assume the CPU port to be a tagged
> member of each VLAN. But someone may want to add a VLAN with swp3 and swp4
> only, and another VLAN with swp0, swp1 and the CPU port. Am I correct? This is
> currently not possible, but with an exposed "cpu" interface, the user could
> explicitly add the CPU port to a VLAN.

If we do put, say swp0 and swp1 in VLAN1, and CPU port is not in this
VLAN1, we cannot learn any traffic from it, this might be an
acceptable use-case, but I am not sure if there is much we get from
not adding the CPU to this VLAN membership, am I missing something?
-- 
Florian
--
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