On 03/13, Ferruh Yigit wrote:
>
>>> <...>
>>>
>>>> +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".
Get your point now, will add the exact kernel info.
>
>>>> +* 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?
Will add the kernel version info.
>
>>> <...>
>>>
>>>> +
>>>> +#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/
>
I'll have a try.
>>> <...>
>>>
>>>> +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?
Sure.
Thanks,
Xiaolong
>
