...unfortunately there's no easy way to detect drops on the receive side. Resizing queues on the fly also means you have to modify your CQ size as well. Resizing also means that it could be CPU intense during the resize operation, so I wouldn't resize too often (if at all). And currently resizing is either not tested very strongly or not implemented yet in the device drivers. (Mellanox? Pathscale?)
I'd guess 10gig ethernet drivers are in a similiar situation. Does anybody there resize on the fly? If you look at the problem at this level it's a common functionality which should be triggered by the networking stack. But I'm not sure if it's a good idea to propose that there... on e1000 there's a TxDescriptors and RxDescriptors for queue sizes on s2io there's a tx_fifo_len, rx_ring_sz on ixgb there's a TxDescriptors and RxDescriptors ...all of these are module load time parameters. Is there a way to change these while the module is loaded? Gruss / Regards . . . Christoph Raisch ehca teamlead, ibm boeblingen lab, [EMAIL PROTECTED] wrote on 27.03.2006 09:40:41: > Quoting r. Shirley Ma <[EMAIL PROTECTED]>: > > Without each HCA vendor support resizing send/recv/completion > queue pairs, the tuning method is limited to only as loadable modules. > > Assuming that we had resize support, how would we go about IPoIB self-tuning? > SQ overruns are easy to detect, but what can be done about RQ overruns? > > -- > 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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
