dev_alloc_skb() alloc_skb

筆錄收藏 2012-05-08

展開全文

dev_alloc_skb()也是一個緩沖區(qū)分配函數(shù)，它主要被設備驅(qū)動使用，通常用在中斷上下文中。這是一個alloc_skb()的包裝函數(shù)，它會在請求分配的大小上增加16字節(jié)的空間以優(yōu)化緩沖區(qū)的讀寫效率，它的分配要求使用原子操作(GFP_ATOMIC)，這是因為它是在中斷處理函數(shù)中被調(diào)用的。
    dev_alloc_skb(length) uses the function alloc_skb() to create a socket buffer. The length of this socket buffer's packet data space is length + 16 bytes. Subsequently, skb_reserve(skb, 16) is used to move the currently valid packet data space 16 bytes backwards. This means that the packet has now a headroom of 16 bytes and a tailroom of length bytes.

/usr/src/linux-2.6.19/include/linux/skbuff.h
static inline struct sk_buff *dev_alloc_skb(unsigned int length)
{
     return __dev_alloc_skb(length, GFP_ATOMIC);
}

/usr/src/linux-2.6.19/include/linux/skbuff.h
static inline struct sk_buff *__dev_alloc_skb(unsigned int length,
                          gfp_t gfp_mask)
{
    struct sk_buff *skb = alloc_skb(length + NET_SKB_PAD, gfp_mask);
    if (likely(skb))
        skb_reserve(skb, NET_SKB_PAD);
    return skb;
}

/usr/src/linux-2.6.19/include/linux/skbuff.h
#ifndef NET_SKB_PAD
#define NET_SKB_PAD 16
#endif

dev_alloc_skb(pkt_len+2)中的2是什么用途? nuc900_ether738行:skb = dev_alloc_skb(length+2);

dev_alloc_skb(int len) 在分配空間是就把len+16了，作為以太網(wǎng)頭部的空間，為什么在ne2000 和3c501中又+2？
dev_alloc_skb(pkt_len+2);2

wxp95

dev_alloc_skb(pkt_len+2)中的2是什么用途?

在__dev_alloc_skb里是把len+16調(diào)用alloc_skb的，但下面是
            if(likely(skb))
                         skb_reserve(skb,16);
            return skb;
skb->;data指向的是16B后面,那16字節(jié)并不是做以太網(wǎng)頭的，你也可以看看旁邊的
注釋。
    在驅(qū)動里面dev_alloc_skb(pkt_len+2)是分配包的長度+2，
包括了以太網(wǎng)頭，也說明上面那16B不是給以太網(wǎng)頭的,
+2是為了ip頭的對齊，驅(qū)動里面后面有
   skb_reserve(skb,2);        /*Force 16 byte alignment*/
在skbuff.h里有個NET_IP_ALIGN有說明

首先L2的地址一共是14(6+6+2)個BYTE:

L2+L3(IP addr)+L4

按照常理L2地址是在L3后加, 所以在ALLOCSKB的時候要留14個BYTE,為了以后給L2用.
但是計算機一般是4字節(jié)對齊的, 如果留14個BYTE那么IP只能排在15個byte位子, ip頭要經(jīng)常訪問所以這樣效率似乎不好.
于是在預留2個(14+2 = 16) 正好讓IP頭4字節(jié)對齊

詳見:http://bbs./thread-2017407-1-1.html

http://blog.csdn.net/wzws45/article/details/6154005