[ewg] the default CQ moderation parameters patch in OFED 1.3

[Or Gerlitz]

For some reason, the message below was not delivered to the list

Or Gerlitz wrote:
> Eli Cohen wrote:
>> On Sun, 2008-01-06 at 10:47 +0200, Or Gerlitz wrote:
> 
>>> The patch below in OFED 1.3 does not check the device capabilities and hence
>>> always fail on non connectx systems. Can you fix it such that we will not
>>> get all those "why I we mthca0: failed to modify CQ params prints in the logs".
> 
>> I chose to use KERN_INFO to indicate that it is not a sever situation.
>> Perhaps I should just remove the message.
> 
> I see, however, is there any problem to check the device capabilities before issuing the call or to print error message only if the return value is not ENOSYS?
> 
>>> Other then that and maybe even more important... I understand that it hard codes
>>> ipoib to ask for delivery of interrupt only after MAX (16 packets received, 10 us
>>> elapsed since first packet received), correct? so every simple ping-pong test that
>>> measures IPoIB latency under small packet rate will have now 10us added to its latency?
> 
>> I did not notice that this deteriorates ping pong latency. Could you
>> check if it does?
> 
> Yes, I run a simple datagram sockets ping-pong test on a pair of connectx (HW device 25418 FW 2.3.0 SW OFED-1.3-rc1) systems we have here and you can see that there's a ~10us different in the latency between the case of waiting for 16 frame vs 1 frame to deliver an interrupt.
> 
>> # ethtool -C ib1 adaptive-rx on rx-usecs 10 rx-frames 16
>> # /tmp/udp_lat -c -i 193.168.80.11
>> client_sig_handler:client_counter=26162 in 1 sec, latency=19.111 [usec]
> 
>> # ethtool -C ib1 adaptive-rx on rx-usecs 10 rx-frames 1
>> # /tmp/udp_lat -c -i 193.168.80.11
>> client_sig_handler:client_counter=50667 in 1 sec, latency=9.878 [usec]
> 
> Or.
> 
> 
>