2015-06-17 11:09 GMT-07:00 Vivien Didelot <vivien.dide...@savoirfairelinux.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
