linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: Stephen Lee <mukansai@emailplus.org>
Cc: scott.feldman@intel.com, laforge@netfilter.org,
	netfilter-devel@lists.netfilter.org,
	linux-kernel@vger.kernel.org
Subject: Re: Extremely slow network with e1000 & ip_conntrack
Date: Fri, 5 Dec 2003 12:28:19 -0800	[thread overview]
Message-ID: <20031205122819.25ac14ab.davem@redhat.com> (raw)
In-Reply-To: <20031204213030.2B75.MUKANSAI@emailplus.org>

On Thu, 04 Dec 2003 21:36:09 +0900
Stephen Lee <mukansai@emailplus.org> wrote:

> "Feldman, Scott" <scott.feldman@intel.com> wrote:
> > 
> > Try turning off TSO by disabling this code or by using "ethtool -K tso
> > off" (need version 1.8).
> 
> Yes, turning off TSO with ethtool fixed it (tested on 2.6.0-test11).  At
> least we have a workaround now.

OK, I've found out what IP conntack does that creates the problems.

In fact, it's a bug in conntrack and this ends up corrupting the TSO
packet.  This forces TSO-disabling on that connection, and
retransmission of all the data.  Then the data flows correctly so TSO
is re-enabled, and on and on and on like this.  Performance goes into
the toilet.

The culprit is net/ipv4/netfilter/ip_conntrack_standalone.c,
in ip_refrag(), it does this:

        if ((*pskb)->len > dst_pmtu(&rt->u.dst)) {
                /* No hook can be after us, so this should be OK. */
                ip_fragment(*pskb, okfn);
                return NF_STOLEN;
        }

Which fragments TSO packets, oops :)

People can confirm this analysis by applying the patch below, enabling
TSO with conntrack loaded, and see if the problem goes away.

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.  Another area for inspection are the
cases where TCP header bits are changed and thus the checksum needs to
be adjusted.

===== net/ipv4/netfilter/ip_conntrack_standalone.c 1.22 vs edited =====
--- 1.22/net/ipv4/netfilter/ip_conntrack_standalone.c	Thu Oct  2 23:21:19 2003
+++ edited/net/ipv4/netfilter/ip_conntrack_standalone.c	Fri Dec  5 12:25:22 2003
@@ -201,7 +201,8 @@
 	/* Local packets are never produced too large for their
 	   interface.  We degfragment them at LOCAL_OUT, however,
 	   so we have to refragment them here. */
-	if ((*pskb)->len > dst_pmtu(&rt->u.dst)) {
+	if ((*pskb)->len > dst_pmtu(&rt->u.dst) &&
+	    !skb_shinfo(*pskb)->tso_size) {
 		/* No hook can be after us, so this should be OK. */
 		ip_fragment(*pskb, okfn);
 		return NF_STOLEN;

  parent reply	other threads:[~2003-12-05 20:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-04  6:51 Extremely slow network with e1000 & ip_conntrack Feldman, Scott
2003-12-04 12:36 ` Stephen Lee
2003-12-04 18:24   ` David S. Miller
2003-12-05 20:45     ` Stephen Lee
2003-12-05 20:28   ` David S. Miller [this message]
2003-12-05 22:20     ` Stephen Lee
2003-12-05 22:56       ` David S. Miller
2003-12-11  7:26     ` Harald Welte
2003-12-11  8:25       ` Henrik Nordstrom
2003-12-11 11:03     ` TSO and netfilter (Re: Extremely slow network with e1000 & ip_conntrack) Harald Welte
2003-12-12  1:41       ` David S. Miller
2003-12-12  7:01         ` Harald Welte
2003-12-12  8:00           ` David S. Miller
  -- strict thread matches above, loose matches on Subject: below --
2003-12-04 17:37 Extremely slow network with e1000 & ip_conntrack Feldman, Scott
2003-12-04 18:30 ` David S. Miller
2003-12-04 19:53 ` Stephen Lee
2003-12-04 20:09   ` Jeff Garzik
2003-12-05 13:25     ` Stephen Lee
2003-12-04 20:20   ` David S. Miller
2003-12-04  7:24 Feldman, Scott
     [not found] <20031126174943.0AA5.MUKANSAI@emailplus.org>
     [not found] ` <20031129042551.A460.MUKANSAI@emailplus.org>
     [not found]   ` <20031130074532.0105.MUKANSAI@emailplus.org>
2003-11-30 15:52     ` Harald Welte
2003-12-02 11:44       ` Stephen Lee
2003-12-03  5:03         ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031205122819.25ac14ab.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=laforge@netfilter.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mukansai@emailplus.org \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=scott.feldman@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).