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...
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Garzik <jgarzik@pobox.com>
To: Linas Vepstas <linas@austin.ibm.com>
Cc: Norbert Eicker <n.eicker@fz-juelich.de>,
Jens Osterkamp <jens@de.ibm.com>,
Kou Ishizaki <kou.ishizaki@toshiba.co.jp>,
linuxppc-dev@ozlabs.org, 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...
next prev parent reply other threads:[~2007-03-09 16:53 UTC|newest]
Thread overview: 23+ 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-08 23:15 ` Linas Vepstas
2007-03-09 16:53 ` Jeff Garzik [this message]
2007-03-09 16:53 ` Jeff Garzik
2007-03-09 23:16 ` Norbert Eicker
2007-03-12 8:28 ` Geert Uytterhoeven
2007-03-12 8:28 ` Geert Uytterhoeven
2007-03-12 9:45 ` Norbert Eicker
2007-03-12 9:45 ` Norbert Eicker
2007-03-12 10:44 ` Geert Uytterhoeven
2007-03-12 10:44 ` Geert Uytterhoeven
2007-03-12 11:21 ` Norbert Eicker
2007-03-12 11:21 ` Norbert Eicker
-- strict thread matches above, loose matches on Subject: below --
2007-02-28 14:21 Norbert Eicker
2007-02-28 14:21 ` Norbert Eicker
2007-03-01 22:52 ` Chris Engel
2007-03-01 22:52 ` Chris Engel
2007-03-01 23:34 ` Linas Vepstas
2007-03-01 23:34 ` Linas Vepstas
2007-03-02 17:39 ` Norbert Eicker
2007-03-02 17:39 ` Norbert Eicker
2007-03-03 8:21 ` Benjamin Herrenschmidt
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.