On Tue, Dec 08, 2015 at 08:08:02PM +0200, eran ben elisha wrote: > On Tue, Dec 8, 2015 at 7:17 PM, Jason Gunthorpe > <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Dec 08, 2015 at 06:54:15PM +0200, Eran Ben Elisha wrote: > >> HW is capable of 2 requestor endianness modes for standard 8 Bytes > >> atomic: BE (0x0) and host endianness (0x1). Read the supported modes > >> from hca atomic capabilities and configure HW to host endianness mode if > >> supported. > > > > Uh, isn't this a user visible thing? > > > > How will apps know if they need to swap or not? > > > > Jason > > The problem is that some HWs cannot support IB spec regarding > requester respond endianness. > By default, HWs are set to return BE respond. > If it can be configured to host endianness -> return IB_ATOMIC_HCA > if not -> return IB_ATOMIC_NONE > (Done in patch #2 in this series) > > The state of BE respond is not visible to the user (atomic cap = > IB_ATOMIC_NONE), > App should behave according to the existing API and IB spec. Okay, that sounds fine, details like that belong in the patch comments. 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
