linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Linas Vepstas <linas@austin.ibm.com>
Cc: linuxppc-dev@ozlabs.org, Norbert Eicker <n.eicker@fz-juelich.de>,
	netdev@vger.kernel.org
Subject: Re: [PATCH] spidernet: Fix problem sending IP fragments
Date: Fri, 09 Mar 2007 11:53:23 -0500	[thread overview]
Message-ID: <45F19103.3010100@pobox.com> (raw)
In-Reply-To: <20070308231556.GE30703@austin.ibm.com>

Linas Vepstas wrote:
> Jeff, 
> 
> Please apply. The rather long patch description is from the submitter,
> Norbert Eicker, I don't know if that's alright, or if I should ask to 
> have it trimmed.
> 
> Thanks, 
> --linas
> 
> From: Norbert Eicker <n.eicker@fz-juelich.de>
> 
> I found out that the spidernet-driver is unable to send fragmented IP 
> frames.
> 
> Let me just recall 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>

are you sure it can't send out fragmented IP frames?  what's really 
going on here?

patch was corrupted anyway, and could not be applied...

  reply	other threads:[~2007-03-09 16:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-08 23:15 [PATCH] spidernet: Fix problem sending IP fragments Linas Vepstas
2007-03-09 16:53 ` Jeff Garzik [this message]
2007-03-09 23:16   ` Norbert Eicker
2007-03-12  8:28     ` Geert Uytterhoeven
2007-03-12  9:45       ` Norbert Eicker
2007-03-12 10:44         ` Geert Uytterhoeven
2007-03-12 11:21           ` Norbert Eicker
  -- strict thread matches above, loose matches on Subject: below --
2007-02-28 14:21 Norbert Eicker
2007-03-01 22:52 ` Chris Engel
2007-03-01 23:34   ` Linas Vepstas
2007-03-02 17:39     ` Norbert Eicker
2007-03-03  8:21       ` Benjamin Herrenschmidt

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=45F19103.3010100@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=linas@austin.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=n.eicker@fz-juelich.de \
    --cc=netdev@vger.kernel.org \
    /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).