Deactivating TCP checksumming

[shesha bhushan]

Hello all,
I am trying to de-activate the TCP checksumming and allow hardware (GBE to
compute it for me). But can any one let me know how to do it.

This is what I did.But Its not working for me.

In linux/net/ipv4/tcp.c there are function calls to
csum_and_copy_from_user(). I replaced it from copy_from_user() and set the
skb->ip_summed = CHECKSUM_HW and skb->csum = 1;. Is this correct. Since its
not working there must be something more that has to be done. could any one
please tell me what additional thinks I need to do.

All suggestion are highly apperciated.

Thanking You
Shesha




_________________________________________________________________
Say it now. Say it online. http://www.msn.co.in/ecards/ Send e-cards to your
love

[Matti Aarnio]

Post by shesha bhushan
Hello all,
I am trying to de-activate the TCP checksumming and allow hardware (GBE to
compute it for me). But can any one let me know how to do it.

GBE ? Likely device feature flags are wrong -- See examples
from drivers/net/sunhme.c, acenic.c, tg3.c for various ways
to use NETIF_F_*_CSUM feature flags.

For (some of) explanations: include/linux/netdevice.h
(for NETIF_F_* flags)

Post by shesha bhushan
All suggestion are highly apperciated.
Thanking You
Shesha

/Matti Aarnio

[shesha bhushan]

I get that. I can talk with the driver vendor. But to gain the usefulness of
caculation of CSUM in HW we need to disable the software CSUM calculation in
TCP layer in the kernel. Am I correct? I am trying to find that and I ma
stuck there. How to disble the software TCP CSUM calculation? and later I
can talk with driver vendor to enable it in hardware. I wanted help from
linux gurus in disabling TCP csum calculation in the kernel.

Thanking You
Shesha

Subject: Re: Deactivating TCP checksumming
Date: Tue, 1 Apr 2003 15:00:08 +0300

Ok I will. Is there any other material which I can reffer?
I am using Intel pro1000 GBE
Thank you very much for providing me the below information.

You will need to talk with the driver author then.
In 2.4.20 kernels (at least RedHat version) there is directory
drivers/net/e1000/
in which the driver code resides.
if(adapter->hw.mac_type >= e1000_82543) {
netdev->features = NETIF_F_SG |
NETIF_F_HW_CSUM |
NETIF_F_HW_VLAN_TX |
NETIF_F_HW_VLAN_RX |
NETIF_F_HW_VLAN_FILTER;
} else {
netdev->features = NETIF_F_SG;
}
... so, if your card isn't with that chip, then perhaps that is
the reason for not doing checksums in HW ?
Existence of that kind of test is telling to me, that "E1000" name
is used to refer to a series of cards with varying properties.
(Like there are a whole family of cards driven by 3c59x driver,
and even larger one referred as "tulip".)
/Matti Aarnio

Subject: Re: Deactivating TCP checksumming
Date: Tue, 1 Apr 2003 13:58:21 +0300

Post by shesha bhushan
Hello all,
I am trying to de-activate the TCP checksumming and allow hardware

(GBE

to

Post by shesha bhushan
compute it for me). But can any one let me know how to do it.

GBE ? Likely device feature flags are wrong -- See examples
from drivers/net/sunhme.c, acenic.c, tg3.c for various ways
to use NETIF_F_*_CSUM feature flags.
For (some of) explanations: include/linux/netdevice.h
(for NETIF_F_* flags)

Post by shesha bhushan
All suggestion are highly apperciated.
Thanking You
Shesha

/Matti Aarnio

_________________________________________________________________

[Matti Aarnio]

Post by shesha bhushan
I get that. I can talk with the driver vendor. But to gain the usefulness
of caculation of CSUM in HW we need to disable the software CSUM
calculation in TCP layer in the kernel. Am I correct? I am trying to find
that and I ma stuck there. How to disble the software TCP CSUM calculation?
and later I can talk with driver vendor to enable it in hardware. I wanted
help from linux gurus in disabling TCP csum calculation in the kernel.

The kernel code is already smart enough of detect that the outbound
device will handle the checksum calculations all by itself, and not
do it in that case.

Testing of dev->features is done in files:
net/core/dev.c
net/ipv4/tcp.c
(depending what protocol is in question.)
in the latter case, actually in common tcp path with route-cached
route_caps flags.

I did
egrep 'NETIF_F_.._CSUM' net/*/*.c
to find those.
(and a number of other subset searches finding nothing)

Grep is your friend.

This whole "zero-copy" infastructure was implemented during
development in 2.3 series.

Post by shesha bhushan
Thanking You
Shesha

/Matti Aarnio

[Dennis Cook]

Using RH Linux kernel 2.4.18, setting "features" bit NETIF_F_IP_CSUM does
not appear
to keep a valid IP checksum from being computed in packets presented to my
driver
for transmission. So having HW compute outgoing checksum buys nothing.
Checked this
by suppressing HW checksum computation. Packets are still accepted by peer.

Dennis Cook
Sandgate Technologies

Post by Matti Aarnio

Post by shesha bhushan
I get that. I can talk with the driver vendor. But to gain the usefulness
of caculation of CSUM in HW we need to disable the software CSUM
calculation in TCP layer in the kernel. Am I correct? I am trying to find
that and I ma stuck there. How to disble the software TCP CSUM calculation?
and later I can talk with driver vendor to enable it in hardware. I wanted
help from linux gurus in disabling TCP csum calculation in the kernel.

The kernel code is already smart enough of detect that the outbound
device will handle the checksum calculations all by itself, and not
do it in that case.
net/core/dev.c
net/ipv4/tcp.c
(depending what protocol is in question.)
in the latter case, actually in common tcp path with route-cached
route_caps flags.
I did
egrep 'NETIF_F_.._CSUM' net/*/*.c
to find those.
(and a number of other subset searches finding nothing)
Grep is your friend.
This whole "zero-copy" infastructure was implemented during
development in 2.3 series.

Post by shesha bhushan
Thanking You
Shesha

/Matti Aarnio

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/

[Jeff Garzik]

Post by Dennis Cook
Using RH Linux kernel 2.4.18, setting "features" bit NETIF_F_IP_CSUM does
not appear
to keep a valid IP checksum from being computed in packets presented to my
driver
for transmission. So having HW compute outgoing checksum buys nothing.

You are not using sendfile(2), which is required to activate h/w csum.

Jeff

[Dennis Cook]

What I was looking for is a general capability to keep the SW transport
stack from
computing outgoing TCP/UDP/IP checksums so that the HW can be allowed to do
it,
similar to Windows checksum offload capability.

Post by Jeff Garzik

Post by Dennis Cook
Using RH Linux kernel 2.4.18, setting "features" bit NETIF_F_IP_CSUM does
not appear
to keep a valid IP checksum from being computed in packets presented to my
driver
for transmission. So having HW compute outgoing checksum buys nothing.

You are not using sendfile(2), which is required to activate h/w csum.
Jeff

[Jeff Garzik]

Post by Dennis Cook
What I was looking for is a general capability to keep the SW transport
stack from
computing outgoing TCP/UDP/IP checksums so that the HW can be allowed to do
it,
similar to Windows checksum offload capability.

If you are not using sendfile(2), it is _more expensive_ to offload
checksums, because we already checksum and copy at the same time.

Hardware checksum offload is only a win when a copy is eliminated.

Therefore, _always_ offloading checksum is actually slower in some
cases, because of the unneeded additional HW csum setup that would be
performed.

Jeff

[Dennis Cook]

Based on various feedback, on my RH Linux 2.4.18 kernel I tried the
following:

Set "features" bit NETIF_F_IP_CSUM set (the only feature bit set).
In my network driver start-transmit check for "CHECKSUM_HW" in ip_summed.
Using a small test program, use "sendfile" to copy a file to a network
socket FD.
Result is none of the packets presented to my network adapter driver have
ip_summed set to CHECKSUM_HW, so the SW IP stack has already
computed checksums.

Is this mechanism possibly broken on kernel 2.4?

Post by Jeff Garzik

Post by Dennis Cook
What I was looking for is a general capability to keep the SW transport
stack from
computing outgoing TCP/UDP/IP checksums so that the HW can be allowed to do
it,
similar to Windows checksum offload capability.

If you are not using sendfile(2), it is _more expensive_ to offload
checksums, because we already checksum and copy at the same time.
Hardware checksum offload is only a win when a copy is eliminated.
Therefore, _always_ offloading checksum is actually slower in some
cases, because of the unneeded additional HW csum setup that would be
performed.
Jeff

[Jeff Garzik]

Post by Dennis Cook
Based on various feedback, on my RH Linux 2.4.18 kernel I tried the
Set "features" bit NETIF_F_IP_CSUM set (the only feature bit set).
In my network driver start-transmit check for "CHECKSUM_HW" in ip_summed.
Using a small test program, use "sendfile" to copy a file to a network
socket FD.
Result is none of the packets presented to my network adapter driver have
ip_summed set to CHECKSUM_HW, so the SW IP stack has already
computed checksums.

CHECKSUM_HW is for receive, not transmit. Read the comments at the top
of include/linux/skbuff.h.

Post by Dennis Cook
Is this mechanism possibly broken on kernel 2.4?

it works quite well.

Jeff

[Dennis Cook]

In the 3c59x.c, e1000, and other adapter drivers, ip_summed is
what is being checked for value CHECKSUM_HW when sending
a packet.

-----Original Message-----
Sent: Thursday, April 03, 2003 03:47 PM
To: Dennis Cook
Subject: Re: Deactivating TCP checksumming

Post by Dennis Cook
Based on various feedback, on my RH Linux 2.4.18 kernel I tried the
Set "features" bit NETIF_F_IP_CSUM set (the only feature bit set).
In my network driver start-transmit check for "CHECKSUM_HW" in

ip_summed.

Post by Dennis Cook
Using a small test program, use "sendfile" to copy a file to a network
socket FD.
Result is none of the packets presented to my network adapter

driver have

Post by Dennis Cook
ip_summed set to CHECKSUM_HW, so the SW IP stack has already
computed checksums.

CHECKSUM_HW is for receive, not transmit. Read the comments at the top
of include/linux/skbuff.h.

Post by Dennis Cook
Is this mechanism possibly broken on kernel 2.4?

it works quite well.
Jeff

[Jeff Garzik]

Post by Dennis Cook
In the 3c59x.c, e1000, and other adapter drivers, ip_summed is
what is being checked for value CHECKSUM_HW when sending
a packet.

Yep; my mistake on that one.

Regardless, Ion and Manish picked up on what you were missed - the
NETIF_F_SG bit. And if your hardware can do 64-bit DMA, you'll want to
set NETIF_F_HIGHDMA too.

Jeff



--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/

[Abhishek Agrawal]

Post by Jeff Garzik
CHECKSUM_HW is for receive, not transmit. Read the comments at the top
of include/linux/skbuff.h.

Actually CHECKSUM_HW can be set at either of the "producer" ends. At
least this is what I gather from tcp_output.c

// tcp_output.c:454
if (!skb_shinfo(skb)->nr_frags && skb->ip_summed != CHECKSUM_HW) {
//...
}
else {
skb->ip_summed = CHECKSUM_HW;
skb_split(skb, buff, len);
}

AND

//1014 dev.c:dev_queue_xmit()
/* If packet is not checksummed and device does not support
* checksumming for this protocol, complete checksumming here.
*/
if (skb->ip_summed == CHECKSUM_HW &&
(!(dev->features&(NETIF_F_HW_CSUM|NETIF_F_NO_CSUM)) &&
(!(dev->features&NETIF_F_IP_CSUM) ||
skb->protocol != htons(ETH_P_IP)))) {
if ((skb = skb_checksum_help(skb)) == NULL)
return -ENOMEM;
}

[Ion Badulescu]

Post by Dennis Cook
Based on various feedback, on my RH Linux 2.4.18 kernel I tried the
Set "features" bit NETIF_F_IP_CSUM set (the only feature bit set).
In my network driver start-transmit check for "CHECKSUM_HW" in ip_summed.
Using a small test program, use "sendfile" to copy a file to a network
socket FD.
Result is none of the packets presented to my network adapter driver have
ip_summed set to CHECKSUM_HW, so the SW IP stack has already
computed checksums.
Is this mechanism possibly broken on kernel 2.4?

No, but you also need the scatter-gather bit to be set. Otherwise the
network needs to perform at least one copy to linearize the skb, thus it
will take the opportunity to checksum it at the same time so the
hardware capability of the board is not used.

Ion

[Richard B. Johnson]

Post by Dennis Cook
What I was looking for is a general capability to keep the SW transport
stack from
computing outgoing TCP/UDP/IP checksums so that the HW can be allowed to do
it,
similar to Windows checksum offload capability.

REALLY? Who are you kidding. Windows has no such capability.

Check \WINDOWS\SYSTEM32\DRIVERS\ETC\* and see who they stole
the TCP/IP stack from!

Further, when you perform normal user->TCP/IP operations, you
get checksumming for free as part of the copy operation. It's
only when you don't even copy data that you can get any advantage
of not checksumming. That's why sendfile disables it.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

[Dennis Cook]

Re: Windows support of checksum offloading (not kidding).

=46ollowing from Windows DDK

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

To achieve a significant performance boost, the Microsoft TCP/IP transp=
ort
can offload one or more of the following tasks to a NIC that has the
appropriate task-offload capabilities:

a.. Checksum tasks
The TCP/IP transport can offload the calculation and/or validation of=
IP
and/or TCP checksums. The initial release of Windows=AE 2000 does not s=
upport
UDP checksum offloads; however, future service packs and update release=
s of
Windows 2000 and later versions may support UDP checksum offloads.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Win2K SP3 and WinXP both indicate to my driver that TCP and IP checksum=
s are
being offloaded
on packets to be sent provided the driver advertises that the associate=
d HW
is capable of computing
the checksums. I haven't established that the SW transport stack actual=
ly
skips computing the checksums.

Post by Richard B. Johnson

What I was looking for is a general capability to keep the SW trans=

port

Post by Richard B. Johnson

stack from
computing outgoing TCP/UDP/IP checksums so that the HW can be allow=

ed to
do

Post by Richard B. Johnson

it,
similar to Windows checksum offload capability.

REALLY? Who are you kidding. Windows has no such capability.
Check \WINDOWS\SYSTEM32\DRIVERS\ETC\* and see who they stole
the TCP/IP stack from!
Further, when you perform normal user->TCP/IP operations, you
get checksumming for free as part of the copy operation. It's
only when you don't even copy data that you can get any advantage
of not checksumming. That's why sendfile disables it.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about=

it.