On Mon, Feb 08, 2021 at 10:21:21AM +0200, Vlad Buslov wrote: > > On Sat 06 Feb 2021 at 20:13, Marcelo Ricardo Leitner > <marcelo.leit...@gmail.com> wrote: > > Hi, > > > > I didn't receive the cover letter, so I'm replying on this one. :-) > > > > This is nice. One thing is not clear to me yet. From the samples on > > the cover letter: > > > > $ tc -s filter show dev enp8s0f0_1 ingress > > filter protocol ip pref 4 flower chain 0 > > filter protocol ip pref 4 flower chain 0 handle 0x1 > > dst_mac 0a:40:bd:30:89:99 > > src_mac ca:2e:a7:3f:f5:0f > > eth_type ipv4 > > ip_tos 0/0x3 > > ip_flags nofrag > > in_hw in_hw_count 1 > > action order 1: tunnel_key set > > src_ip 7.7.7.5 > > dst_ip 7.7.7.1 > > ... > > > > $ tc -s filter show dev vxlan_sys_4789 ingress > > filter protocol ip pref 4 flower chain 0 > > filter protocol ip pref 4 flower chain 0 handle 0x1 > > dst_mac ca:2e:a7:3f:f5:0f > > src_mac 0a:40:bd:30:89:99 > > eth_type ipv4 > > enc_dst_ip 7.7.7.5 > > enc_src_ip 7.7.7.1 > > enc_key_id 98 > > enc_dst_port 4789 > > enc_tos 0 > > ... > > > > These operations imply that 7.7.7.5 is configured on some interface on > > the host. Most likely the VF representor itself, as that aids with ARP > > resolution. Is that so? > > > > Thanks, > > Marcelo > > Hi Marcelo, > > The tunnel endpoint IP address is configured on VF that is represented > by enp8s0f0_0 representor in example rules. The VF is on host.
That's interesting and odd. The VF would be isolated by a netns and not be visible by whoever is administrating the VF representor. Some cooperation between the two entities (host and container, say) is needed then, right? Because the host needs to know the endpoint IP address that the container will be using, and vice-versa. If so, why not offload the tunnel actions via the VF itself and avoid this need for cooperation? Container privileges maybe? Thx, Marcelo
