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
Attachments
- smime.p7s [application/pkcs7-signature] 4160 bytes
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