On Tue, Nov 18, 2014 at 7:14 PM, Yishai Hadas <yishaih@xxxxxxxxxxxxxxxxxx> wrote: > On 11/18/2014 4:42 PM, Or Gerlitz wrote: >> Can we somehow make this patch generic (e.g land in the IB core) such >> that it can apply also for mlx5 (and other HW drivers...) basically, the >> HW driver should tell the IB core which pages to zap and we should be >> OK, isn't that? > We introduced a generic API that asked the low level driver to detach a > given ucontext from its HW resources. The specific driver implementation may > be different between HW devices and may not involve the zap usage, that's > why it wasn't put in IB core. In addition, the zap API should be in sync > with inflight VMA closing to prevent zapping an already unmapped address. To > achieve that the driver should implement some VMA ops and synchronize > between those flows. Again, drivers that don't want to go the zapping way, could just avoid this generic code. So we have already two more low-level drivers (cxgb3/4) that would be happily using the 95% of the mlx4_ib code you wrote after the re-factoring I suggested. I tend to think mlx5_ib should join too. Why not try it out, write the code in the way which 1. under the IB core 2. easiest to use under this twist for mlx4_ib and let cxgb3/4 and mlx5 maintainers to see if/how they can use it. > That code looks like something that fit to be done in > the driver and not as part of a IB core. None of the arguments above doesn't make me get into this conclusion, open to more people, but why don't you just follow steps 1/2 above and see where it gets you? 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
