On Mon, Mar 12, 2018 at 01:47:30PM -0500, Steve Wise wrote:
>
> > On Mon, Mar 12, 2018 at 11:13:03PM +0530, Raju Rangoju wrote:
> > > diff --git a/include/uapi/rdma/cxgb4-abi.h
> b/include/uapi/rdma/cxgb4-abi.h
> > > index e82cfd69c3f8..f603ef9d7e97 100644
> > > +++ b/include/uapi/rdma/cxgb4-abi.h
> > > @@ -51,7 +51,8 @@ struct c4iw_create_cq_resp {
> > > __u32 cqid;
> > > __u32 size;
> > > __u32 qid_mask;
> > > - __u32 reserved; /* explicit padding (optional for i386) */
> > > + __u32 reserved[2]; /* explicit padding (optional for i386) */
> > > + __u32 cqe_size;
> > > };
> >
> > Any reason not to use the existing reserved? If yes add a comment.
> >
> > It is customary to put new reserved at the end so they can be used the
> > next time the struct is updated.
> >
> > Make sure the result is a multiple of 8 bytes, I didn't check.
> >
>
> The reason was we want the kernel side to "know" based on the size of this
> structure if the user side is supporting this new feature (CQE moving from
> 32B -> 64B). Reusing the reserved field wont' allow that run-time
> determination.
Hurm, usually a bit safer to be explicit when doing feature
negotiation, eg rename reserved to flags and set a 64B CQE flag in
it..
I had guessed that is what cqe_size was doing?
> Raju, add comments to make this explicit.
And put the new reserved at the end then..
Jason
--
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
