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

[Caitlin Bestler]

openib-general-bounces at openib.org wrote:
> ...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? 
> 

Allowing a change to an active ring that a NIC is the producer
to will adversely impact performance. Logically reducing the
size of a ring (without actually changing the allocation) is
feasible, but I'm not sure what benefit it has for a general
purpose L2 ring (as opposed to L4 or above).

Additionally, unlike L4 and above, knowing that the ring is idle
isn't really that feasible for L2.

Would allocating the maximum size and then logically limiting
it be useful for what you are attempting?