All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Leech <christopher.leech@intel.com>
To: netdev@oss.sgi.com, linux-kernel <linux-kernel@vger.kernel.org>
Subject: skb_padto and small fragmented transmits
Date: 05 Feb 2003 13:39:51 -0800	[thread overview]
Message-ID: <1044481190.9268.43.camel@localhost.localdomain> (raw)

While looking at the new software padding routines, something caught my
eye in skb_padto.  It seemed that the fragmented portion of a packet
would actually be counted twice when checking to see if padding is
needed, as skb->len already includes the count of skb->data_len.

> unsigned int size = skb->len + skb->data_len;

I tested this by modifying e1000 to use skb_padto, disabling TCP
timestamps, and writing a small app to transmit 4 bytes using sendfile. 
The resulting packet had 54 bytes of headers, and 4 bytes of data in a
separate fragment.  Calling skb_padto(skb,60) should have linearized the
skb, and zeroed out the first 2 bytes of tailroom.  Instead the length
was incorrectly calculated as 62 bytes, and the buffer was returned as
is.

Changing skb_padto to simply use size = skb->len fixed the padding, but
then I started seeing incorrect TCP checksums going out.  I found this
comment in skb_copy_expand that seemed to explain things.

> BUG ALERT: ip_summed is not copied. Why does this work? Is it used
> only by netfilter in the cases when checksum is recalculated? --ANK

So after calling skb_copy_expand the checksum is not recalculated in
software, but the checksum offload information is discarded.

-- 
Chris Leech <christopher.leech@intel.com>


             reply	other threads:[~2003-02-05 21:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-05 21:39 Chris Leech [this message]
2003-02-06 11:58 ` skb_padto and small fragmented transmits David S. Miller
     [not found] <BD9B60A108C4D511AAA10002A50708F20BA2AAE3@orsmsx118.jf.intel.com>
2003-02-06 19:22 ` Chris Leech
2003-02-06 22:43   ` David S. Miller
2003-02-07 13:33     ` Alan Cox
2003-02-08  8:53       ` David S. Miller
     [not found] <BD9B60A108C4D511AAA10002A50708F20BA2AAD1@orsmsx118.jf.intel.com>
2003-02-06 19:22 ` Chris Leech
2003-02-06 18:44   ` David S. Miller

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=1044481190.9268.43.camel@localhost.localdomain \
    --to=christopher.leech@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    /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.