netdev - Re: RFC: Latency reducing TCP modifications for thin-stream interactive applications

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]

Message-ID: <Pine.LNX.4.64.0901221554240.1889@wrl-59.cs.helsinki.fi>
Date:	Thu, 22 Jan 2009 16:13:19 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	kristrev@...ula.no
cc:	Andreas Petlund <apetlund@...ula.no>,
	Netdev <netdev@...r.kernel.org>, griff@...ula.no,
	paalh@....uio.no
Subject: Re: RFC: Latency reducing TCP modifications for thin-stream       
    interactive applications

On Wed, 21 Jan 2009, kristrev@...ula.no wrote:

> >> If I have understood the code correctly, what will then be the
> >> difference
> >> between our current solution and the one you suggest (except we can
> >> remove
> >> one of the bundling methods and when a packet is retransmitted)? If I
> >> have
> >> not understood the code correctly, feel free to yell :) (if it is a
> >> misunderstanding, it also explains all the checks for skb->cloned).
> >
> > It didn't mean clone an skb but copy the relevant data into new skb which
> > is then not put into write queue at all but given to lower layers only.
> 
> Thank you, now I understand what you meant and I agree that it is a better
> solution. However, when I think of it, copying might be too resource
> intensive and thus remove all gains from RDB. We have seen streams with 
> small packets and very low interarrival times, which would lead to a large
> number of copy-operations every second. I will implement it and compare
> performance.

The latencies caused by network related problems are hardly in the same 
order of magnitude than processing latencies due to simple alloc + copy of 
<= mss sized content, and if data is in frags you won't be copying even 
that much. For every avoided retransmission (with the associated rtt 
latency) you can copy a lot of data.

Ah, one more thing I already forgot earlier... Your solution is lacking 
means to deal with ambiguity problem which is a serious problem since
RTT measurements are valid only if there was not ambiguity.

-- 
 i.
--
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