On 05/02/2016 03:55 PM, Dennis Dalessandro wrote:
[ snip stuff about the UI file ]
The UI file discussion appears to have reached a reasonable conclusion,
so I'm not going to add to it.
> We also should be able to use any of these schemes to handle our eprom
> reading/writing. Adding eprom to IPoIB as Doug suggested is a fine plan,
> but
> we technically don't need to do it right now when we could make do with the
> "UI" functionality and hide the details in user space. In the future
> there may well be value in having an eprom capability in the rdma
> sub-system, but for now we believe we can avoid extending the kernel in
> this regard.
I'm not sure I agree here.
First, on the "technically don't need to do it" and "can make do". At
least one of the points of these reviews is to identify and squash cases
of "technically don't need to do it" and "can make do" when it revolves
around doing something half-assed that should be done properly instead.
The cxgb? drivers use the kernel firmware load mechanism. I'm fine with
that.
The Mellanox drivers use a custom, user space tool. I *was* fine with
that, when it was a one off thing. Now you are talking about doing the
same thing, and it's going to become a two off thing. That makes me
somewhat less OK with either one.
Upfitting IPoIB to pass through the netstack eeprom stuff should be
almost trivial to do.
1) Add eeprom_get and eeprom_set routines to struct ib_device
2) In driver, set eeprom_get and eeprom_set in ib_device
3) In IPoIB, copy eeprom_get and eeprom_set from ib_device to ethtool ops
Everything else is done in user space. You can use ethtool, or you
could write a custom tool to do the trick. Mellanox could do the same
thing and modify mstflint to just pass the work to the ethool entry
points while still retaining all of their FS/IMG/GUID/MAC/PSID magic in
mstflint. For your case, if all you need to do is to write a new file
to the eeprom, you should be able to do this:
cat <binary-image> | ethtool --change-eeprom DEVNAME magic MAGIC offset
0 length `wc -c <binary-image>`
and the eeprom is written with the new data. If you need to do special
things, like Mellanox, in terms of recovering burned data like GIDs or
MACs or whatever, then you can write a tool that does that, but leaves
the EEPROM banging to the driver and just passes the buffers around
using the ethtool interface.
Really, it doesn't look hard at all, and it sounds much better than
continuing with everybody writing their own tool and reinventing the wheel.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
