I tried the test with the following:
. fc25 env but booted with latest net-next kernel (my developer env)
. clang/llvm 5.0 (build from source)
. latest iproute2 (build from source)
and it works fine.
I suggest you migrate to the latest (or above) environment and it should work.
Otherwise, you could bisect and debug to see which component may have issues.
On Mon, Aug 28, 2017 at 10:53 PM, Zvi Effron <zeffron@xxxxxxxxxxxxx> wrote:
> 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
|