Yonghong Song <yhs@xxxxxx> 于2022年3月29日周二 07:10写道： > > > > On 3/26/22 10:04 AM, 范开喜 wrote: > > Yonghong Song <yhs@xxxxxx> 于2022年3月26日周六 00:41写道： > >> > >> > >> > >> On 3/22/22 8:42 AM, fankaixi.li@xxxxxxxxxxxxx wrote: > >>> From: "kaixi.fan" <fankaixi.li@xxxxxxxxxxxxx> > >>> > >>> Vxlan tunnel is chosen to test bpf code could configure tunnel > >>> source ipv4 address. > >> > >> The added test configures tunnel source ipv4 address. > >> > >> >It's sufficient to prove that other types > >>> tunnels could also do it. > >> > >> Could you be more specific what other types will also use source ipv4 > >> address. It is too vague to claim "it's sufficient to prove ...". > >> > > > > Is it better to add more test cases for other types of ip tunnels ? It would > > introduce more duplicate codes. > > > > In the kernel, this is referred to as collect metadata mode as follows: > > https://man7.org/linux/man-pages/man8/ip-link.8.html > > Kernel use "struct ip_tunnel_info" to save tunnel parameters, and use > > it for tunnel encapsulation. The process is similar for vxlan, gre,/gretap, > > geneve, ipip and erspan tunnels. > > The previous test cases in "test_tunnel.sh" test this mechanism for bpf > > program code already. Based on this mechanism, I just use vxlan tunnel > > to test tunnel source ip configuration. > > You can just mention something like: > Other type of tunnels, e.g., gre, gretap, geneve, ipip, erspan, etc, > can also configure tunnel source ip addresses. > Thanks. It's more clear as you say ! > > > >> > >>> In the vxlan tunnel testcase, two underlay ipv4 addresses > >>> are configured on veth device in root namespace. Test bpf kernel > >>> code would configure the secondary ipv4 address as the tunnel > >>> source ip. > >>> > >>> Signed-off-by: kaixi.fan <fankaixi.li@xxxxxxxxxxxxx> > >> > >> Again, please use proper name in Signed-off-by tag. > > > > Thanks. I will fix it. > > > [...]
