Date: Wed, 17 Feb 2010 15:50:30 -0800 (PST)
Message-Id: <20100217.155030.110521237.davem@davemloft.net>
To: william.allen.simpson@gmail.com
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
       akpm@linux-foundation.org, andi@firstfloor.org
Subject: Re: [PATCH v4 4/7] tcp: input header length, prediction, and
 timestamp bugs
From: David Miller <davem@davemloft.net>
In-Reply-To: <4B77966F.1030203@gmail.com>
References: <4B7791CF.9030201@gmail.com>
	<4B77966F.1030203@gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 875
Lines: 21

From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Sun, 14 Feb 2010 01:21:35 -0500

> Don't use output calculated tp->tcp_header_len for input decisions.
> While the output header is usually the same as the input (same options
> in both directions), that's a poor assumption. In particular, Sack
> will
> be different. Newer options are not guaranteed.

And when SACK is present, tp->tcp_header_len will not match, and
therefore we won't do the header prediction fast path, what is what we
want.

And, SACK presence doesn't change tp->tcp_header_len on transmit.

Therefore, I see no need at all for this change.
--
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/