On Tue, 2006-02-28 at 23:03 +0200, Michael S. Tsirkin wrote: > Quoting Tom Tucker <[EMAIL PROTECTED]>: > > > 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. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
