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.
