Attachment 153314 Details for Bug 236298 – x

x (text/plain), 6.72 KB, created by IBM Bug Proxy on 2007-04-23 21:07:23 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: IBM Bug Proxy

Created: 2007-04-23 21:07:23 UTC

Size: 6.72 KB

patch

obsolete

>From akpm@linux-foundation.org Tue Apr 17 00:54:59 2007
>Return-Path: <akpm@linux-foundation.org>
>Received: from imap.linux.ibm.com ([unix socket])
>	 by imap.linux.ibm.com (Cyrus v2.3.7-Invoca-RPM-2.3.7-7) with LMTPA;
>	 Tue, 17 Apr 2007 01:54:59 -0400
>X-Sieve: CMU Sieve 2.3
>Received: by imap.linux.ibm.com (Postfix, from userid 101)
>	id 83ACC1910147; Tue, 17 Apr 2007 01:54:59 -0400 (EDT)
>X-Spam-TestScore: NO_REAL_NAME=0.55,SPF_NEUTRAL=1.379
>X-Spam-TokenSummary: Bayes not run.
>X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on imap.linux.ibm.com
>X-Spam-Level: *
>X-Spam-Status: No, score=1.9 required=5.0 tests=NO_REAL_NAME,SPF_NEUTRAL 
>	autolearn=disabled version=3.1.7
>X-Spam-Relay-Country: US ** US US US ** US US US US **
>Received: from smtp.linux.ibm.com (smtp.linux.ibm.com [9.26.4.197])
>	by imap.linux.ibm.com (Postfix) with ESMTP id 35CF61910127
>	for <linas@imap.linux.ibm.com>; Tue, 17 Apr 2007 01:54:55 -0400 (EDT)
>Received: from localhost (localhost.localdomain [127.0.0.1])
>	by smtp.linux.ibm.com (Postfix) with ESMTP id C67BEC03F
>	for <linas@linux.ibm.com>; Tue, 17 Apr 2007 01:54:54 -0400 (EDT)
>X-Virus-Scanned: amavisd-new at linux.ibm.com
>Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176])
>	by smtp.linux.ibm.com (Postfix) with ESMTP id C2F5EC03E
>	for <linas@linux.ibm.com>; Tue, 17 Apr 2007 01:54:52 -0400 (EDT)
>Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226])
>	by austin.ibm.com (8.13.8/8.12.10) with ESMTP id l3H5sqGd038162
>	for <linas@austin.ibm.com>; Tue, 17 Apr 2007 00:54:52 -0500
>Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
>	by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3H5spTE155308
>	for <linas@austin.ibm.com>; Mon, 16 Apr 2007 23:54:51 -0600
>Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
>	by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3H5ske1020377
>	for <linas@austin.ibm.com>; Mon, 16 Apr 2007 23:54:46 -0600
>Received: from d03atspamtest02.boulder.ibm.com (d03atspamtest02 [9.17.195.254])
>	by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3H5sk9e020373
>	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
>	for <linas@austin.ibm.com>; Mon, 16 Apr 2007 23:54:46 -0600
>Received: from e34.co.us.ibm.com ([9.17.249.44])
>	by d03atspamtest02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3H5sTo0001176
>	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
>	for <linas@austin.ibm.com>; Mon, 16 Apr 2007 23:54:29 -0600
>Received: from smtp.osdl.org (smtp.osdl.org [65.172.181.24])
>	by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l3H5sJR5009958
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL)
>	for <linas@austin.ibm.com>; Tue, 17 Apr 2007 01:54:20 -0400
>Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6])
>	by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id l3H5sEIs019477
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
>	Mon, 16 Apr 2007 22:54:15 -0700
>Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31])
>	by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id l3H5sDrg021617;
>	Mon, 16 Apr 2007 22:54:13 -0700
>Message-Id: <200704170554.l3H5sDrg021617@shell0.pdx.osdl.net>
>Subject: [patch 1/1] spidernet: Fix problem sending IP fragments
>To: jeff@garzik.org
>Cc: akpm@linux-foundation.org, linas@austin.ibm.com, n.eicker@fz-juelich.de
>From: akpm@linux-foundation.org
>Date: Mon, 16 Apr 2007 22:54:13 -0700
>X-MIMEDefang-Filter: osdl$Revision: 1.177 $
>X-Scanned-By: MIMEDefang 2.36
>Status: RO
>Content-Length: 3234
>Lines: 70
>
>From: Linas Vepstas <linas@austin.ibm.com>
>
>The basic structure of "normal" UDP/IP/Ethernet
>frames (that actually work):
> - It starts with the Ethernet header (dest MAC, src MAC, etc.)
> - The next part is occupied by the IP header (version info, length of
>packet, id=0, fragment offset=0, checksum, from / to address, etc.)
> - Then comes the UDP header (src / dest port, length, checksum)
> - Actual payload
> - Ethernet checksum
>
>Now what's different for IP fragment:
> - The IP header has id set to some value (same for all fragments),
>offset is set appropriately (i.e. 0 for first fragment, following
>according to size of other fragments), size is the length of the frame.
> - UDP header is unchanged. I.e. length is according to full UDP
>datagram, not just the part within the actual frame! But this is only
>true within the first frame: all following frames don't have a valid
>UDP-header at all.
>
>The spidernet silicon seems to be quite intelligent: It's able to
>compute (IP / UDP / Ethernet) checksums on the fly and tests if frames
>are conforming to RFC -- at least conforming to RFC on complete frames.
>
>But IP fragments are different as explained above:
>I.e. for IP fragments containing part of a UDP datagram it sees
>incompatible length in the headers for IP and UDP in the first frame
>and, thus, skips this frame. But the content *is* correct for IP
>fragments. For all following frames it finds (most probably) no valid
>UDP header at all. But this *is* also correct for IP fragments.
>
>The Linux IP-stack seems to be clever in this point. It expects the
>spidernet to calculate the checksum (since the module claims to be able
>to do so) and marks the skb's for "normal" frames accordingly
>(ip_summed set to CHECKSUM_HW).
>But for the IP fragments it does not expect the driver to be capable to
>handle the frames appropriately. Thus all checksums are allready
>computed. This is also flaged within the skb (ip_summed set to
>CHECKSUM_NONE).
>
>Unfortunately the spidernet driver ignores that hints. It tries to send
>the IP fragments of UDP datagrams as normal UDP/IP frames. Since they
>have different structure the silicon detects them the be not
>"well-formed" and skips them.
>
>The following one-liner against 2.6.21-rc2 changes this behavior. If the
>IP-stack claims to have done the checksumming, the driver should not
>try to checksum (and analyze) the frame but send it as is.
>
>Signed-off-by: Norbert Eicker <n.eicker@fz-juelich.de>
>Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>---
>
> drivers/net/spider_net.c |    2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff -puN drivers/net/spider_net.c~spidernet-fix-problem-sending-ip-fragments drivers/net/spider_net.c
>--- a/drivers/net/spider_net.c~spidernet-fix-problem-sending-ip-fragments
>+++ a/drivers/net/spider_net.c
>@@ -719,7 +719,7 @@ spider_net_prepare_tx_descr(struct spide
> 			SPIDER_NET_DESCR_CARDOWNED | SPIDER_NET_DMAC_NOCS;
> 	spin_unlock_irqrestore(&chain->lock, flags);
> 
>-	if (skb->protocol == htons(ETH_P_IP))
>+	if (skb->protocol == htons(ETH_P_IP) && skb->ip_summed == CHECKSUM_PARTIAL)
> 		switch (skb->nh.iph->protocol) {
> 		case IPPROTO_TCP:
> 			hwdescr->dmac_cmd_status |= SPIDER_NET_DMAC_TCP;
>_
>

Actions: View

Attachments on bug 236298: 152510 | 152660 | 152661 | 152662 | 153314 | 153385 | 153456 | 153747