Quoting r. Tom Tucker <[EMAIL PROTECTED]>: > 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 <[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
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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
