On 12/27/2015 12:54 PM, Moni Shoua wrote: >> Yes it is specific to Intel *now*, that doesn't mean it should stay that >> way. Rdmavt could, and in my opinion should, be extended to support >> soft-roce. I don't think replicating the same thing is a great idea. >> > But you post *now* a so called generic driver so it must now fit any > possible driver (including Soft RoCE)
This is incorrect. This isn't some public API that we are exporting to
user space. Nor is it an API that out of tree drivers are using. This
is a purely kernel internal API for use by a limited number of drivers.
As such, it need not be finalized before it is submitted or used. It
can be taken one piece at a time, and if, at some point, it is
determined that there are shortcomings to the API, it can be updated in
place with all of the drivers that use it in a single patch or patch
series. So a finalized design prior to putting code in place is
specifically *not* needed.
>> As to the location, where do you think it should go. drivers/infiniband/sw
>> makes the most sense to me, but open to suggestions.
>>
>> And for the question of why publish when it's not ready, the better question
>> is why not? Is it not good to see the work in progress as it evolves so the
>> community can provide feedback?
>>
> What kind of a feedback you expect when I don't have an idea about
> your plans for rdmavt
> Interfaces, flows, data structures... all is missing from the
> documentation to rdmavt.
They released it so that you can start hooking SoftRoCE into it. As you
hook it in, if it needs changes to work with SoftRoCE, simply make the
changes needed and move on.
I think Dennis' point, and I agree with him, is that you are over
complicating the issue here. This need not be a highly designed item,
it needs to be a functional item, and we can build it as we go. If you
have to make changes to rdmavt in order to hook up SoftRoCE, that's
fine, post them to the list, they will get reviewed. As long as the
change doesn't break or otherwise negatively impact qib and/or hfi1,
then it should be fine. If it does, then I'm sure Intel will work with
you to find a solution that doesn't negatively impact them.
--
Doug Ledford <dledf...@redhat.com>
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
