This chapter is from the book
This chapter is from the book
This chapter is from the book
3.3 ifnet Structure
The ifnet structure contains information common to all interfaces. During system initialization, a separate ifnet structure is allocated for each network device. Every ifnet structure has a list of one or more protocol addresses associated with it. Figure 3.5 illustrates the relationship between an interface and its addresses.
)
Figure 3.5. Each ifnet structure has a list of associated ifaddr structures.
The interface in Figure 3.5 is shown with three protocol addresses stored in ifaddr structures. Although some network interfaces, such as SLIP, support only a single protocol, others, such as Ethernet, support multiple protocols and need multiple addresses. For example, a system may use a single Ethernet interface for both Internet and OSI protocols. A type field identifies the contents of each Ethernet frame, and since the Internet and OSI protocols employ different addressing schemes, the Ethernet interface must have an Internet address and an OSI address. All the addresses are connected by a linked list (the arrows on the right of Figure 3.5), and each contains a back pointer to the related ifnet structure (the arrows on the left of Figure 3.5).
It is also possible for a single network interface to support multiple addresses within a single protocol. For example, two Internet addresses may be assigned to a single Ethernet interface in Net/3.
This feature first appeared in Net/2. Having two IP addresses for an interface is useful when renumbering a network. During a transition period, the interface can accept packets addressed to the old and new addresses.
The ifnet structure is large so we describe it in five sections:
-
implementation information,
-
hardware information,
-
interface statistics,
-
function pointers, and
-
the output queue.
Figure 3.6 shows the implementation information contained in the ifnet structure.
)
Figure 3.6. ifnet structure: implementation information.
80-82
if_next joins the ifnet structures for all the interfaces into a linked list. The if_attach function constructs the list during system initialization. if_addrlist points to the list of ifaddr structures for the interface (Figure 3.16). Each ifaddr structure holds addressing information for a protocol that expects to communicate through the interface.
){kind=link}
Common interface information
83-86
if_name is a short string that identifies the interface type, and if_unit identifies multiple instances of the same type. For example, if a system had two SLIP interfaces, both would have an if_name consisting of the 2 bytes "s1" and an if_unit of 0 for the first interface and 1 for the second. if_index uniquely identifies the interface within the kernel and is used by the sysctl system call (Section 19.14) as well as in the routing domain.
Sometimes an interface is not uniquely identified by a protocol address. For example, several SLIP connections can have the same local IP address. In these cases, if_index specifies the interface explicitly.
if_flags specifies the operational state and properties of the interface. A process can examine all the flags but cannot change the flags marked in the "Kernel only" column in Figure 3.7. The flags are accessed with the SIOCGIFFLAGS and SIOCSIFFLAGS commands described in Section 4.4.
)
Figure 3.7. if_flags values.
The IFF_BROADCAST and IFF_POINTOPOINT flags are mutually exclusive.
The macro IFF_CANTCHANGE is a bitwise OR of all the flags in the "Kernel only" column.
The device-specific flags (IFF_LINKx) may or may not be modifiable by a process depending on the device. For example, Figure 3.29 shows how these flags are defined by the SLIP driver.
){kind=link}
Interface timer
87
if_timer is the time in seconds until the kernel calls the if_watchdog function for the interface. This function may be used by the device driver to collect interface statistics at regular intervals or to reset hardware that isn't operating correctly.
BSD Packet Filter
88-89
The next two members, if_pcount and if_bpf, support the BSD Packet Filter (BPF). Through BPF, a process can receive copies of packets transmitted or received by an interface. As we discuss the device drivers, we also describe how packets are passed to BPF. BPF itself is described in Chapter 31.
The next section of the ifnet structure, shown in Figure 3.8, describes the hardware characteristics of the interface.
)
Figure 3.8. ifnet structure: interface characteristics.
Net/3 and this text use the short names provided by the #define statements on lines 138 through 143 to specify the ifnet members.
Interface characteristics
90-92
if_type specifies the hardware address type supported by the interface. Figure 3.9 lists several common values from net/if_types.h.
)
Figure 3.9. if_type: data-link types.
93-94
if_addrlen is the length of the datalink address and if_hdrlen is the length of the header attached to any outgoing packet by the hardware. An Ethernet network, for example, has an address length of 6 bytes and a header length of 14 bytes (Figure 3.8).
){kind=link}
95
if_mtu is the maximum transmission unit of the interface: the size in bytes of the largest unit of data that the interface can transmit in a single output operation. This is an important parameter that controls the size of packets created by the network and transport protocols. For Ethernet, the value is 1500.
96-97
if_metric is usually 0; a higher value makes routes through the interface less favorable. if_baudrate specifies the transmission speed of the interface. It is set only by the SLIP interface.
Interface statistics are collected by the next group of members in the ifnet structure shown in Figure 3.10.
)
Figure 3.10. ifnet structure: interface statistics.
Interface statistics
98-111
Most of these statistics are self-explanatory. if_collisions is incremented when packet transmission is interrupted by another transmission on shared media such as Ethernet. if_noproto counts the number of packets that can't be processed because the protocol is not supported by the system or the interface (e.g., an OSI packet that arrives at a system that supports only IP). The SLIP interface increments if_noproto if a non-IP packet is placed on its output queue.
These statistics were not part of the ifnet structure in Net/1. They were added to support the standard SNMP MIB-II variables for interfaces.
if_iqdrops is accessed only by the SLIP device driver. SLIP and the other network drivers increment if_snd.ifq_drops (Figure 3.13) when IF_DROP is called. ifq_drops was already in the BSD software when the SNMP statistics were added. The ISODE SNMP agent ignores if_iqdrops and uses ifsnd.ifq_drops.
Change timestamp
112-113
if_lastchange records the last time any of the statistics were changed.
Once again, Net/3 and this text use the short names provided by the #define statements on lines 144 through 155 to specify the ifnet members.
The next section of the ifnet structure, shown in Figure 3.11, contains pointers to the standard interface-layer functions, which isolate device-specific details from the network layer. Each network interface implements these functions as appropriate for the particular device.
)
Figure 3.11. ifnet structure: interface procedures.
Interface functions
114-129
Each device driver initializes its own ifnet structure, including the seven function pointers, at system initialization time. Figure 3.12 describes the generic functions.
)
Figure 3.12. ifnet structure: function pointers.
We will see the comment /* XXX */ throughout Net/3. It is a warning to the reader that the code is obscure, contains nonobvious side effects, or is a quick solution to a more difficult problem. In this case, it indicates that if_done is not used in Net/3.
In Chapter 4 we look at the device-specific functions for the Ethernet, SLIP, and loopback interfaces, which the kernel calls indirectly through the pointers in the ifnet structure. For example, if ifp points to an ifnet structure,
(*ifp->if_start)(ifp)
calls the if_start function of the device driver associated with the interface.
The remaining member of the ifnet structure is the output queue for the interface and is shown in Figure 3.13.
)
Figure 3.13. ifnet structure: the output queue.
130-137
if_snd is the queue of outgoing packets for the interface. Each interface has its own ifnet structure and therefore its own output queue. ifq_head points to the first packet on the queue (the next one to be output), ifq_tail points to the last packet on the queue, if_len is the number of packets currently on the queue, and ifq_maxlen is the maximum number of buffers allowed on the queue. This maximum is set to 50 (from the global integer ifqmaxlen, which is initialized at compile time from IFQ_MAXLEN) unless the driver changes it. The queue is implemented as a linked list of mbuf chains. ifq_drops counts the number of packets discarded because the queue was full. Figure 3.14 lists the macros and functions that access a queue.
)
Figure 3.14. ifqueue routines.
The first five routines are macros defined in net/if.h and the last routine, if_qflush, is a function defined in net/if.c. The macros often appear in sequences such as:
s = splimp();
if (IF_QFULL(inq)) {
IF_DROP(inq); /* queue is full, drop new packet */
m_freem(m);
} else
IF_ENQUEUE(inq, m); /* there is room, add to end of queue */
splx(s);
This code fragment attempts to add a packet to the queue. If the queue is full, IF_DROP increments ifq_drops and the packet is discarded. Reliable protocols such as TCP will retransmit discarded packets. Applications using an unreliable protocol such as UDP must detect and handle the retransmission on their own.
Access to the queue is bracketed by splimp and splx to block network interrupts and to prevent the network interrupt service routines from accessing the queue while it is in an indeterminate state.
m_freem is called before splx because the mbuf code has a critical section that runs at splimp. It would be wasted effort to call splx before m_freem only to enter another critical section during m_freem (Section 2.5).