Re: qlen check in tun.c

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

On 06/19/2013 01:42 PM, Jerry Chu wrote:
> On Wed, Jun 19, 2013 at 12:49 PM, Rick Jones <rick.jones2@hp.com> wrote:
>> Assuming this single-stream is a netperf test, what happens when you cap the
>> socket buffers to 724000 bytes?  Put another way, is this simply a situation
>> where the autotuning of the socket buffers/window is taking a connection
>> somewhere it shouldn't go?
>
> You have a good point - for single netperf streaming the TCP window seems to
> grow much larger than necessary. Manually capping socket buffer seems to make
> the problem go away without hurting throughput - but only to some extent.
> Unfortunately manual setting is undesirable, and the autotuning code
> is difficult to "tune".
>

...

>> Just what is the bandwidthXdelay product through the openvswitch?
>
> Unlike the traditional NIC, for tuntap it'd be CPU b/w times scheduling delay.
> Both can have a large variance. I haven't figured out how to right size the
> qlen in this scenario.

In perhaps overly broad, handwaving terms, doesn't wireless have a 
similar problem with highly variable latency/delay?

In theory, if your max scheduling delay is 10 milliseconds, your still 
not large enough 8192 entry queue should still get you 1 GB/s assuming 
that it is >> 1 GB/s between scheduling delays.   Is there really an 
expectation/requirement to get better than that or have even larger 
scheduling delays?  The existence of 40 and 100 GbE (even bonded 10GbE) 
notwithstanding, once one is talking about 1 GB/s one is looking more at 
SR-IOV I would think, not going through an Openvswitch.

Do you actually still see single-stream drops at 8192?  That should be 
something like 11 MB of queuing - I don't think I've seen tcp_[wr]mem go 
above 6 MB thusfar...

rick