On Friday, July 07/27/18, 2018 at 00:33:51 +0530, Jason Gunthorpe wrote:
> On Thu, Jul 26, 2018 at 12:51:06PM -0500, Steve Wise wrote:
> > > > struct {
> > > > - __be64 imm_data;
> > > > + __be32 mo;
> > > > + __be32 msn;
> > > > + /*
> > > > + * Use union for immediate data to be consistent
> > with
> > > > + * stack's 32 bit data and iWARP spec's 64 bit data.
> > > > + */
> > > > + union {
> > > > + struct {
> > > > + u32 reserved;
> > > > + __be32 imm_data32;
> > > > + } ib_imm_data;
> > > > + __be64 imm_data64;
> > >
> > > You guys should think carefully about this as this choice to put the
> > > 32 bit version at the end becomes a permanent wire protocol ABI for
> > > iWarp.
> > >
> > > The definition of 'imm data' is a memory image of what is put into the
> > > packet, so placing the 32 bit version of this at the end of the array
> > > on the wire seems like a strange choice.
> > >
> > > If we extend verbs, it will continue to be a memory image semantic,
> > > and I would expect the 32 bits version to be the upper chunk of the
> > > array, not the lower chunk.
> > >
> >
> > Are you assuming an LE host?
>
> endianness doesn't matter, the above always orders the imm_data_32 in
> the last 4 bytes of the imm_data.
>
> > Which brings up a point that 'imm data' is not very platform
> > independent. But I guess putting it in the upper chunk is fine.
>
> imm_data is defined as a memory image. byte 0 of imm_data in the work
> request goes into bytes 0 of the packet and comes out again at byte 0
> in the work completion.
>
> This is fully platform independent.
>
> Most apps choose to put a BE value in here, but any other
> fixed-memory-order value would be fine.
>
> You should also make sure your byte ordering on the wire is right, as
> this becomes ABI forever. Recommend to follow IB with byte 0 as byte 0
> in the packet. (I think, at least)
>
Got it. Shall interchange the imm_data32 and send out a v3.
Thanks!
-Bharat.
--
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
