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

[Tom Tucker]

On Tue, 2006-02-28 at 23:03 +0200, Michael S. Tsirkin wrote:
> Quoting Tom Tucker <tom at opengridcomputing.com>:
> > > Using process_mad as an example, we would add all 7 function 
> > > prototypes directly to ib_device.
> > 
> > ... And in fact in the end there will be more.
> 
> Oh, I hope not much more.

llp_connect, llp_accept, llp_reject, llp_listen, llp_send, llp_recv,
llp_close, net_event_notif

> 
> > This separation allows
> > one transport to change without impacting the other.
> 
> What kind of impact does adding some new field have?

It complicates the data structure and makes it somewhat more difficult
to maintain. I also like the idea that iWARP support can be added in a
separate file without hitting either ib_verbs.h or the core ib_device
structure. This lessens the risk that a change in one transport's verbs
will regress the other. 

> 
> My point is, I have to test whether the function is implemented anyway,
> so why add two checks: one for device type, another for function
> implementation? Its complicated and inefficient.
> 

I don't see these as the same thing fmr / srq are optional features
supported on both transports. MAD processing has no meaning on iWARP and
the iWARP CM verbs have no meaning in IB. We're talking about
partitioning transport specific verbs, not optional features.

> The gain in memory usgae by using union is neglidgible, since its per
> device and we dont have that many devices.
> 
I think this is true, but I don't see memory optimization as the thrust
of the proposal. I think the idea is improving maintainability.