On Sat, Aug 1, 2015 at 11:34 PM, Doug Ledford <dledford@xxxxxxxxxx> wrote: > On 07/31/2015 03:34 AM, Christoph Hellwig wrote: >> On Fri, Jul 31, 2015 at 02:05:06AM +0300, Or Gerlitz wrote: >>> So... enough is enough, please put it in a kernel module residing in >>> the IB core and use it in this driver, to begin with. The fact that >>> ipath is going to go, makes the cope duplication "only" 2X vs the 3X, >>> but it's still 2X >> Agreed. Any if anyone tries to submit software RoCE again it'll be >> another duplication. > Or, I haven't looked at the soft-roce driver (ever). Is it going to > need this library as well? If it is, then as you have rung the bell for > getting this library written, I will expect Mellanox to work with Intel > to make sure that this library is suitable for not just their hardware > drivers but also the soft-roce driver you guys are working on. Doug, I'd like to make sure we're on the same page here: the upstream kernel currently contains two SW implementations of IB transports, namely within ipath and qib, the OPA driver is the third in that row, and this is without any reason I can think of. If we agree on that, this by itself justifies the OPA developers to come up with factoring out the bits from qib and the OPA driver into a library which is to be used by the two drivers. As for soft-roce, indeed, that driver would uses SW implementation as well, and it when we review this proposed library it should be usable there too. One thing to take into account for that triple use-case would be a layered breakdown, e.g to have the shared code deal with the transport (L4) level without deep assumptions on the lower layers. [...] > if the soft-roce driver needs the library too, and it is > not yet in a state to be submitted and even not in a state where its > needs can be articulated clearly so that the library can be written with > soft-roce's needs in mind as well as the Intel driver's needs, then I'll > let the hfi1 driver out of staging before that task is complete and > we'll just get to the library when we have all of the stake holders in > place and can actually work on all of them at once. Doug, this I can't understand, why have in upstream the same functionality implemented three times: ipath, qib and hfi1?! Or. -- 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
