TSO and netfilter (Re: Extremely slow network with e1000 & ip_conntrack)

From: Harald Welte <laforge@netfilter.org>
To: "David S. Miller" <davem@redhat.com>
Cc: Stephen Lee <mukansai@emailplus.org>,
	scott.feldman@intel.com, netfilter-devel@lists.netfilter.org,
	linux-kernel@vger.kernel.org
Subject: TSO and netfilter (Re: Extremely slow network with e1000 & ip_conntrack)
Date: Thu, 11 Dec 2003 12:03:15 +0100	[thread overview]
Message-ID: <20031211110315.GJ22826@sunbeam.de.gnumonks.org> (raw)
In-Reply-To: <20031205122819.25ac14ab.davem@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2121 bytes --]

On Fri, Dec 05, 2003 at 12:28:19PM -0800, David S. Miller wrote:

> Some auditing is definitely necessary wrt. TSO and netfilter.  In particular
> I am incredibly confident that we have issues in cases like when the FTP
> netfilter modules mangle the data.

I didn't have a look into how TSO is implemented until today.  From my
naive point of view, I cannot think of any issues.  From a netfilter
point of view, a TSO-enabled skb just looks like a single large packet,
right?

I mean, the TSO-enabled skb still contains a fully valid IP and TCP
packet.  If we do any changes to the IP header or tcp header bits, or
even to the payload of the packet, this happens before the TSO-enabled
driver and the network board start creating multiple tcp/ip datagrams
from this skb (by using the information present in the
netfilter-modified ip/tcp headers).

The only interesting case is in ip_output.c:ip_queue_xmit(), where
tso_size and tso_segs are calculated, before NF_IP_LOCAL_OUT is run.

But changing the content or the size of the tcp payload should not
affect those calculations. 

A real problem would be resizing the TCP header (where th.doff is
affected).  But I cannot think of any case where any of the current
netfilter/iptables/conntrack/nat code does that.  Even in the past, when
we used to remove SACKPERM from the tcp header, we just NOP'ed it out
instead of resizing the header.

> Another area for inspection are the cases where TCP header bits are
> changed and thus the checksum needs to be adjusted.

Why is this a problem?  The netfilter code has to adjust the checksum
anyway... or is the checksum calculation for TSO-enabled skb's
different?

Please enlighten me if I have missed something.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]