On 8/9/16 3:04 PM, David Miller wrote:
From: rapier
Date: Tue, 9 Aug 2016 13:17:59 -0400
I cannot deny that would be a problem but conversely, those
applications are currently in a position where they may be depending
on inaccurate data. I'm not advocating breaking things for the sa
On 8/8/16 7:02 PM, David Miller wrote:
From: rapier
Date: Mon, 8 Aug 2016 18:02:29 -0400
As such, would it be feasible to define these instruments as 64bit
instead of 32bit? If so, a cursory look at the code seems to indicate
that this would only require a change in the header files.
It
The instruments for data_segs_in, data_segs_out, segs_in, and segs_out
(along with the corresponding tcpi_ variables) are currently defined as
unsigned 32 bit ints. While this is in line with RFC4898 I'm thinking
that for some flows this value might be too small.
For example, a 1GB sustained f
On 4/15/15 5:01 PM, Eric Dumazet wrote:
On Wed, 2015-04-15 at 15:31 -0400, rapier wrote:
All,
First, my apologies if this came up previously but I couldn't find
anything using a keyword search of the mailing list archive.
As part of the on going work with web10g I need to come up
All,
First, my apologies if this came up previously but I couldn't find
anything using a keyword search of the mailing list archive.
As part of the on going work with web10g I need to come up with baseline
TCP stack performance for various kernel revision. Using netperf and
super_netperf* I'
