> 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?
Yes. Renaming the reserved field to flags and adding a 64B CQE flag will
work and be more explicit...
--
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
