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
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
