[dpdk-dev] [PATCH v1 1/6] net/af_xdp: introduce AF_XDP PMD driver

Ferruh Yigit ferruh.yigit at intel.com
Wed Mar 13 11:54:10 CET 2019


>> <...>
>>
>>> +Prerequisites
>>> +-------------
>>> +
>>> +This is a Linux-specific PMD, thus the following prerequisites apply:
>>> +
>>> +*  A Linux Kernel with XDP sockets configuration enabled;
>>
>> Can you please give more details of what exact vanilla kernel version?
> 
> Do you mean I should write more details about AF_XDP in kernel in this introduction 
> document?

I think it is good to document the exact version information instead of saying
"Linux Kernel with af_xdp".

>>> +*  libbpf with latest af_xdp support installed
>>
>> Is there a specific version of libbpf for this?
> 
> I'm not aware that there is specific version number for libbpf, it's part of linux
> kernel src code.

If it is coming with Linux kernel, which version of Linux kernel?

>> <...>
>>
>>> +
>>> +#include <linux/if_ether.h>
>>> +#include <linux/if_xdp.h>
>>> +#include <linux/if_link.h>
>>> +#include <asm/barrier.h>
>>
>> Getting an build error for this [1], can there be any include path param missing?
>>
>> [1]
>> drivers/net/af_xdp/rte_eth_af_xdp.c:15:10: fatal error: asm/barrier.h: No such
>> file or directory
> 
> Yes, it need something like 
> 
> CFLAGS += -I/root/yexl/shared_mks0/linux/tools/include
> 
> as in above Makefile currently.

I see, assuming you will be booting up with that kernel, can something like
below work:

CFLAGS += -I/lib/modules/$(shell uname -r)/build/tools/include/

>> <...>
>>
>>> +static void
>>> +eth_dev_info(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>>> +{
>>> +	struct pmd_internals *internals = dev->data->dev_private;
>>> +
>>> +	dev_info->if_index = internals->if_index;
>>> +	dev_info->max_mac_addrs = 1;
>>> +	dev_info->max_rx_pktlen = (uint32_t)ETH_FRAME_LEN;
>>> +	dev_info->max_rx_queues = 1;
>>> +	dev_info->max_tx_queues = 1;
>>
>> 'ETH_AF_XDP_MAX_QUEUE_PAIRS' is '16' but you are forcing the max Rx/Tx queue
>> number to be '1', intentional?
> 
> Yes, current implementation is single queue only, we plan to support muli-queues
> in futher.

OK, Can you please document this information?



More information about the dev mailing list