[openib-general] [PATCH] iWARP Include File Changes

[Caitlin Bestler]

openib-general-bounces at openib.org wrote:
> On Wed, 2006-02-01 at 13:34 -0800, Sean Hefty wrote:
>>> enum ib_device_cap_flags {
>>> @@ -86,6 +87,14 @@
>>> 	IB_DEVICE_RC_RNR_NAK_GEN	= (1<<12),
>>> 	IB_DEVICE_SRQ_RESIZE		= (1<<13),
>>> 	IB_DEVICE_N_NOTIFY_CQ		= (1<<14),
>>> +	IB_DEVICE_IN_ORD_PLCMNT         = (1<<15),
>>> +	IB_DEVICE_ZERO_STAG             = (1<<16),
>>> +	IB_DEVICE_SEND_W_INV            = (1<<17),
>>> +	IB_DEVICE_MW                    = (1<<18),
>>> +	IB_DEVICE_FMR                   = (1<<19),
>>> +	IB_DEVICE_SRQ                   = (1<<20),
>>> +	IB_DEVICE_ARP                   = (1<<21),
>>> +	IB_DEVICE_LLP                   = (1<<22),
>>> };
>> 
>> I have a couple of questions below, but does anyone object to this
>> portion of this patch (with some possible renaming)?
>> 
>> Does in order placement indicate that a technique that polls memory
>> can be used to determine if remote data has been received?
> 
> yes.
>

To be precise it indicates that *this* end can certify that
its placements to memory will become visible to the local
processor in the order that they were posted on the remote
side.

There is NOTHING that can tell you how your peer behaves.
The best you can do is trust your peer to relay this info
to you, but you can't know that they did so correctly.

Also note that like many device attributes that this is
read-only. You cannot *tell* your device to work this way.
 
>> 
>> Can you also describe how a user would use ARP and LLP flags?
> 
> ARP == the rnic device handles ARP entirely for iwarp
> connections. The amso1100 device does this.  Otherwise, it is
> assumed the native stack will do ARP to resolve MAC addresses
> for the rnic.  The IW CM will use this to determine whether
> it needs to initiate ARP during
> rdma_resolve_addr() processing.
> 
> LLP == the device exposes TCP connect methods.  This
> capability isn't supported by the IW CM patch nor the
> Amso1100.  It for future devices that might expose TCP
> connect methods.  Some protocols that sit on top of iwarp
> require this.  iSER in its current form would require this, for
> instance. 
> 
> 

Devices that supported this flag would enable common
device-independent code, but transport specific, code
to perform RDMA enabling negotiations. Without this
capability, this common logic must rely on device
specific implementations.

In the long run we want to avoid duplicating logic,
especially if the logic is in the driver rather than
on the device.