rte_kni

DPDK版本:19.02

关于kni的接口，rte_kni.h的注释比较详细了，用法参考demo就行
这里分析一下kni接口配置的结构体

创建kni接口的API原型:
struct rte_kni rte_kni_alloc(struct rte_mempool pktmbuf_pool,
const struct rte_kni_conf conf, struct rte_kni_ops ops);

核心结构:

struct rte_kni_conf {
    /*
     * KNI name which will be used in relevant network device.
     * Let the name as short as possible, as it will be part of
     * memzone name.
     */
    char name[RTE_KNI_NAMESIZE];
    uint32_t core_id;   /* Core ID to bind kernel thread on */
    uint16_t group_id;  /* Group ID */
    unsigned mbuf_size; /* mbuf size */
    struct rte_pci_addr addr;
    struct rte_pci_id id;

    __extension__
    uint8_t force_bind : 1; /* Flag to bind kernel thread */
    char mac_addr[ETHER_ADDR_LEN]; /* MAC address assigned to KNI */
    uint16_t mtu;
};

根据rte_kni.c和驱动，详细说明一下这些成员的作用

name

顾名思义,创建的kni接口的名字。驱动内有一个链表维护所有创建的kni接口，通过名字定位

core_id, force_bind

这两个放在一起解释。kni接口创建后，驱动会创建一个内核线程负责io，这个线程可以绑定到指定的core上。
如果force_bind有效，那么驱动会把创建的内核线程绑定到core_id指定的core上。force_bind为0的话，实际上core_id也没什么用

group_id

kni接口在内核会注册为一个netdev设备，自然也继承了netdev的一些公共操作接口，比如ioctl(ndo_do_ioctl)
group_id在ioctl里面会用到，但是当前版本也仅仅是debug打印以下，功能上没有用到。可能后续可以用来组管理kni接口吧。

mbuf_size

内核收发数据时的内存都是从rte_kni_alloc的pktmbuf_pool分配的
发送的时候会判断skb的长度是否超过mbuf_size,超过的话会drop掉
这个内存是从mempool申请的，自然每次发送的长度不能超过mempool每个成员的长度。
所以这个成员值应该不大于rte_kni_alloc里面pktmbuf_pool的buffer_size

addr, id

这些都是pci相关的东西，一般不通过手工指定吧，可以先通过rte_eth_dev_info_get把这些信息取出来

mac_addr

配置接口的mac地址，应该也可以沿用rte_eth_dev_info_get取出来的值吧

mtu

配置接口的mtu值，应该也可以沿用rte_eth_dev_info_get取出来的值吧