Re: [PATCH for-3.7 0/4] mlx4 SRIOV fixes, 64B CQE/EQE patches re-spin

On Thu, Oct 18, 2012 at 4:58 PM, Roland Dreier [off-list ref] wrote:

On Wed, Oct 17, 2012 at 9:42 AM, Or Gerlitz [off-list ref] wrote:

quoted

Also, a respin of the 64B CQE/EQE patches (kernel and user-space), over
the V1 posting
you were asking for max flexibility - e.g expose/force update of guests
only if needed
and similarily for libmlx4, I think I have this now, would love feedback
though.

I tested this with both modified/non-modified mlx4 guest drivers, and
with
both modified/non-modified libmlx4. The only pain point I was hitting,
if non modified libmlx4 on systems with CX3 and modified kernel, on
the V1 discussion Roland -- you made a comment we might need a module
param
here to provide admins a way to let systems with old libmlx4 to work
with fresh kernels?!

So I don't think this change (which changes the kernel ABI) is appropriate
for 3.7 after the merge window in any case.

With that said I think we need a stronger compatibility story even for
3.8.
Suppose I'm running a virtualized system with SR-IOV, and I have a stable
guest that is working perfectly.  Then I want to update the hypervisor to
a newer kernel to get more KVM features or something.

If that kernel update enables 64B CQEs, then my guest is now broken.
And I don't want to force a guest update just to get a new hypervisor.

So I think we need some flag passed to the mlx4_core (that drives the
PPF) that lets the user opt into 64B CQEs.  I would suggest that we
start with the default value be "disabled" and then flip that after a few
kernel versions (and print something in the kernel log when we detect
64B-CQE-capable HW when we're running with 64B CQEs disabled).

Unfortunately because the 64B CQE setting is global for the whole
adapter (instead of being per-CQ), I don't see any better way to
support old userspace/guest kernels.

OK, let it be, will resubmit with that flag,

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html