Re: [External] [PATCH bpf-next v2 3/3] selftests/bpf: add ipv6 vxlan tunnel source testcase

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Martin KaFai Lau <kafai@xxxxxx> 于2022年4月8日周五 01:53写道:
>
> On Wed, Apr 06, 2022 at 04:03:32PM +0800, 范开喜 wrote:
> > Hi Martin KaFai Lau and Yonghong,
> >
> > I have prepared v3 patches for tunnel source ip feature. Some obviously
> > errors have been fixed. But there are three problems left. They makes me
> > copy tunnel test cases and put tunnel source ip test codes into them.
> > I put these three problems here:
> >
> > I have tried to use bpf_printk in bpf kernel code. But the object file could
> > not be loaded by tc filter command. There are .relxxx section such as
> > .relgre_set_tunnel in the output of objdump.  The tc filter says it could
> > not find the dedicated section.
> > So I still use bpf_trace_printk now.
> >
> > I have tried to use a bpf map "local_ip_array" to store tunnel source ip
> > address. Userspace code change tunnel source ip by updating map
> > "local_ip_array" in the middle of test. Kernel bpf code get the tunnel source
> > ip by looking up the map. But the object file could not be loaded by tc filter
> > command also. The verifier says "R1 type=scalar expected=map_ptr" when
> > calling "bpf_map_lookup_elem" helper function. I check the assembly code
> > that the r1 register value is 0 when calling "bpf_map_lookup_elem".
> > I write a tiny bpf loader for this test. But It's too heavy.
> >
> > I have read test cases in prog_tests directory. They use c code to replace
> > shell command to create network namespace and ping. Also functions like
> > "test_tc_peer__load" are used to load bpf code. It's more complicate than
> > shell commands. And there are many duplicate funtions like create_ns in
> > some files.
> > The code in test_progs.c are common functions not test cases.
> > Maybe we could move tunnel test code to it in the future until the test
> > framework is complete.
> Regarding the "test_tc_peer__load" is more complicated than shell,
> it is the skeleton and a better way to load bpf to do test.
> It makes the user space test easier to write, e.g. the bpf_printk+grep
> for capturing error can go away and replace it with checking some
> bpf's global variables instead.  All newly added tests are using it.
>
> There are examples in prog_tests/ (i.e. test_progs) doing similar things as
> the test_tunnel.sh, e.g. creating netns, adding veth, tc filter...etc.
> For example, take a look at tc_redirect.c and how it avoids the tc bpf
> loading issues that you have seen.
>
> The .sh is not run by CI also.  I also only run test_progs regularly.
> I was also not sure if test_tunnel.sh should further be extended, so
> did not mention it.  However, based on the issues you are seeing from
> making common changes to the bpf prog, it is clear that it should be done
> in prog_tests/ (i.e. test_progs) instead.  At least start with the
> two new tests that you are adding in patch 2 and 3 instead of further
> extending the test_tunnel.sh.  That will setup a base to move
> all test_tunnel.sh to prog_tests/ eventually.

OK. Get it. I will move them to test_progs step by step.
Many thanks.




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux