Hi,
While looking through the users of fackets_out, i found this from
tcp_fragment(...):
/* If this packet has been sent out already, we must
* adjust the various packet counters.
*/
if (!before(tp->snd_nxt, TCP_SKB_CB(buff)->end_seq)) {
int diff = old_factor - tcp_skb_pcount(skb) -
tcp_skb_pcount(buff);
[...snip...]
if (diff > 0) {
/* Adjust Reno SACK estimate. */
if (!tp->rx_opt.sack_ok) {
tp->sacked_out -= diff;
if ((int)tp->sacked_out < 0)
tp->sacked_out = 0;
tcp_sync_left_out(tp);
}
tp->fackets_out -= diff;
if ((int)tp->fackets_out < 0)
tp->fackets_out = 0;
}
}
[...]
There are IMHO two problems in it. First of all, nothing ensures that the
skb TCP is fragmenting is actually below the forwardmost sack block (and
thus is included to the fackets_out)... What I'm not sure of though, is
how to fix this in net-2.6(.22), it is due to the fact that there is no
pointer/seq which can be used in testing for it like in tcp-2.6 which has
the highest_sack. Second problem is even more obvious: if adjustment here
is being done and the sacktag code then uses fastpath at the arrival of
the next ACK, the sacktag code will use a stale value from
fastpath_cnt_hint and fails to notice all that math TCP did here unless we
start clearing fastpath_skb_hint.
--
i.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
