[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <B26690A4-C7E8-4D68-932F-D017A645989F@insidepacket.com>
Date: Tue, 25 Mar 2025 19:33:23 +0200
From: Eliyah Havemann <eliyah@...idepacket.com>
To: Michal Kubecek <mkubecek@...e.cz>
Cc: netdev@...r.kernel.org
Subject: Re: ethtool read EEPROM
Hi Michal,
thanks so much for your response. I will look into devlink and am looking forward to your insights!
Best
Eliyah
> On 25 Mar 2025, at 19:03, Michal Kubecek <mkubecek@...e.cz> wrote:
>
> On Tue, Mar 25, 2025 at 05:16:52PM +0200, Eliyah Havemann wrote:
>> Hi Michael,
>>
>> You seem to be the current maintainer and top contributor to the
>> ethtool project. First of all: Thank you for your contribution to OSS!
>>
>> I ran into an issue with a whitebox switch with 100G and 400G QSFP
>> slots, that I was hoping ethtool could solve and I want to ask you for
>> assistance. It’s pretty simple: I need to read EEPROM binary data from
>> these QSFP transceivers, but they are not associated with any linux
>> interface. This is because vpp is controlling them directly. The
>> ethtool has a function to output the EEPROM of an interface, but I
>> can’t feed it the file back to it to read it. The file it outputs has
>> the exact same format of the file the whitebox switch provides. I
>> created a small python script to read the file and it gives reasonable
>> output, but I don’t have a way to test this against a big collection
>> of SFPs and I know that this work was already done in ethtool.
>>
>> My questions:
>> 1. Do you know of a tool that can read these files that ethtool
>> outputs? Maybe it exists, and I just didn’t find it…
>> 2. If not, can you provide some guidance on how to add the
>> functionality to ethtool to read EEPROMs directly?
>
> If I understand you correctly, your problem is that ethtool can
> interpret the content of the module EEPROM but cannot read it for
> a module in a smart switch.
>
> In general, devlink should be the tool designed to handle smart switches
> and similar devices and their components. I'm not aware if it can also
> interpret the module EEPROM content like ethtool does but it's the tool
> you should definitely take a look at.
>
> Implementing a feature that would allow to use the ethtool code for
> interpreting the module EEPROM content also on a dump read from a file
> is something that would probably make sense whether you can use devlink
> for your purpose. I'll check what would be the most appropriate way to
> do that.
>
> Michal
Powered by blists - more mailing lists