From: Baruch Even [EMAIL PROTECTED]
Date: Fri, 26 Jan 2007 08:40:09 +0200
You actually need recv_sack_cache to detect if you can use the fast
path. Another alternative is to somehow hash the values of the sack
blocks but then you rely on probabilty that you will properly detect the
ability to
On Thu, 25 Jan 2007 20:29:03 +0200
Baruch Even [EMAIL PROTECTED] wrote:
The sorting of SACK blocks actually munges them rather than sort, causing the
TCP stack to ignore some SACK information and breaking the assumption of
ordered SACK blocks after sorting.
The sort takes the data from a
The sorting of SACK blocks actually munges them rather than sort, causing the
TCP stack to ignore some SACK information and breaking the assumption of
ordered SACK blocks after sorting.
The sort takes the data from a second buffer which isn't moved causing
subsequent data moves to occur from the
* Stephen Hemminger [EMAIL PROTECTED] [070125 20:47]:
On Thu, 25 Jan 2007 20:29:03 +0200
Baruch Even [EMAIL PROTECTED] wrote:
The sorting of SACK blocks actually munges them rather than sort, causing
the
TCP stack to ignore some SACK information and breaking the assumption of
ordered
From: Baruch Even [EMAIL PROTECTED]
Date: Thu, 25 Jan 2007 20:29:03 +0200
The sorting of SACK blocks actually munges them rather than sort, causing the
TCP stack to ignore some SACK information and breaking the assumption of
ordered SACK blocks after sorting.
The sort takes the data from a
From: Baruch Even [EMAIL PROTECTED]
Date: Thu, 25 Jan 2007 20:29:03 +0200
The sorting of SACK blocks actually munges them rather than sort, causing the
TCP stack to ignore some SACK information and breaking the assumption of
ordered SACK blocks after sorting.
The sort takes the data from a
* David Miller [EMAIL PROTECTED] [070126 01:55]:
From: Baruch Even [EMAIL PROTECTED]
Date: Thu, 25 Jan 2007 20:29:03 +0200
The sorting of SACK blocks actually munges them rather than sort, causing
the
TCP stack to ignore some SACK information and breaking the assumption of
ordered
