On Wed, 1 Jun 2022 09:48:25 +0800 Yinjun Zhang wrote:

On Mon, May 30, 2022 at 09:32:32PM -0700, Jakub Kicinski wrote:

quoted

On Mon, 30 May 2022 10:48:42 +0200 Simon Horman wrote:  

quoted

The output  of `Configured FEC encodings` should display user
configured/requested value,  

That stands to reason, but when I checked what all drivers do 7 out 
of 10 upstream drivers at the time used it to report supported modes.  

It seems you're right. I agree it's OK that nfp driver keep the same with
majority drivers' implementations.

FWIW this is what I found in my notes:

get:
 s - supported
 c - configured
set:
 1 - single mode
 m - multiple modes

      nfp | ionic | lio | cxgb4 | hns3 | i40e | ice | mlx5 | qede | sfc | bnxt
-----------------------------------------------------------------------------
get |  s  |   s   |  s  |   s   |  s   |  c?  |  s  |  c?  |  s   |  c? |
set |  1  |   1   |  1  |   m   |  m   |  1   |  1  |  m?  |  m   |  m  |

I don't know how accurate that was, hard to tell those things 
by looking only at the kernel driver.

quoted

At which point it may be better to change the text in ethtool user
space that try to change the meaning of the field..  

To adapt to both implementations, "Supported/Configured FEC encodings"
would be a compromise I think.

Yup, it should help avoid bug reports. I don't have better ideas :(