size of data_segs_[in|out] and segs_[in|out]

size of data_segs_[in|out] and segs_[in|out]

[rapier]

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 flow at 1500 bytes would exceed the max 
value inside of around 14.7 hours. Which seems like a long time but at 
higher rates, even with 9k packets, this could cause problems within 7.5 
hours or so (after ~36TB of data). While this is probably not an issue 
for a large number of people in the scientific community transferring 
data sets of this size is happening and likely to become far more common.

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.

Chris

Re: size of data_segs_[in|out] and segs_[in|out]

[David Miller]

From: rapier <rapier@psc.edu>
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 these datastructures
right now.

Re: size of data_segs_[in|out] and segs_[in|out]

[rapier]

On 8/8/16 7:02 PM, David Miller wrote:
> From: rapier <rapier@psc.edu>
> 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 these datastructures
> right now.

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 this will eventually need to be addressed. Since 
the segs datastructure is a relatively recent addition it might make 
sense to make that change now before it's even more baked in to other 
applications.

Re: size of data_segs_[in|out] and segs_[in|out]

[David Miller]

From: rapier <rapier@psc.edu>
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 this will eventually need to be
> addressed. Since the segs datastructure is a relatively recent
> addition it might make sense to make that change now before it's even
> more baked in to other applications.

Changing the size or position of these data structure members is
simply not an option.  It is locked into stone, and a permanent
ABI which we cannot change.

Please stop discussing as if changing this is a possibility.

You need to find another solution to the problem, or advocate a
user side solution (periodic polling).

Re: size of data_segs_[in|out] and segs_[in|out]

[rapier]

On 8/9/16 3:04 PM, David Miller wrote:
> From: rapier <rapier@psc.edu>
> 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 this will eventually need to be
>> addressed. Since the segs datastructure is a relatively recent
>> addition it might make sense to make that change now before it's even
>> more baked in to other applications.
>
> Changing the size or position of these data structure members is
> simply not an option.  It is locked into stone, and a permanent
> ABI which we cannot change.
>
> Please stop discussing as if changing this is a possibility.

I apologize, I wasn't aware of the constraints on this. There are other 
solutions available and I'll focus on those.