public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: taka@valinux.co.jp
Cc: kuznet@ms2.inr.ac.ru, scott.feldman@intel.com,
	linux-kernel@vger.kernel.org, linux-net@vger.kernel.org,
	haveblue@us.ibm.com, Manand@us.ibm.com,
	christopher.leech@intel.com
Subject: Re: TCP Segmentation Offloading (TSO)
Date: Tue, 03 Sep 2002 00:51:19 -0700 (PDT)	[thread overview]
Message-ID: <20020903.005119.50342945.davem@redhat.com> (raw)
In-Reply-To: <20020903.164243.21934772.taka@valinux.co.jp>

   From: Hirokazu Takahashi <taka@valinux.co.jp>
   Date: Tue, 03 Sep 2002 16:42:43 +0900 (JST)

   I guess it may also depend on bad implementations of csum_partial().
   It's wrong that some architecture assume every data in a skbuff are
   aligned on a 2byte boundary so that it would access a byte next to
   the the last byte where no pages might be there.
   
It is real requirement, x86 works because unaligned
access is handled transparently by cpu.

But on every non-x86 csum_partial I have examined, worse than
2-byte aligned data start is totally not handled.  It is not difficult
to figure out why this is the case, everyone has copied by example. :-)

So we must make a decision, either make every csum_partial
implementation eat 1 byte alignment or enforce 2-byte
alignment at call sites.

I think for 2.4.x it is unreasonable to force everyone to change their
csum_partial, especially since handling byte aligned buffer requires
holding onto state across the whole checksum from beginning to the
last fold.  Many RISC implementation are using registers to the max
and may not easily be able to obtain a temporary.

I dealt with a bug in this area recently, pppoe can cause ppp_input to
send byte aligned data in packets to TCP input, this crashes just
about every non-x86 system so my "fix" was to copy byte aligned SKBs
in ppp_input.

  reply	other threads:[~2002-09-03  7:53 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-02 17:45 TCP Segmentation Offloading (TSO) Feldman, Scott
2002-09-02 18:58 ` kuznet
2002-09-03  7:42   ` Hirokazu Takahashi
2002-09-03  7:51     ` David S. Miller [this message]
2002-09-03 11:27       ` Paul Mackerras
2002-09-03 11:29         ` David S. Miller
2002-09-03 12:21     ` kuznet
2002-09-03 13:03       ` Hirokazu Takahashi
2002-09-03 13:19         ` Hirokazu Takahashi
2002-09-03 13:22         ` kuznet
2002-09-03 21:05           ` David S. Miller
2002-09-03 21:20             ` David S. Miller
2002-09-04  1:02     ` H. Peter Anvin
2002-09-04  1:54       ` David S. Miller
2002-09-04 22:39       ` Gabriel Paubert
2002-09-04 22:41         ` H. Peter Anvin
2002-09-05  2:13           ` Hirokazu Takahashi
2002-09-05  2:21             ` David S. Miller
2002-09-05 10:28             ` Gabriel Paubert
2002-09-05 11:17               ` Jamie Lokier
2002-09-05 13:21                 ` Gabriel Paubert
2002-09-05 13:17                   ` David S. Miller
2002-09-08  4:20                   ` Hirokazu Takahashi
2002-09-08  4:29                     ` H. Peter Anvin
2002-09-04 23:17         ` Alan Cox
2002-09-05  0:09           ` Jamie Lokier
2002-09-02 19:06 ` Jeff Garzik
2002-09-02 23:13 ` David S. Miller
2002-09-03  4:58 ` Jordi Ros
2002-09-03  6:52   ` David S. Miller
2002-09-03  7:26     ` Jordi Ros
2002-09-03  7:39       ` David S. Miller
     [not found] <288F9BF66CD9D5118DF400508B68C4460283E564@orsmsx113.jf.intel.com.suse.lists.linux.kernel>
     [not found] ` <200209021858.WAA00388@sex.inr.ac.ru.suse.lists.linux.kernel>
     [not found]   ` <20020903.164243.21934772.taka@valinux.co.jp.suse.lists.linux.kernel>
     [not found]     ` <20020903.005119.50342945.davem@redhat.com.suse.lists.linux.kernel>
2002-09-03  9:05       ` Andi Kleen
2002-09-03 10:00         ` David S. Miller
2002-09-03 10:10           ` Andi Kleen
2002-09-03 10:09             ` David S. Miller
  -- strict thread matches above, loose matches on Subject: below --
2002-09-03 17:50 Feldman, Scott
2002-09-03 18:09 Manfred Spraul
2002-09-03 23:08 ` Hirokazu Takahashi

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=20020903.005119.50342945.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=Manand@us.ibm.com \
    --cc=christopher.leech@intel.com \
    --cc=haveblue@us.ibm.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-net@vger.kernel.org \
    --cc=scott.feldman@intel.com \
    --cc=taka@valinux.co.jp \
    /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