Messages in this thread | | | Date | Thu, 11 Dec 2003 17:41:36 -0800 | From | "David S. Miller" <> | Subject | Re: TSO and netfilter (Re: Extremely slow network with e1000 & ip_conntrack) |
| |
On Thu, 11 Dec 2003 12:03:15 +0100 Harald Welte <laforge@netfilter.org> wrote:
> 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.
It changes at least tso_segs, since if you decrease of increase the size of the payload the number of real TCP/IP packets the TSO engine will end up spitting out could be different.
The one netfilter module I'm most concerned about is the one that handles non-passive FTP, I remember that one did strange things with the data stream, removed TCP options, and stuff like that.
> 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.
As mentioned above, I thought the netfilter module handling non-passive FTP stripped TCP options.
> 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.
This may be what I was thinking about.
> > 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?
Currently all the TSO supporting drivers set the ip and tcp header checksum values themselves as appropriate, so there are no worries in this area. - 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/
| |