[openib-general] Re: [PATCH] RFC Verbs: add support for transport specific verbs

[Caitlin Bestler]

openib-general-bounces at openib.org wrote:
> Quoting r. Sean Hefty <sean.hefty at intel.com>:
>> Subject: [PATCH] RFC Verbs: add support for transport specific verbs
>> 
>> Add support for transport specific extensions to the ib_device verbs.
>> Relocate process_mad as an IB specific verb.
>> 
>> This provides a mechanism to add iWarp specific functionality, such
>> as the iWarp CM calls, to ib_device.
>> 
>> Signed-off-by: Sean Hefty <sean.hefty at intel.com>
> 
> Is it worth it to separate these things out?
> Even within IB lots of methods are optional - so why cant an
> iWarp device just avoid defining process_local_mad, and IB
> device avoid defining iWarp CM ops?

Ultimately there needs to be a simple way of knowing what
is transport specific. But a naming prefix is adequate
for that purpose.

So the question becomes whether an extra layer of referencing
(requiring a little more typing, but no extra run-time cost)
is justified by the savings of not storing irrelevant pointers.

When it is just a pointer that already can be optional I'm not
sure. When it would pay off a bit more is when attributes are
segregated. But in either case it really won't amount to much.

The more critical question is which is *safer*, having NULL
values so that IB-specific code that stumbles on a iWARP QP
(or vise versa) will see NULL values (as opposed to a false
interpretation of the iWARP data) versus the safety of requiring
a more explicit decision to reference transport specific fields.

My thinking had been that the ib_ and iw_ underscores were
good enough on the latter point and that the savings of actual
data space from using a union was not justified. But that's only
a first guess / slight preference.

Is there a style precedent here in other kernel code that we
should be following?