[ofa-general] Re: why is CPU util/service demand so much higher withSDP than TCP?
Michael S. Tsirkin
mst at dev.mellanox.co.il
Fri Apr 27 06:32:24 PDT 2007
This will poll CQ before going to sleep.
You can try tuning this module option if you like - but
from I saw the defaults are generally OK.
Quoting SEGERS Koen <Koen.SEGERS at VRT.BE>:
Subject: RE: [ofa-general] Re: why is CPU util/service demand so much higher withSDP than TCP?
Can you give more information on what this recv_poll module does? We are not interested in latency, but in throughput. Do we need to change this module for this setup?
Regards,
Koen
________________________________
Van: general-bounces at lists.openfabrics.org namens Michael S. Tsirkin
Verzonden: vr 27/04/2007 6:23
Aan: Rick Jones
CC: general at lists.openfabrics.org
Onderwerp: [ofa-general] Re: why is CPU util/service demand so much higher withSDP than TCP?
> Quoting Rick Jones <rick.jones2 at hp.com>:
> Subject: why is CPU util/service demand so much higher with SDP than TCP?
>
> So, while playing around with my new netperf SDP_RR test I've noticed that
> a single-byte _RR test over SDP has a much higher transactions per second
> (ie lower latency) than over TCP over the same HCA, but the CPU utilization
> is _very_ much higher and the service demand (cpu per transaction) as well.
> CPU util being higher makes sense with a higher transaction rate, but not
> the increased service demand - well at least not to my experience thusfar.
That's expected.
SDP by default uses polling aggressively to trade off service demand for latency.
You can play with recv_poll module parameter to tune that.
--
MST
_______________________________________________
general mailing list
general at lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
*** Disclaimer ***
Vlaamse Radio- en Televisieomroep
Auguste Reyerslaan 52, 1043 Brussel
nv van publiek recht
BTW BE 0244.142.664
RPR Brussel
http://www.vrt.be/disclaimer
--
MST
More information about the general
mailing list