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.