Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpf: avoid encrypt_key map lookup if IPsec is disabled #17840

Merged
merged 2 commits into from Nov 12, 2021

Conversation

tklauser
Copy link
Member

Avoid an unnecessary map lookup for encrypt_key in the bpf_lxc program in case IPsec is disabled. Also fix warnings/errors when building with LLVM 14. See individual commit messages for details.

@tklauser tklauser added sig/datapath Impacts bpf/ or low-level forwarding details, including map management and monitor messages. release-note/misc This PR makes changes that have no direct user impact. labels Nov 10, 2021
@tklauser tklauser requested review from a team and brb November 10, 2021 10:19
@tklauser
Copy link
Member Author

/test

Copy link
Member

@pchaigno pchaigno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me; one nit below.

Did you also try to load the programs compiled with LLVM 14?

bpf/bpf_lxc.c Outdated Show resolved Hide resolved
@tklauser
Copy link
Member Author

Did you also try to load the programs compiled with LLVM 14?

So far I haven't tried loading them, just incidentally noticed these errors while compile testing some other changes locally where I apparently have LLVM 14 installed. What would be the best way to load-test the programs? (Sorry, I'm not that experienced with datapath development yet).

Building the BPF datapath with LLVM 14 leads to the following errors:

    bpf_lxc.c:101:16: error: variable 'daddr' set but not used [-Werror,-Wunused-but-set-variable]
            union v6addr *daddr, orig_dip;
                          ^
    bpf_lxc.c:103:7: error: variable 'encrypt_key' set but not used [-Werror,-Wunused-but-set-variable]
            __u8 encrypt_key = 0;
                 ^
    bpf_lxc.c:102:8: error: variable 'tunnel_endpoint' set but not used [-Werror,-Wunused-but-set-variable]
            __u32 tunnel_endpoint = 0;
                  ^
    bpf_lxc.c:526:7: error: variable 'encrypt_key' set but not used [-Werror,-Wunused-but-set-variable]
            __u8 encrypt_key = 0;
                 ^
    bpf_lxc.c:525:8: error: variable 'tunnel_endpoint' set but not used [-Werror,-Wunused-but-set-variable]
            __u32 tunnel_endpoint = 0;
                  ^

These are normally warnings, but errors in this case due to the use of
-Werror when compiling Cilium's bpf programs. Fix these by marking the
affected variables as __maybe_unused.

Signed-off-by: Tobias Klauser <tobias@cilium.io>
In the bpf_lxc program's functions ipv6_l3_from_lxc and
handle_ipv4_from_lxc, currently encrypt_key is always looked up in the
encrypt map, regardless of whether IPsec is enabled or not. However, its
value is only actually used when IPsec is enabled. Thus, the call can
be avoid when IPsec is disabled.

This also slightly reduces program size if !defined(ENABLE_IPSEC).

Signed-off-by: Tobias Klauser <tobias@cilium.io>
@pchaigno
Copy link
Member

What would be the best way to load-test the programs?

You don't need to. I was just curious because I'd expect loading with LLVM 14 to fail given it fails with LLVM 12+.

@tklauser
Copy link
Member Author

tklauser commented Nov 11, 2021

/test

Job 'Cilium-PR-K8s-1.21-kernel-4.19' failed and has not been observed before, so may be related to your PR:

Click to show.

Test Name

K8sServicesTest Checks service across nodes Tests NodePort BPF Tests with vxlan Tests with secondary NodePort device

Failure Output

FAIL: Request from k8s1 to service http://192.168.37.12:30006 failed

If it is a flake, comment /mlh new-flake Cilium-PR-K8s-1.21-kernel-4.19 so I can create a new GitHub issue to track it.

@pchaigno pchaigno added the area/encryption Impacts encryption support such as IPSec, WireGuard, or kTLS. label Nov 11, 2021
@tklauser
Copy link
Member Author

tklauser commented Nov 11, 2021

test-1.21-4.19

previous run hit #12690: https://jenkins.cilium.io/job/Cilium-PR-K8s-1.21-kernel-4.19/136/

@tklauser
Copy link
Member Author

Paul approved and CI is green, marking as ready to merge.

@tklauser tklauser added the ready-to-merge This PR has passed all tests and received consensus from code owners to merge. label Nov 12, 2021
@ti-mo ti-mo merged commit 3cb9ba1 into cilium:master Nov 12, 2021
@tklauser tklauser deleted the bpf-fix-llvm-14-warnings branch November 12, 2021 09:45
@YutaroHayakawa
Copy link
Member

YutaroHayakawa commented Mar 4, 2022

Let me request backporting this PR to 1.10 branch. The background is this issue (#18591).

According to the user

  • The user met the complexity issue when he upgrade his kernel to 5.15.12-1 to 5.16.1-1
  • But when he upgraded the Cilium from 1.10.6 to 1.11.1 , the issue has gone

We can say two things from here

  • From kernel 5.15.12-1 to 5.16.1-1 , there are/is some change(s) that “increase” the complexity
  • From Cilium 1.10.6 to 1.11.1 , there are/is some change(s) that “decrease” the complexity

I could reproduce the issue in my local (see the original issue), and when I backport this PR over 1.10.6, it resolved the complexity issue at least for their configuration (--set cni.exclusive=true).

That's why I think it's worth backporting this PR to 1.10.

@tklauser tklauser unassigned brb Mar 4, 2022
@tklauser tklauser removed the request for review from brb March 4, 2022 13:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/encryption Impacts encryption support such as IPSec, WireGuard, or kTLS. ready-to-merge This PR has passed all tests and received consensus from code owners to merge. release-note/misc This PR makes changes that have no direct user impact. sig/datapath Impacts bpf/ or low-level forwarding details, including map management and monitor messages.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants