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] [day] [month] [year] [list]

Date:	Sat, 3 Mar 2007 14:27:46 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	David Miller <davem@...emloft.net>
cc:	baruch@...en.org, netdev@...r.kernel.org
Subject: Re: [PATCH 4/4]: Kill fastpath_{skb,cnt}_hint.

On Sat, 3 Mar 2007, Ilpo Järvinen wrote:
> On Fri, 2 Mar 2007, David Miller wrote:
> > From: Baruch Even <baruch@...en.org>
> > Date: Thu, 1 Mar 2007 20:13:40 +0200
> 
> > > 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.
> 
> Maybe this information in the last ACK could be even used as advantage to 
> speed up the startpoint lookup, since the last ACK very likely contains 
> the highest SACK block (could not hold under attack though), no matter how 
> big it is, and it's not necessary to process it ever if we know for sure 
> that it was the global highest rather than a local one. Using that, it's 
> trivial to find the starting point below the SACK block and that could be 
> passed to the head_lost marking on-the-fly using stack rather than in the
> structs. Sort of fastpath too :-)... Maybe even some auto-tuning thingie 
> which enables conditionally skipping of large SACK-blocks to reuse all of 
> this last ACK information in mark_head but that would get rather 
> complicated I think.

Even better, adding to more the globally highest SACKed block range that 
is already larger than tp->reordering does nothing in mark_head_lost 
unless ca_state or high_seq are also changed (just a quick thoughts, 
it might be possible to exclude also them with careful analysis of state), 
isn't that so? But taking advantage of this might require inter-ACK state 
and be then less useful optimization. So only thing that would remain is 
the check for timedout above the highest SACKed block...

-- 
 i.