Re: First pass at MSG_FASTOPEN support in top-of-trunk netperf

[Rick Jones <rick.jones2@hp.com>]

>> There was a ~25% increase in TCP_CRR performance, even without the server
>> actually accepting the magic TCP option.  Is that actually expected?
>
> I have a locally enhanced netperf for TCP_CRR over Fast Open and I've
>   noticed the numbers can change drastically between runs. I have not got
> the time to investigate why. (Does it have to do with scheduler and CPU
> locality?) How consistent is your perf number?

I recall the performance being reasonably consistent but there has been 
a vacation of my own in the middle there so my dimm memory is a bit fuzzy :)

Historically (and going beyond just Linux) a TCP_CRR test can have some 
non-trivial run to run variation thanks to (attempted) TIME_WAIT reuse. 
  Whether that is happening to you I don't know, but it might be worth a 
look.

> I plan to submit the server side code soon and will work with you to add
> the server side support to TCP_CRR (it requires a new TCP_FASTOPEN
> socket option to enable Fast Open on a listener.)

Works for me.

happy benchmarking,

rick jones