Generic XDP driver was introduced in the 4.12 kernel.
https://kernelnewbies.org/Linux_4.12#head-9f96b5e8262772d5e1908bf335fd25f4c3eec15a
If you run dnf update, it should pull down the 4.12 kernel on Fedora 26.
--Zvi
On Mon, Aug 28, 2017 at 10:39 PM, Y Song <ys114321@xxxxxxxxx> wrote:
> I tried on my FC26 VM. I actually got permission denied.
> I tried to attach the main interface enp0s3 (acting as eth0).
>
> The kernel is 4.11. I think generic xdp support is not there.
> Otherwise people can confirm?
> The VM interface enp0s3 (or eth0) may not have driver support for XDP.
>
> On Mon, Aug 28, 2017 at 3:12 PM, Zvi Effron <zeffron@xxxxxxxxxxxxx> wrote:
>> Full reproduction instructions:
>>
>> 1) Install Fedora 26 server. I chose all of the default options,
>> except I chose to install latest packages from the network. Otherwise,
>> just run a dnf update after install. I installed into a VM running on
>> HyperV
>> 2) Install clang, llvm, and kernel-devel:
>> dnf install -y clang llvm kernel-devel
>> 3) Copy the program to xdp_test_kern.c
>> 4) Compile the program into an elf object file:
>> clang -S -O2 -Wall -Werror -nostdinc -isystem $(clang
>> -print-file-name=include) -I /lib/modules/$(uname
>> -r)/build/arch/x86/include -I /lib/modules/$(uname
>> -r)/build/arch/x86/include/generated/uapi -I /lib/modules/$(uname
>> -r)/build/arch/x86/include/generated -I /lib/modules/$(uname
>> -r)/build/include -I /lib/modules/$(uname
>> -r)/build/arch/x86/include/uapi -I /lib/modules/$(uname
>> -r)/build/include/uapi -I /lib/modules/$(uname
>> -r)/build/include/generated/uapi -include /lib/modules/$(uname
>> -r)/build/include/linux/kconfig.h -D __KERNEL__ -c -emit-llvm -o
>> xdp_test_kern.ll xdp_test_kern.c
>> llc -march bpf -filetype obj -o xdp_test_kern.o xdp_test_kern.ll
>> 5) Attach the program to eth0:
>> ip link set dev eth0 xdp object xdp_test_kern.o section .text verbose
>> 6) Notice only 0s being printed for data in /sys/kernel/debug/tracing/trace_pipe
>>
>> As near as I can tell, the driver being used for eth0 is hv_netvsc, in
>> case it's an issue with the driver.
>>
>> Thanks!
>> --Zvi
>>
>> On Mon, Aug 28, 2017 at 2:16 PM, Y Song <ys114321@xxxxxxxxx> wrote:
>>> bpf program itself is okay.
>>> I replaced linux:samples/bpf/xdp1_kern.c with this program and the
>>> bpf_trace_printk works fine.
>>> It could be some setup issue. But in any case, data start and data end
>>> are suspicious.
>>> It would be good you list all steps which can reproduce the issue.
>>>
>>> On Mon, Aug 28, 2017 at 10:20 AM, Zvi Effron <zeffron@xxxxxxxxxxxxx> wrote:
>>>> Hello,
>>>>
>>>> I'm having an issue where bpf_trace_printk seems to always print 0 for
>>>> values. I'm running the following xdp program:
>>>>
>>>>
>>>> #include <uapi/linux/bpf.h>
>>>>
>>>> static int (*bpf_trace_printk)(const char *fmt, int fmt_size, ...) =
>>>> (void *) BPF_FUNC_trace_printk;
>>>>
>>>> int xdp(struct xdp_md *ctx) {
>>>> char format_string[] = "Data start: %x\tData end: %x\n";
>>>> bpf_trace_printk(format_string, sizeof(format_string), ctx->data,
>>>> ctx->data_end);
>>>>
>>>> {
>>>> char format_string[] = "Constant: %x\n";
>>>> bpf_trace_printk(format_string, sizeof(format_string), 1);
>>>> }
>>>>
>>>> if (ctx->data == 0) {
>>>> char format_string[] = "Data starts at offset 0";
>>>> bpf_trace_printk(format_string, sizeof(format_string));
>>>> }
>>>> if (ctx->data_end == 0) {
>>>> char format_string[] = "Data ends at offset 0";
>>>> bpf_trace_printk(format_string, sizeof(format_string));
>>>> }
>>>> return XDP_PASS;
>>>> }
>>>>
>>>> char __attribute__((section("license"), used)) license[] = "GPL";
>>>>
>>>>
>>>> and I get the following output in /sys/kernel/debug/tracing/trace_pipe
>>>>
>>>>
>>>> sshd-4824 [000] ..s1 67372.673714: : Data start: 0 Data end: 0
>>>> sshd-4824 [000] ..s1 67372.673720: : Constant: 0
>>>> <idle>-0 [000] ..s. 67372.675062: : Data start: 0 Data end: 0
>>>> <idle>-0 [000] .Ns. 67372.675090: : Constant: 0
>>>> <idle>-0 [000] .Ns. 67372.675116: : Data start: 0 Data end: 0
>>>> <idle>-0 [000] .Ns. 67372.675117: : Constant: 0
>>>> <idle>-0 [000] .Ns. 67372.675129: : Data start: 0 Data end: 0
>>>> <idle>-0 [000] .Ns. 67372.675130: : Constant: 0
>>>> <idle>-0 [000] .Ns. 67372.675136: : Data start: 0 Data end: 0
>>>> <idle>-0 [000] .Ns. 67372.675137: : Constant: 0
>>>> <idle>-0 [000] .Ns. 67372.675142: : Data start: 0 Data end: 0
>>>> <idle>-0 [000] .Ns. 67372.675143: : Constant: 0
>>>> ip-6458 [000] ..s. 67372.676083: : Data start: 0 Data end: 0
>>>> ip-6458 [000] ..s. 67372.676084: : Constant: 0
>>>> ip-6458 [000] ..s. 67372.676093: : Data start: 0 Data end: 0
>>>> ip-6458 [000] ..s. 67372.676094: : Constant: 0
>>>>
>>>>
>>>> It looks like ctx->data and ctx->data_end are not 0, because the calls
>>>> to bpf_trace_printk in those ifs aren't being called, and the constant
>>>> is definitely not 0.
>>>>
>>>> What might I be missing or doing incorrectly?
>>>>
>>>> Thank you!
>>>> --Zvi
|