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

[Michael S. Tsirkin]

Quoting r. Tom Tucker <tom at opengridcomputing.com>:
> Subject: Re: [openib-general] Re: [PATCH] RFC Verbs: add support for transport specific verbs
> 
> 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

8 rather than 7 then, not too bad.

> > 
> > > 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.

Okay, but lets try to avoid adding runtime overhead.

> This lessens the risk that a change in one transport's verbs
> will regress the other. 

I dont see how - the union size will likely change anyway.

> > 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.

Then at least lets make it a structure, not a union.
This way a single test is sufficient to figure out whether
a specific function is supported.

-- 
Michael S. Tsirkin
Staff Engineer, Mellanox Technologies