netdev - Re: [PATCH 4/4]: Kill fastpath_{skb,cnt}

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070301181340.GD25760@galon.ev-en.org>
Date:	Thu, 1 Mar 2007 20:13:40 +0200
From:	Baruch Even <baruch@...en.org>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH 4/4]: Kill fastpath_{skb,cnt}_hint.

* David Miller <davem@...emloft.net> [070228 21:49]:
> 
> commit 71b270d966cd42e29eabcd39434c4ad4d33aa2be
> Author: David S. Miller <davem@...set.davemloft.net>
> Date:   Tue Feb 27 19:28:07 2007 -0800
> 
>     [TCP]: Kill fastpath_{skb,cnt}_hint.
>     
>     Now that we have per-skb fack_counts and an interval
>     search mechanism for the retransmit queue, we don't
>     need these things any more.
>     
>     Instead, as we traverse the SACK blocks to tag the
>     queue, we use the RB tree to lookup the first SKB
>     covering the SACK block by sequence number.
>     
>     Signed-off-by: David S. Miller <davem@...emloft.net>

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?

Baruch
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html