[openib-general] Re: Re: IBM utilizing and testing openIB release 1 RCx

Christoph Raisch RAISCH at de.ibm.com
Mon Mar 27 03:03:07 PST 2006


...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,

openib-general-bounces at openib.org wrote on 27.03.2006 09:40:41:

> Quoting r. Shirley Ma <xma at us.ibm.com>:
> > 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
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general




More information about the general mailing list