Re: [PATCH V1 for-next 2/2] IB/mlx4_ib: Disassociate support

Or Gerlitz
2014-11-18T21:50:41Z

On Tue, Nov 18, 2014 at 7:14 PM, Yishai Hadas
<yishaih-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> 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.