On Mon, Mar 12, 2018 at 1:39 PM, Steve Wise <swise@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> 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...
Just make sure reserved is reliably set to 0 by the existing user space.
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
