Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753189AbZAGLEI (ORCPT ); Wed, 7 Jan 2009 06:04:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752220AbZAGLD6 (ORCPT ); Wed, 7 Jan 2009 06:03:58 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1]:52919 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751521AbZAGLD5 (ORCPT ); Wed, 7 Jan 2009 06:03:57 -0500 Date: Wed, 7 Jan 2009 13:03:55 +0200 (EET) From: "=?ISO-8859-1?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@wrl-59.cs.helsinki.fi To: Arnd Hannemann cc: LKML , Netdev Subject: Re: [PATCH][TCP]: simplify tcp_mark_lost_retrans() In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-696208474-1828886473-1231326235=:27307" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2317 Lines: 58 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---696208474-1828886473-1231326235=:27307 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 7 Jan 2009, Ilpo J?rvinen wrote: > On Wed, 7 Jan 2009, Arnd Hannemann wrote: > > > I noticed > > Good that somebody else is looking TCP code besides me... :-) > > > that in tcp_mark_lost_retrans the for-loop is only entered > > if tcp_is_fack(tp) evaluates to true: > > > > if (!tcp_is_fack(tp) || !tp->retrans_out || > > !after(received_upto, tp->lost_retrans_low) || > > icsk->icsk_ca_state != TCP_CA_Recovery) > > return; > > > > Therefore the following check in the for-loop seems to be redundant, > > because it always evaluates to true: > > > > (tcp_is_fack(tp) || > > !before(received_upto, > > ack_seq + tp->reordering * tp->mss_cache)) > > > > Did I miss something? > > It was just a left over from the RFC3517 SACK addition which added that > !tcp_is_fack(tp) there above. ...It would have been nice to have similar > lost rexmit feature without FACK as well but calculating that wasn't > trivial (or I didn't find that too trivial) and could end up being > extremely expensive in case of large holes. (So I also left it there as > sort of reminder). > > On the second thought, it would be possible to count skbs we pass while > walking from the beginning and use that a remaining_sacked counter > to get rid of all heurestics too and base the counting only on sacked > stuff which aligns with the spirit of rfc3517 much better than > sacked+holes used by fack. Nah, tried to do that that wasn't working nicely either... Since there is a need to know how many sack blocks reside between ack_seq and received_upto, not the number of sack blocks between skb and received_upto... -- i. ---696208474-1828886473-1231326235=:27307-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/