From: Baruch Even <[EMAIL PROTECTED]>
Date: Thu, 1 Mar 2007 20:13:40 +0200
> If you take this approach it makes sense to also remove the sorting of
> SACKs, the traversal of the SACK blocks will not start from the
> beginning anyway which was the reason for this sorting in the first
> place.
>
> One drawback for this approach is that you now walk the entire sack
> block when you advance one packet. If you consider a 10,000 packet queue
> which had several losses at the beginning and a large sack block that
> advances from the middle to the end you'll walk a lot of packets for
> that one last stretch of a sack block.
>
> One way to handle that is to use the still existing sack fast path to
> detect this case and calculate what is the sequence number to search
> for. Since you know what was the end_seq that was handled last, you can
> search for it as the start_seq and go on from there. Does it make sense?
Thanks for the feedback and these great ideas.
BTW, I think I figured out a way to get rid of
lost_{skb,cnt}_hint. The fact of the matter in this case is that
the setting of the tag bits always propagates from front of the queue
onward. We don't get holes mid-way.
So what we can do is search the RB-tree for high_seq and walk
backwards. Once we hit something with TCPCB_TAGBITS set, we
stop processing as there are no earlier SKBs which we'd need
to do anything with.
Do you see any problems with that idea?
scoreboard_skb_hint is a little bit trickier, but it is a similar
case to the tcp_lost_skb_hint case. Except here the termination
condition is a relative timeout instead of a sequence number and
packet count test.
Perhaps for that we can remember some state from the
tcp_mark_head_lost() we do first. In fact, we can start
the queue walk from the latest packet which tcp_mark_head_lost()
marked with a tag bit.
Basically these two algorithms are saying:
1) Mark up to smallest of 'lost' or tp->high_seq.
2) Mark packets after those processed in #1 which have
timed out.
Right?
-
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
