This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] skb_checksum_setup and NAT

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] skb_checksum_setup and NAT
From: Christophe Saout <christophe@xxxxxxxx>
Date: Fri, 29 Sep 2006 00:08:24 +0200
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 28 Sep 2006 15:52:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C141C66F.1C74%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C141C66F.1C74%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Am Donnerstag, den 28.09.2006, 18:35 +0100 schrieb Keir Fraser:

> The Linux network stack doesn't expect to be able to receive packets that
> have their protocol-checksum field empty. So we have to add extra packet
> flags to signal this situation. It does create something of a mess unless
> all parts of the network stack know what's going on. I heard that the
> networking maintainers were working on a more generic scheme that we should
> be able to make use of. Apart from that, the stack needs to make sure that
> the proto_csum_blank field is cleared whenever it fills in the full
> checksum.

Ok, ip_forward e.g. sets ip_summed to CHECKSUM_NONE, so it indeed
assumes the checksum is correctly set. This should probably just be
changed accordingly to set CHECKSUM_HW when the incoming packet didn't
have a valid checksum set (although the packet was accepted), possibly
by adding a new CHECKSUM_xxx define.

You are probably talking about the work by Patrick McHardy that is being
merged for post-2.6.18: 


It looks promising though it doesn't seem to address this problem in
particular (?).

> For now, if it causes you problems and you just want stuff to work, you can
> run ethtool on your interface in domU: 'ethtool -K eth0 tx off'.

I just ifdef'ed all places where the NAT code changed the checksum. I'm
having a lot of network traffic between DomU's and I'd like to keep CPU
usage down. If someone is interested in the patch, it's attached (just
the FTP NAT part tested though).

Attachment: xen-nat-more-hacking.patch
Description: Text Data

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>