All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	zdzichu@irc.pl, netdev@vger.kernel.org
Subject: Re: BUGs in skb_checksum_help() and skb_gso_segment() in 2.6.18-rc2
Date: Wed, 26 Jul 2006 06:01:40 +0200	[thread overview]
Message-ID: <44C6E924.2010902@trash.net> (raw)
In-Reply-To: <20060726034650.GA3393@gondor.apana.org.au>

Herbert Xu wrote:
> Hi Patrick:
> 
> On Wed, Jul 26, 2006 at 05:38:07AM +0200, Patrick McHardy wrote:
> 
>>I have a patch which changes netfilter to do incremental checksumming.
>>The hook number is passed to all functions doing this so they know
>>how to update the checksum. Could you explain how
>>CHECKSUM_COMPLETE/CHECKSUM_PARTIAL are going to be used? I assume
>>they're meant to avoid passing hook numbers around everywhere?
> 
> 
> Yes the hook number is another way to solve the same problem.  However,
> it can only be used within netfilter.  CHECKSUM_COMPLETE/CHECKSUM_PARTIAL
> on the other hand are valid throughout the stack.  With Xen feeding Linux
> packets into the stack the netfilter hook is also no longer sufficient to
> distinguish between these two cases as partial checksum packets can now
> appear on receive.
> 
> The problem is that you need to do different incremental updates depending
> on whether the checksum is complete (i.e., CHECKSUM_HW on receive), or
> partial (i.e., CHECKSUM_HW on transmit).
> 
> With complete checksums the current update code in netfilter can be used
> as is.  With partial checksums you need to exclude bits which weren't
> used when computing the partial checksums (e.g., TCP port numbers need
> to be excluded, but the IP address needs to be included for NAT).

That does sound better than the hook number approach.

> I have a patch that adds CHECKSUM_COMPLETE/CHECKSUM_PARTIAL if you want
> something to work from.  Let me know if you want this and I'll bounce it
> to you.

Please send it, I'll update my patch based on that. Thanks.


  reply	other threads:[~2006-07-26  4:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-25 15:15 BUGs in skb_checksum_help() and skb_gso_segment() in 2.6.18-rc2 Tomasz Torcz
2006-07-25 15:29 ` Evgeniy Polyakov
2006-07-26  2:32   ` Herbert Xu
2006-07-26  3:38     ` Patrick McHardy
2006-07-26  3:46       ` Herbert Xu
2006-07-26  4:01         ` Patrick McHardy [this message]
2006-07-26  4:35           ` Herbert Xu

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=44C6E924.2010902@trash.net \
    --to=kaber@trash.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=johnpol@2ka.mipt.ru \
    --cc=netdev@vger.kernel.org \
    --cc=zdzichu@irc.pl \
    /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.