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

Date:	Tue, 20 Jan 2009 17:45:52 +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

Trimmed all but netdev (and .no addresses) from cc list.

On Fri, 16 Jan 2009, kristrev@...ula.no wrote:

> >> We have to admit we don't quite see the problem. Since a page can never
> >> be removed before all owners have decleared that they no longer needs
> >> it, all data will be correctly present. Also, since the packets are
> >> placed linearly on the queue and we don't support when SACK is enabled,
> >> no gaps will occur. But maybe we have misunderstood your comment, please
> >> let us know if that is the case.
> >
> > Yes, the problems _may_ arise because you create afaict:
> > skb->end_seq > next_skb->seq situations which is something that certainly
> > needs an audit over every single seqno operation to see that they don't
> > implicitly assume otherwise (ie., omit redundant compares)! There are
> > certainly places I know of already which will break... I'm afraid
> > that using the approach you've select you'll end up having very many
> > places needing some extra tweaking, that's why I suggested the alternative
> > approach to just construct the redundant things on-the-fly while keeping
> > the write queue as is.
> >
> 
> >> As far as we understand this comment, you want us to do it on the
> >> application layer instead? Do you mean as a middleware,
> >> application-specific solution or something similar? Also, we believe
> >> doing it on the application layer will lead to the same delays that we
> >> try to prevent, since sent data will be delayed on the transport layer
> >> in case of loss.
> >
> > No but at the time we're supposed to actually send an skb to the lower
> > layer and keeping the rest intact.
> 
> I have a small question regarding these two comments. Are you allowed to
> modify the packet data stored in a clone? Based on my understanding of the
> code and what a clone is, I thought the data was shared between the
> original and the clone. Thus, any data appended/inserted into the clone
> will also be appended to the original.

To avoid corruption you are not allowed to change data for cloned skbs.
...I'm not fully sure how this is related though.

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


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