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 sake of
bre
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 sake of
> breaking things but my feeling is that
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 wo
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 would break every application looking at
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
