I have a question about skb allocation along the Rx path. If I understand, skb's are allocated by the softirq's running in interrupt context or by ksoftirqd before they are passed up the networking stack via netif_receive_skb. Can someone explain the underlying mechanism of how the kernel ensures this allocation does not block (given softirq processing is non-preemptible) ?
Can someone explain the underlying mechanism of how the kernel ensures this allocation does not block ... ?
Refer to the description of __alloc_skb() in net/core/skbuff.c :
/**
* __alloc_skb - allocate a network buffer
* @size: size to allocate
* @gfp_mask: allocation mask
* @flags: If SKB_ALLOC_FCLONE is set, allocate from fclone cache
* instead of head cache and allocate a cloned (child) skb.
* If SKB_ALLOC_RX is set, __GFP_MEMALLOC will be used for
* allocations in case the data is required for writeback
* @node: numa node to allocate memory on
*
* Allocate a new &sk_buff. The returned buffer has no headroom and a
* tail room of at least size bytes. The object has a reference count
* of one. The return is the buffer. On a failure the return is %NULL.
*
* Buffers may only be allocated from interrupts using a @gfp_mask of
* %GFP_ATOMIC.
*/
The GFP_ATOMIC flag is passed to the memory allocator to prevent sleeping/blocking.
"GFP" stands for "Get Free Pages".
This flag is described in a Linux Journal article as:
The GFP_ATOMIC flag instructs the memory allocator never to block. Use this flag in situations where it cannot sleep—where it must remain atomic—such as interrupt handlers, bottom halves and process context code that is holding a lock.
Also see the SO post How does GFP_ATOMIC prevent sleep.
Study how callers of netdev_alloc_skb() in the Linux kernel handle a NULL return code, meaning no free memory was available for a new skbuff. The typical Ethernet MAC driver increments an rx_dropped statistics counter and discards the received frame.