> -----Original Message----- > From: James Lentini [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 13, 2005 11:49 AM > To: Caitlin Bestler > Cc: openib-general; [EMAIL PROTECTED] > 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. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
