AIX Version 4.3 Differences Guide

There is a packet size threshold where it is cheaper to do the checksum
processing completely on the CPU. The driver only offloads checksums for
packets larger than this threshold. This threshold is maintained internally as a
variable or constant.
Currently, AIX checksums transmitted packets before copying them to the
network adapter, and checksum received packets after they have been copied
from the adapter to processor memory. Checksumming packets on the adapter
increases the possibility of undetected corruption during the copy from or to the
processor. This possibility is very small. The NDD provides a way for you to turn
off the checksum offload capability for an adapter in cases where corruption is
believed to be occurring.
7.10.1 Limitations
The feature of checksum offload only applies to TCP on ATM over IP Version 4. It
means:
• This driver does not offload checksum processing for IPv6 TCP connections,
• This driver does not offload checksum processing for UDP datagrams.
• The checksum processing is not allowed when IPSEC is running since IPSEC
may encrypt data, and the checksum for the data should be done before it is
encrypted. Offloading, in this case, will cause the checksum to be calculated
after the data has been encrypted, which is wrong. When IPSEC is running,
the checksum must be calculated before the data is encrypted.
7.10.2 Command Changes
The command ifconfig is changed to handle a new interface option,
checksum_offload. Table 38 lists the new options.
Table 38. Ifconfig New Options for Checksum Offload
checksum_offload
Enables checksum offload if the adapter associated with the
interface supports it. This is the default for adapters that
support checksum offload.
-checksum_offload
Disables checksum offload. This is the default for adapters
that do not support checksum offload.
7.11 Thread-Based Application Connection Enhancement (4.3.2)
The thundering herd problem is a well-known, industry-wide performance
problem that effects some Web servers. When multiple threads call accept()
function on the same socket, all of these threads are woken up for a single new
connection. For example, if there are 256 threads sleeping in accept(), only one
thread needs to be woken up to handle the new connection. However, currently
all 256 threads are woken up. Since only one thread receives the connection, the
other 255 immediately go back to sleep. This results in wasted CPU time due to
the unnecessary scheduling, running, and sleeping of the 255 threads.
The cause for this problem is that the socket layer uses a hash table to keep
chains of threads waiting for events on specific sockets. All threads waiting for an
event on a specific socket will hash to the same slot, but other threads waiting for
events on other sockets could also hash to the same slot. For this reason, all the
threads in the slot must be woken up when the event occurs, so that the right
Networking Enhancements 177