Above we read merely about the theory of networking, about the basic ideas, about communication protocols and standards. Now, let us see, how all of this is being handled by the Linux Kernel 2.6:
- The Linux kernel is only one component of the operating system
- it is very modular and there are many modules
- it does require applications to provide features to end users (these run in userspace)
The main interface between the kernel and userspace is the set of
system calls. There are about
system calls. Network related
system calls include:
writes to socket
- Queue No.1: The application process does a
write()on a socket and all the data is copied from the process space into the send socket buffer
- Queue No.2: The data goes through the TCP/IP stack and the packets are put (Evaluation strategy#Call_by_reference) into the NIC's egress buffer (here works the packet scheduler)
- Queue No.3: After a packet gets dequeued, the transmission procedure of the driver is called, and it is copied into the tx_ring, a ring buffer the driver shares with the NIC
- Queue No.1: The hardware (NIC) puts all incoming network packets into the rx_ring, a ring buffer the driver shares with the NIC
- Queue No.2: The IRQ handler of the driver takes the packet from the rx_ring, puts it (by (Evaluation strategy#Call_by_reference)) in the ingress buffer (aka backlog queue) and schedules a SoftIRQ (in former days, every incoming packet triggered an IRQ, since Kernel this is solved by polling instead)
- Queue No.3: is the the receive socket buffer
- The socket buffers can be set by the application (
- The default queuing discipline is a FIFO queue. Default length is 100 packets (ether_setup(): dev→queue_len, drivers/net/net_init.c)
- The tx_ring and rx_ring are driver dependent (e.g. the e1000 driver set these lengths to 80 packets)
- The backlog queue is 300 packets in size (
/proc/sys/net/core/netdev_max_backlog). Once it is full, it waits for being totally empty to allow again an enqueue() (netif_rx(), net/core/dev.c).
/proc is the POSIX complient mount point for the Virtual Filesystem for the processes.
/proc/cpuinfo: processor information
/proc/meminfo: memory status
/proc/version: kernel version and build information
/proc/cmdline: kernel command line
/proc/<pid>/environ: calling environment
/proc/<pid>/cmdline: process command line
See → http://gettys.wordpress.com/2010/11/29/home-router-puzzle-piece-one-fun-with-your-switch/ for some "fun" with all the queues.
So you can install hardware capable of Ethernet (usually a network card or more precisely an Ethernet card) on two hosts, connect them with a standardized cable, like a Category 5 cable and communicate with one another over Ethernet as far as your software supports Ethernet Sooner or later the sausage will get to the Ethernet thingy of the network stack, this will prepare the data conforming to the Ethernet standard, then will deliver the frames to the network card drivers and this will make the hardware, the network card, transmit the data.
The NIC on the other side will receive the signal, relay it to the Ethernet thingy of the network stack, this will create one huge data out of the Ethernet frames and relay it to the software.
When a packet is enqueued on an interface with
dev queue xmit (in
enqueue operation of the packet scheduler is triggered and
qdisc wakeup is being called (in
net/pkt_sched.h) to send the packet on that device.
A transmit queue is associated with each device. When a network packet is ready for transmission, the "networking code" will call the driver's
hard_start_xmit()-function to let it know, a packet is waiting. The driver will then put that packet into the
transmit queue of the hardware.
You find the sources for the whole TCP/IP protocol suite implementation
doc/networking/praxis.txt · Last modified: 2014/07/31 14:36 by cbytime