On Wed, May 18, 2005 at 10:07:52PM +0300, Michael S. Tsirkin wrote: ... > > obvious place to do the work. I guess that's a political > > argument for doing the work in netperf. I'll think about it more > > and talk to the netperf maintainer later this week. > > Fair enough - the more the merrier.
Rick Jones thinks it should be straight forward to add netperf_ib.c. I'll work with him to update his silly HPUX box to a more silly parisc-linux box so we can run subversion. Then I can start "borrowing" code from rmda_lat to do the same things using netperf infrastructure. > I'd like to re-iterate what I am trying to do currently: > - show how to utilize uverbs efficiently > - get a benchmark useful e.g. for hardware tuning and/or testing > > For both these goals its very important for the test to be simple > and readable - netperf sure is not it. Yes, I agree with both the goals and rdma_lat covers those pretty well already. I think netperf is more interesting for more complex stuff since it has slightly different goals and serves a different purpose. (e.g. binding tasks to CPUs and reporting statistics) I'll finish up cleaning up rmda_lat and then use it as an example (like you intended) to add IB functionality into netperf. > I started with latency and am looking at bandwidth now, it seems these > may be part of the same test If the two tests can share code, I'd rather see two example tests and parts of rdma_lat.c split off into a seperate file. I expect all the socket handling and context setup stuff could be shared. The more bells and whistles you add to rdma_lat, the further it gets away from your primary goal (simple, efficient example). >- but CPU utilization may be harder. Isn't the use of get_cycles() a sufficient form of CPU utilization for the two goals above? Or is there more kernel overhead we aren't catching somehow? grant _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
