The Linux network stack is packaged into the softnet_data queue through netif_rx()/NAPI from the network card driver; 2. net_rx_action() is processed and distributed to the protocol layer such as ip_rcv(), supporting eBPF filtering; 3. IP layer verification and routing search, and locally send to the transport layer, otherwise forwarding; 4. TCP/UDP delivers applications according to the socket queue, and rmem_max affects UDP packet collection performance. Understanding this process can accurately locate packet loss and optimize performance, which is a necessary foundation for practical combat.

The Linux kernel networking stack is a powerful, modular, and highly optimized subsystem that handles everything from packet reception and transmission to routing, filtering, and socket operations. Whether you're debugging network performance issues, writing a network driver, or building a high-performance application, understanding how the stack works under the hood is essential.

Here's a practical deep dive—no fluff, just what matters:

1. Where It All Starts: The Network Device Interface (NDIS-like layer in Linux)

When a packet arrives from hardware (like a NIC), the driver calls netif_rx() or uses NAPI (New API) for high-throughput scenarios (eg, napi_schedule() ).

• NAPI reduces interrupt overhead by switching to polling mode when traffic is heavy—critical for avoiding CPU satisfaction.
• Drivers register with the kernel via register_netdev() , and packets flow into the per-CPU softnet_data structure (found in net/core/dev.c ).

Pro tip: Use cat /proc/softirqs | grep NET_RX to see how many packets your CPU is handling via softirqs—uneven distribution may indicate RSS (Receive Side Scaling) isn't configured right.

2. Packet Flow: From Driver to Protocol Handlers

Once in the softnet backlog, packets are processed by net_rx_action() —a softirq handler that:

• Pulls packets from the queue
• Checks for protocol handlers via ptype_base (a hash table of packet types like ETH_P_IP, ETH_P_ARP)
• Calls the right handler, eg, ip_rcv() for IPv4

This is where BPF (Berkeley Packet Filter) programs can hook in—either via classic socket filters or modern eBPF (used by tools like Cilium or tcpdump).

Example: If you run tcpdump , it attaches a BPF filter to the socket, which runs before the packet hits the IP layer—so you can drop packets early and save CPU.

3. IP Layer: Routing, Forwarding, and Local Delivery

Inside ip_rcv() , the kernel:

• Validates the IP header
• Applies netfilter hooks (think iptables): NF_INET_PRE_ROUTING
• Looks up the route using the FIB (Forwarding Information Base)
• If destination is local → passes to transport layer (TCP/UDP)
• If not local and forwarding is on → sends to ip_forward()

Key files:

• net/ipv4/ip_input.c – packet input logic
• net/core/rtnetlink.c – route table management

Watch out: Misconfigured iptables rules or missing routes can silently drop packets here—use tcpdump -i any to see if packets reach the IP layer.

4. Socket Layer: From Transport to User Space

For TCP:

• tcp_v4_rcv() processes the packet
• Checks socket state, updates receive buffer
• Wakes up waiting processes via sk_data_ready() callback

For UDP:

• udp_rcv() delivers to the correct socket via 4-tuple lookup
• Uses per-socket receive queues ( sk_receive_queue )

Performance tip: If your app is slow receiving UDP packets, check netstat -su for “receive buffer errors”—you might need to increase net.core.rmem_max .

Bonus: Tools to Inspect the Stack

• ss -lntp – see listening TCP sockets and their states
• cat /proc/net/softnet_stat – per-CPU packet processing stats (look for dropped packets)
• ethtool -S eth0 – driver-level counters (eg, rx_missed_errors)
• perf record -g -a sleep 10 && perf script – profile kernel functions in the stack

Understanding the Linux networking stack isn't just academic—it's how you debug latency, tune performance, and avoid “why is my service dropping packets?” at 2 AM.
The code is in net/ in the kernel tree—start with dev.c and core/ —it's readable once you know the flow.

Basically, it's a pipeline: driver → softirq → protocol → socket → app.
Mess with one stage, and the whole thing feels it.

The above is the detailed content of A Deep Dive into the Linux Kernel Networking Stack. For more information, please follow other related articles on the PHP Chinese website!