[EMAIL PROTECTED] wrote: > 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. >
Being able to define transport specific fields in a transport specific header file would be a major benefit. I think it trumps all the other factors cited. The only trick is avoiding an extra layer of indirection for any fastpath operations. So we may want to keep all fastpath operations transport neutral, at least on a syntax basis, to avoid the extra dereference. I'm not sure there are any, though. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
