On Fri, 2018-02-02 at 16:07 +0000, Bart Van Assche wrote: > On Fri, 2018-02-02 at 15:08 +0100, Roman Pen wrote: > > Since the first version the following was changed: > > > > - Load-balancing and IO fail-over using multipath features were added. > > - Major parts of the code were rewritten, simplified and overall code > > size was reduced by a quarter. > > That is interesting to know, but what happened to the feedback that Sagi and > I provided on v1? Has that feedback been addressed? See also > https://www.spinics.net/lists/linux-rdma/msg47819.html and > https://www.spinics.net/lists/linux-rdma/msg47879.html. > > Regarding multipath support: there are already two multipath implementations > upstream (dm-mpath and the multipath implementation in the NVMe initiator). > I'm not sure we want a third multipath implementation in the Linux kernel. There's more than that. There was also md-multipath, and smc-r includes another version of multipath, plus I assume we support mptcp as well. But, to be fair, the different multipaths in this list serve different purposes and I'm not sure they could all be generalized out and served by a single multipath code. Although, fortunately, md-multipath is deprecated, so no need to worry about it, and it is only dm-multipath and nvme multipath that deal directly with block devices and assume block semantics. If I read the cover letter right (and I haven't dug into the code to confirm this), the ibtrs multipath has much more in common with smc-r multipath, where it doesn't really assume a block layer device sits on top of it, it's more of a pure network multipath, which the implementation of smc-r is and mptcp would be too. I would like to see a core RDMA multipath implementation soon that would abstract out some of these multipath tasks, at least across RDMA links, and that didn't have the current limitations (smc-r only supports RoCE links, and it sounds like ibtrs only supports IB like links, but maybe I'm wrong there, I haven't looked at the patches yet). -- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
Attachment:
signature.asc
Description: This is a digitally signed message part
