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: optmize builtin functions before we fallback to them #11089

Merged
merged 4 commits into from Apr 24, 2020

Conversation

borkmann
Copy link
Member

See commit msg.

@borkmann borkmann added wip 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 Apr 22, 2020
@borkmann borkmann requested a review from a team April 22, 2020 00:45
@maintainer-s-little-helper maintainer-s-little-helper bot added this to In progress in 1.8.0 Apr 22, 2020
@joestringer
Copy link
Member

Huh, apparently one of the very few bpf/ unit tests triggered a failure on this:

test/bpf/unit-test
unit-test: ../../bpf/lib/ipv6_test.h:15: test_ipv6_addr_clear_suffix: Assertion `(__builtin_constant_p(v6.p1) ? ((__u32)( (((__u32)((__be32)(v6.p1)) & (__u32)0x000000ffUL) << 24) | (((__u32)((__be32)(v6.p1)) & (__u32)0x0000ff00UL) << 8) | (((__u32)((__be32)(v6.p1)) & (__u32)0x00ff0000UL) >> 8) | (((__u32)((__be32)(v6.p1)) & (__u32)0xff000000UL) >> 24))) : __builtin_bswap32(v6.p1)) == 0xffffffff' failed.

@borkmann borkmann force-pushed the pr/xdp-follow-ups-3 branch 6 times, most recently from 013032a to 16e925f Compare April 22, 2020 12:34
Copy link
Member

@tklauser tklauser left a comment

Choose a reason for hiding this comment

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

Small nit: s/optmize/optimize/ in commit message and PR title.

@aanm aanm marked this pull request as draft April 23, 2020 10:06
@aanm aanm removed the wip label Apr 23, 2020
@aanm
Copy link
Member

aanm commented Apr 23, 2020

this PR has been marked as a draft PR since it had a WIP label. Please click in "Ready for review" [below vvv ] once the PR is ready to be reviewed. CI will still run for draft PRs.

@borkmann borkmann force-pushed the pr/xdp-follow-ups-3 branch 2 times, most recently from f038a99 to 9a3a578 Compare April 24, 2020 00:02
@borkmann borkmann marked this pull request as ready for review April 24, 2020 00:03
@borkmann
Copy link
Member Author

test-me-please

@borkmann
Copy link
Member Author

test-me-please

@borkmann
Copy link
Member Author

test-me-please

@coveralls
Copy link

coveralls commented Apr 24, 2020

Coverage Status

Coverage increased (+0.007%) to 44.768% when pulling fa17377 on pr/xdp-follow-ups-3 into 3ed89e4 on master.

@borkmann
Copy link
Member Author

test-me-please

@borkmann
Copy link
Member Author

test-me-please

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.

This is great! One nit and a couple questions below.

Did you get a chance to check the complexity and program size impact? It looks like it could have a bigger impact than other mitigations we've discussed, and on all kernels 🎉

bpf/include/bpf/builtins.h Outdated Show resolved Hide resolved
bpf/include/bpf/builtins.h Outdated Show resolved Hide resolved
bpf/include/bpf/builtins.h Show resolved Hide resolved
Convert all direct use of __builtin_mem{cpy,set}() over to the
regular mem{cpy,set}() function as we're going to have a custom
implementation of the latter two.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
While checking some of the xlated code from XDP side, I recently
noticed __builtin_memcpy() patterns like:

  [...]
      14:    55 04 ee 00 00 00 00 00    if r4 != 0 goto +238 <LBB0_2>
      15:    71 32 2f 00 00 00 00 00    r2 = *(u8 *)(r3 + 47)
      16:    67 02 00 00 08 00 00 00    r2 <<= 8
      17:    71 31 2e 00 00 00 00 00    r1 = *(u8 *)(r3 + 46)
      18:    4f 12 00 00 00 00 00 00    r2 |= r1
      19:    7b 2a 78 ff 00 00 00 00    *(u64 *)(r10 - 136) = r2
      20:    71 32 37 00 00 00 00 00    r2 = *(u8 *)(r3 + 55)
      21:    67 02 00 00 08 00 00 00    r2 <<= 8
      22:    71 31 36 00 00 00 00 00    r1 = *(u8 *)(r3 + 54)
      23:    4f 12 00 00 00 00 00 00    r2 |= r1
      24:    7b 2a b0 ff 00 00 00 00    *(u64 *)(r10 - 80) = r2
  [...]

This is bad since we end up doing byte-wise copy of data. LLVM is
not aware of efficient unaligned access on x86-64 or arm64 etc so
it cannot make any assumptions on the access.

Implement optimized routines and make sure we don't blindly use
pain __builtin_*() directly in the code.

  [...]
      15:    79 31 38 00 00 00 00 00    r1 = *(u64 *)(r3 + 56)
      16:    7b 1a f8 ff 00 00 00 00    *(u64 *)(r10 - 8) = r1
      17:    79 31 30 00 00 00 00 00    r1 = *(u64 *)(r3 + 48)
      18:    7b 1a f0 ff 00 00 00 00    *(u64 *)(r10 - 16) = r1
      19:    79 31 28 00 00 00 00 00    r1 = *(u64 *)(r3 + 40)
      20:    7b 1a e8 ff 00 00 00 00    *(u64 *)(r10 - 24) = r1
      21:    79 31 20 00 00 00 00 00    r1 = *(u64 *)(r3 + 32)
      22:    7b 1a e0 ff 00 00 00 00    *(u64 *)(r10 - 32) = r1
      23:    79 31 18 00 00 00 00 00    r1 = *(u64 *)(r3 + 24)
      24:    7b 1a d8 ff 00 00 00 00    *(u64 *)(r10 - 40) = r1
  [...]

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Place them into its own directory instead of directly into lib/
code. Adding more into lib/ would convolute it too much. Also
add a Wno-builtin-declaration-mismatch for gcc.

Tested via: # make unit-tests TESTPKGS=

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
@borkmann borkmann requested review from a team as code owners April 24, 2020 12:05
@borkmann
Copy link
Member Author

test-me-please

Add various new test cases for mem{cpy,set} adn run them as part
of the bpf unit tests. I've added barrier_data() from [0] to
prevent the compiler from any optimizations on the test data.

Tested via: # make unit-tests TESTPKGS=

  [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7829fb09a2b4268b30dd9bc782fa5ebee278b137

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
@borkmann
Copy link
Member Author

test-me-please

@borkmann
Copy link
Member Author

 98 9987M   98 9841M    0     0   104M      0  0:01:35  0:01:34  0:00:01  112M
 99 9987M   99 9953M    0     0   104M      0  0:01:35  0:01:35 --:--:--  112M
100 9987M  100 9987M    0     0   104M      0  0:01:35  0:01:35 --:--:--  112M
12:58:21  The machine index which stores all required information about
12:58:21  running Vagrant environments has become corrupt. This is usually
12:58:21  caused by external tampering of the Vagrant data folder.
12:58:21  
12:58:21  Vagrant cannot manage any Vagrant environments if the index is
12:58:21  corrupt. Please attempt to manually correct it. If you are unable
12:58:21  to manually correct it, then remove the data file at the path below.
12:58:21  This will leave all existing Vagrant environments "orphaned" and
12:58:21  they'll have to be destroyed manually.
12:58:21  
12:58:21  Path: /root/.vagrant.d/data/machine-index/index
12:58:21  box locked or unavailable, adding box from vagrant cloud
12:58:22  The machine index which stores all required information about
12:58:22  running Vagrant environments has become corrupt. This is usually
12:58:22  caused by external tampering of the Vagrant data folder.
12:58:22  
12:58:22  Vagrant cannot manage any Vagrant environments if the index is
12:58:22  corrupt. Please attempt to manually correct it. If you are unable
12:58:22  to manually correct it, then remove the data file at the path below.
12:58:22  This will leave all existing Vagrant environments "orphaned" and
12:58:22  they'll have to be destroyed manually.
12:58:22  
12:58:22  Path: /root/.vagrant.d/data/machine-index/index
Post stage

@borkmann
Copy link
Member Author

test-with-kernel

Copy link
Member

@qmonnet qmonnet left a comment

Choose a reason for hiding this comment

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

Very nice set! Thanks

@borkmann
Copy link
Member Author

restart-gke

@borkmann
Copy link
Member Author

gke known hubble flake via #11141 (prior run before rebase was green on gke as well)

@pchaigno
Copy link
Member

@cilium/ci is requested for review because of error in CODEOWNERS. #11125 should fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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
No open projects
1.8.0
  
Merged
Development

Successfully merging this pull request may close these issues.

None yet

7 participants