Thread (31 messages) 31 messages, 4 authors, 2021-02-02

Re: [PATCH net-next v3 2/7] ethtool: Get link mode in use instead of speed and duplex parameters

From: Edwin Peer <hidden>
Date: 2021-02-02 00:15:35

On Mon, Feb 1, 2021 at 2:20 PM Jakub Kicinski [off-list ref] wrote:
quoted
Should they not be the same thing?
Okay. Does "supported modes" in ethtool for bnxt get ANDed with the
supported modes of the plugged in module?

What happens when no module is plugged in? List all?

I've surveyed this behavior a few years back and three vendors I tested
all had different interpretation on what to list in supported modes :/
Fair enough, I can't argue there. ;)
quoted
Yes, there would be multiple link modes that map to the same speed and
lane combination, but that doesn't mean you need to accept them if the
media doesn't match what's plugged in also. In the above scenario, the
supported mask should not list SR because CR is physically plugged in.
That way, the user knows what options are legal and the kernel knows
what it can reject.
If the modes depend on what's plugged in - what happens if cable gets
removed? We (you, Danielle, I) can agree what we think is best, but
history teaches us that doesn't matter in long run. We had a similar
conversation when it comes to FEC. There simply is no way for upstream
developers to review the behavior is correct.
Given that supported is only defined in the context of autoneg today,
once could still specify. But again, you raise a fair concern.

The asymmetry in interface is still ugly though, you get to decide
which ugly is worse. :P

Regards,
Edwin Peer

Attachments

  • smime.p7s [application/pkcs7-signature] 4160 bytes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help