Re: [RFC] Proposal to address hfi1 UI and EPROM devices

Dennis Dalessandro
2016-05-04T12:20:45Z

On Tue, May 03, 2016 at 09:42:18PM +0300, Leon Romanovsky wrote:
>On Tue, May 03, 2016 at 12:54:05PM -0400, Dennis Dalessandro wrote:
>> On Tue, May 03, 2016 at 07:24:57PM +0300, Leon Romanovsky wrote:
>> >On Mon, May 02, 2016 at 03:55:02PM -0400, Dennis Dalessandro wrote:
>> >>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.
>> >
>> >Just to understand better your RFC. Are you asking from the community
>> >excuse do not implement core functionality just because you don't need
>> >it? Am I right?
>>
>> The purpose of the RFC is to get the community's feedback on our plans to
>> solve our UI/EPROM issue. The paragraphs [1] not snipped in your response
>> focus on that. It comes down to:
>>
>> Use resource0 which does not support locking vs use a file in
>> /sys/kernel/debug.
>
>I didn't quote the whole email because I didn't see any question in
>these 3 options:
>* First option - doesn't meet the requirements and hard to extend.
>* Second option - doesn't meet the requirements and HW limitations
>* Third option - presented as one possible option and looks like the
> correct one.
>
>And the real question is "where" do you need to implement third option.

As in where would it be visible? That would be in /sys/kernel/debug/hfi1.
We have some counters and stats there already. Based on Jason's response
I'm thinking we can use that just for the locking aspect.

-Denny