[openib-general] makiing ibverb.h transport neutral -- 2nd draft

[Caitlin Bestler]

> -----Original Message-----
> From: James Lentini [mailto:jlentini at netapp.com] 
> Sent: Wednesday, July 13, 2005 11:49 AM
> To: Caitlin Bestler
> Cc: openib-general; rdma-developers at lists.sourceforge.net
> Subject: RE: [openib-general] makiing ibverb.h transport 
> neutral -- 2nd draft

> 
> Ok, so each file will be (directly) included by a different type of
> user: rdma_verbs.h by generic RDMA consumers, ibonly_verbs.h 
> (which will become ib_verbs.h) by IB consumers, and 
> iwarp_verbs.h by iwarp consumers.
> 
> In that case, why does the rdma_device structure in 
> rdma_verbs.h contain entries for functions with IB specific 
> types (query_gid, modify_device, process_mad, etc.)? 
> Shouldn't these be in the ib specific header?
> 
> Keeping knowledge of the IB types in ib_verbs.h would remove 
> the need to define the ib_gid type before including 
> rdma_verbs.h in ib_verbs.h. 
> Include files that require certain symbols to be defined 
> before they can be included can quickly become difficult to maintain.
> 

The trade-off here is whether there is a single device struct defined,
or whether some existing IB-only methods can remain in their current
home in order to simplify use of the method table.

The current proposal opts for the latter, on the theory that defining
empty struct types and not filling in meaningless method points is not
really a burder for iWARP providers.

Basically, iWARP providers don't have modifiable port attributes, so 
it doesn't really matter what the type of the argument is since there
wouldn't be an implementation.

My assumption here is that all meaningful port attributes for an iWARP
RNIC would already be fully controlled through the IP stack (IP Address,
MTU, etc.) and SHOULD NOT/MUST NOT have conflicting controls being
introduced via the RDMA stack. Or put another way, there are no RDMA
layer port attributes for iWARP. There are at best some transport
layer attributes that might be reported as a convenience to RDMA
developers.

Given that, it seemed silly to rename these iWARP-irrelevant types
to "rdma_xxx" just so that they fit the naming profile a bit better
when all code that actually used them would be IB specific.