On Mon, Feb 08, 2021 at 03:31:50PM +0200, Vlad Buslov wrote: > > On Mon 08 Feb 2021 at 15:25, Marcelo Ricardo Leitner > <marcelo.leit...@gmail.com> wrote: > > 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 > > As I wrote in previous email, tunnel endpoint VF is on host (not in > namespace/container, VM, etc.).
Right. I assumed it was just for simplicity of testing. Okay, I think I can see some use cases for this. Thanks. Cheers, Marcelo
