On Wed, Dec 2, 2020 at 2:09 AM Jiri Pirko wrote: > >I'm not suggesting the port split be dynamic at all. I'm suggesting that if > >the admin wants or needs to force PAM4 on a port that would otherwise > >be able to achieve the given speed using more lanes with NRZ, then the > >admin should split the port, so that it has fewer lanes, in order to make > >that intent clear (or otherwise configure the port to have fewer lanes > >attached, if you really don't want to or can't create the additional split > >port). > > Okay, I see your point now. The thing is, the port split/unsplit causes > a great distubance. Meaning, the netdevs all of the port > disappear/reappear. Now consider following example: I guess that's a detail of the present implementation and/or device capabilities (I'm not particularly familiar), but presumably it is at least possible, in principle, to modify a device's port config without taking down the netdev. That said, after spending more time thinking about this, I'm coming around to the idea of being able to explicitly set encoding (not lanes) via ethtool. And, in this context, by encoding, I technically mean line code signalling, not symbol encoding. Although it does for today's link modes, the number of lanes does not generally imply signalling mode. In future we may have PAM8 signalling and then the present proposal of deriving the signalling mode for a given speed from the lane count falls down. We should be specifying signalling mode via ethtool instead of lanes. Alternatively, we need to be specifying the fully defined link mode. But, doing so is fraught with other issues, including how to represent it in the interface and the fact that the user doesn't necessarily want to specify physical media in these cases, something that is implied by the full link mode definition. Regards, Edwin Peer