[openib-general] [PATCH/RFC] IB/ipoib: add selective tx signaling - performance measurements

[Moni Shoua]

Michael S. Tsirkin wrote:
>>>>Tests with iperf and netperf for unicast and multicast destinations show
>>>>an improvement in the ability of user applications to xmit packets. 
>>>>
>>>>Examples: Number of successful writes as reported by 30 seconds UDP_STREAM of 100 byte packets.
>>>>Tested with netperf on Dual CPU (64bit Intel Xeon 3GHz) running linux-2.6.20-rc1 (sender) and
>>>>OFED-1.1 (receiver)
>>>
>>>
>>>IMO netperf reporting is actually not too informative without stats settings.
>>>Try running with e.g. -i 10,2 -I 99,5 - you might discover that your numbers are
>>>only accurate within 30%
>>
>>I tried that and I am getting a warning about confidence level not being
>>achieved.  I am still trying to learn about that and trying to understand why
>>(any ideas?) but for the meantime can you explain why do I need statistics when
>>I am only trying to count the number of successful writes?
> 
> 
> Otherwise your results could be just noise.
I'm sorry but I don't understand how can it be noise. I am not measuring average nor PPS (or BW) but
true a counter (number of total sent packets) so confidence seems irrelevant here.
Anyway, port counters and device counters show the same number as netperf so I guess this is
the real confidence.

> 
> 
>>>>Note that the results below show improvement only for TX so we see an end to end packet loss.
>>>
>>>
>>>Hmm, as long as packet drops increase, BW improvements in UDP don't sound
>>>too convincing, do they? You can get infinite BW at 100% drop ...
>>>
>>>
>>>
>>>>Improving the receiver (NAPI) will reduce the packet loss. 
>>>
>>>
>>>Needs testing with NAPI patch then?
>>
>>I tried NAPI and I get better results for the receiver but my opinion is that
>>the receiver side is less important here since all I'm trying to improve is
>>the ability to send packets. Am I right?
> 
> 
> Only if you are sure something else is not dropping the packets (e.g.
> buffer overruns triggered).
>