From: Patrick McHardy <kaber@trash.net>
To: Alexander Sirotkin <demiourgos@gmail.com>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: TCP/UDP checksum in hardware
Date: Mon, 05 Mar 2007 19:06:55 +0100 [thread overview]
Message-ID: <45EC5C3F.6060401@trash.net> (raw)
In-Reply-To: <c4357ccd0703050149p508d3b2ej80cbdeaccbdbd3b5@mail.gmail.com>
Alexander Sirotkin wrote:
> On 3/4/07, Patrick McHardy <kaber@trash.net> wrote:
>
>> Alexander Sirotkin wrote:
>> > The reason I'm asking is that computing checksum (in case of NAT, for
>> > instance) becomes a real problem on embedded devices
>>
>> Do you have any data to show this?
>>
> I don't know how relevant this is for netfilter, but yes - if the
> device does not support checksum offloading my benchmark which I ran
> on 266Mhz MIPS 24K (which is a pretty common processor for residential
> gateways) showed that under 80Mbps UDP traffic, with NAT enabled,
> checksum check takes about 15% CPU.
The first question would be whether this is really checksumming
done by netfilter or by the UDP code. Since enabling checksum
offloading seems to help, this points to the UDP code. In case
it is netfilter, the second question would be whether its
checksum verification or updates.
> BTW, while we are on the subject, the overhead of netfilter itself,
> i.e. the difference in CPU utilization of kernel with and without
> netfilter on the above platform is more than 5%. Is there anybody hear
> willing to discuss this ?
Is this with netfilter modules (like iptables, conntrack, NAT, ...)
loaded or just by enabling netfilter in the configuration?
BTW, which kernel version are you talking about?
next prev parent reply other threads:[~2007-03-05 18:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-04 15:26 TCP/UDP checksum in hardware Alexander Sirotkin
2007-03-04 17:16 ` Patrick McHardy
2007-03-05 9:49 ` Alexander Sirotkin
2007-03-05 18:06 ` Patrick McHardy [this message]
2007-03-08 10:15 ` Alexander Sirotkin
2007-03-16 12:35 ` Patrick McHardy
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=45EC5C3F.6060401@trash.net \
--to=kaber@trash.net \
--cc=demiourgos@gmail.com \
--cc=netfilter-devel@lists.netfilter.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.