HOWTO interact with BPF subsystem

BPF subsystem 협업 안내

이 문서는 BPF subsystem에서 bug를 report하고 patch를 제출하며 stable kernel용 patch를 queue하는 여러 workflow를 설명합니다.

일반적인 patch 제출 방법은 `Documentation/process/submitting-patches.rst`를 참조하십시오. 이 문서는 BPF에만 해당하는 추가 사항을 다룹니다.

BPF bug report

질문: BPF kernel code의 bug는 어떻게 report합니까? 답변: BPF kernel 개발뿐 아니라 bpftool과 iproute2 BPF loader 개발도 모두 BPF kernel mailing list에서 이루어지므로, BPF와 관련해 발견한 문제는 `bpf@vger.kernel.org`로 report하십시오. XDP, BPF tracing 등에 관련된 문제도 여기에 포함됩니다.

netdev traffic 양이 많으므로 kernel `MAINTAINERS` file에 기재된 BPF maintainer도 Cc에 추가하십시오.

• Alexei Starovoitov <ast@kernel.org>
• Daniel Borkmann <daniel@iogearbox.net>

문제가 있는 commit을 이미 식별했다면 실제 commit author도 report의 Cc에 반드시 포함하십시오. 보통 kernel git tree에서 author를 찾을 수 있습니다.

BPF 문제를 `bugzilla.kernel.org`에 report하지 마십시오. 그곳에 올린 문제는 간과된다고 보아야 합니다.

Review 전 BPF CI 실행

질문: 변경 사항을 review에 보내기 전에 BPF CI를 어떻게 실행합니까? 답변: BPF CI는 GitHub 기반이며 `https://github.com/kernel-patches/bpf`에서 운영됩니다. GitHub CLI로도 같은 결과를 얻을 수 있지만 여기서는 UI 기반 workflow를 설명합니다.

patch에 대한 CI run을 시작하는 절차는 다음과 같습니다.

• 앞서 언급한 repository를 자신의 account로 fork합니다. 이 작업은 한 번만 하면 됩니다.
• fork를 local에 clone하고 `bpf-next` 또는 `bpf` branch를 tracking하는 새 branch를 checkout한 뒤, test할 patch를 그 위에 적용합니다.
• local branch를 자신의 fork에 push하고 각각 `kernel-patches/bpf`의 `bpf-next_base` 또는 `bpf_base` branch를 대상으로 pull request를 만듭니다.

pull request를 만들면 곧 CI workflow가 실행됩니다. upstream에 제출된 patch 검사와 capacity를 공유하므로 사용량에 따라 완료까지 시간이 걸릴 수 있습니다.

`bpf-next_base`와 `bpf_base`는 tracking하는 upstream branch에 patch가 push될 때 갱신됩니다. 따라서 해당 patch set도 자동 rebase가 시도됩니다. 이 동작 때문에 CI run이 중단되고 새 baseline에서 다시 시작될 수 있습니다.

Mailing list와 patchwork

질문: BPF patch를 어느 mailing list에 제출해야 합니까? 답변: BPF kernel mailing list인 `bpf@vger.kernel.org`에 제출하십시오.

patch가 networking, tracing, security 등 여러 subsystem을 변경한다면 관련 kernel mailing list와 maintainer도 Cc에 포함해야 합니다. 그래야 이들이 변경을 review하고 patch에 `Acked-by`를 제공할 수 있습니다.

질문: BPF subsystem에서 현재 논의 중인 patch는 어디에서 찾습니까? 답변: netdev에 Cc된 모든 patch는 netdev patchwork project인 `https://patchwork.kernel.org/project/netdevbpf/list/`에서 review queue에 들어갑니다.

BPF 대상 patch는 BPF maintainer가 처리하도록 `bpf` delegate에 할당됩니다. 현재 review 중인 queue는 `https://patchwork.kernel.org/project/netdevbpf/list/?delegate=121173`에서 확인할 수 있습니다.

BPF community 전체가 review하고 BPF maintainer가 승인하면 patchwork status가 `Accepted`로 바뀌고 제출자에게 mail이 전달됩니다. 이는 BPF 관점에서 patch가 적절하며 두 BPF kernel tree 중 하나에 적용됐다는 뜻입니다.

community feedback 때문에 patch를 다시 작성해야 하면 status는 `Changes Requested`가 되고 현재 review queue에서 제거됩니다. patch가 reject되거나 BPF tree에 적용할 수 없지만 `bpf` delegate에 할당된 경우도 마찬가지입니다.

BPF kernel tree와 mainline 경로

질문: 변경 사항은 어떤 경로로 Linux에 들어갑니까? 답변: BPF maintainer가 patch를 accept하면 두 BPF kernel tree 중 하나에 적용합니다.

• https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/
• https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/

`bpf` tree는 fix 전용이며 `bpf-next`는 feature, cleanup, 그 밖의 improvement 같은 "next-like" content용입니다. networking의 `net`과 `net-next` 관계와 같습니다. rebase할 branch 선택을 단순화하기 위해 `bpf`와 `bpf-next`에는 모두 `master` branch만 있습니다.

`bpf`에 쌓인 patch는 정기적으로 `net` kernel tree로 pull되고, `bpf-next`에서 accept된 patch는 `net-next`로 이동합니다. David S. Miller가 `net`과 `net-next`를 모두 관리하며, 그 뒤 Linus Torvalds가 관리하는 kernel mainline tree로 들어갑니다. `net`과 `net-next`가 mainline에 merge되는 과정은 `Documentation/process/maintainer-netdev.rst`를 참조하십시오.

merge conflict를 막기 위해 가끔 patch 일부를 tracing 같은 다른 tree에 pull request로 보낼 수 있지만, 주된 integration 대상은 항상 `net`과 `net-next`입니다.

pull request에는 누적 patch의 high-level summary가 들어갑니다. `yyyy-mm-dd`가 pull request 날짜일 때 netdev kernel mailing list에서 다음 subject로 찾을 수 있습니다.

pull-request: bpf yyyy-mm-dd
pull-request: bpf-next yyyy-mm-dd

Target tree와 subject prefix

질문: patch를 `bpf`와 `bpf-next` 중 어느 tree에 적용해야 하는지 어떻게 표시합니까? 답변: 절차는 `Documentation/process/maintainer-netdev.rst`의 netdev subsystem 설명과 같습니다. maintainer가 `bpf` 또는 `bpf-next` 대상을 알 수 있도록 subject line에 fix인지 "next-like" content인지 표시해야 합니다.

결국 `bpf -> net` tree로 들어갈 fix의 subject는 다음처럼 만듭니다.

git format-patch --subject-prefix='PATCH bpf' start..finish

`bpf-next -> net-next`로 들어갈 feature, improvement 등의 subject는 다음처럼 만듭니다.

git format-patch --subject-prefix='PATCH bpf-next' start..finish

patch 또는 series가 `bpf`와 `net` 중 어디로, 또는 `bpf-next`와 `net-next` 중 어디로 직접 가야 하는지 확실하지 않다면 subject line의 target을 `net`이나 `net-next`로 적어도 괜찮습니다. 최종 delegation은 maintainer가 결정합니다.

`bpf` 또는 `bpf-next`로 가야 함이 명확하면 잠재적 conflict를 줄이도록 해당 tree를 기준으로 patch를 rebase하십시오.

patch 또는 series를 수정해 두 번째 이상 revision으로 다시 보낼 때는 subject prefix에 `v2`, `v3` 같은 version number도 넣어야 합니다.

git format-patch --subject-prefix='PATCH bpf-next v2' start..finish

patch series에 변경 요청을 받았다면 feedback을 반영한 전체 series를 항상 다시 보내십시오. 이전 series 위에 개별 diff만 보내면 안 됩니다.

BPF tree 적용의 의미

질문: patch가 `bpf` 또는 `bpf-next` tree에 적용됐다는 것은 무엇을 뜻합니까? 답변: BPF 관점에서 mainline inclusion에 적합해 보인다는 뜻입니다.

다만 patch가 결국 `net`이나 `net-next`에 자동으로 accept된다는 최종 판정은 아닙니다. BPF kernel mailing list에는 언제든 review가 들어올 수 있습니다. 논의 결과 patch를 그대로 포함할 수 없다면 follow-up fix를 적용하거나 tree에서 완전히 drop할 수 있으며, 필요하면 tree를 rebase할 수도 있습니다.

이 tree의 목적은 다음 두 가지입니다.

• BPF patch를 누적하고 stage해 `net`, `net-next` 같은 tree로 통합합니다.
• patch가 더 진행되기 전에 광범위한 BPF test suite와 workload를 실행합니다.

David S. Miller가 BPF pull request를 accept하면 patch는 각각 `net` 또는 `net-next` tree에 들어가고 그곳에서 mainline으로 진행합니다. mainline merge 주기 등 자세한 내용은 `Documentation/process/maintainer-netdev.rst`를 다시 참조하십시오.

Feedback 주기와 merge window

질문: BPF patch feedback을 얼마나 기다려야 합니까? 답변: latency를 낮게 유지하려 하며 보통 영업일 기준 2~3일 안에 feedback을 줍니다. 변경 복잡도와 현재 patch load에 따라 달라질 수 있습니다.

질문: `net`이나 `net-next` 같은 주요 kernel tree에 pull request를 얼마나 자주 보냅니까? 답변: `bpf` 또는 `bpf-next`에 너무 많은 patch가 쌓이지 않도록 비교적 자주 보냅니다. 대략 각 tree에 대해 매주 말 정기적으로 보내며, patch load나 긴급성에 따라 주중에도 추가로 보낼 수 있습니다.

질문: merge window가 열려 있을 때 `bpf-next`에 patch를 적용합니까? 답변: merge window 동안에는 `bpf-next`를 처리하지 않습니다. `net-next` patch 처리와 대체로 같으므로 자세한 내용은 `Documentation/process/maintainer-netdev.rst`를 참조하십시오.

약 2주인 merge window 동안에는 `bpf-next`가 다시 열린 뒤 patch series를 재전송해 달라고 요청할 수 있습니다. Linus가 merge window 뒤 `v*-rc1`을 release하면 `bpf-next` 처리를 계속합니다.

kernel mailing list 비구독자를 위해 David S. Miller가 운영하는 `net-next` status page `http://vger.kernel.org/~davem/net-next.html`도 안내를 제공합니다.

Verifier 변경과 test case

질문: BPF verifier를 변경했다면 BPF kernel selftests에 test case를 추가해야 합니까? 답변: patch가 verifier behavior를 바꾼다면 반드시 추가해야 합니다. 필요한데 빠졌다고 판단하면 변경을 accept하기 전에 test 추가를 요청할 수 있습니다.

특히 `test_verifier.c`는 LLVM BPF back end가 제한된 C code에서 생성할 수 있는 많은 corner case를 포함해 수많은 BPF test case를 추적합니다. 미래 변경이 기존 use case에 뜻하지 않은 영향을 주지 않게 하려면 test case 추가가 매우 중요합니다.

따라서 `test_verifier.c`가 추적하지 않는 verifier behavior는 잠재적으로 변경될 수 있다고 간주하십시오.

samples/bpf와 selftests 선택

질문: 언제 `samples/bpf/`에 code를 추가하고 언제 BPF kernel selftests에 추가해야 합니까? 답변: 일반적으로 `samples/bpf/`보다 BPF kernel selftests 추가를 선호합니다. kernel selftest는 여러 bot이 정기 실행해 kernel regression을 검사하기 때문입니다.

BPF selftest에 test case가 많을수록 coverage가 좋아지고 우연히 깨질 가능성이 낮아집니다. BPF kernel selftest도 특정 feature의 사용법을 시연할 수 있습니다.

다만 `samples/bpf/`는 처음 시작하는 사람에게 좋은 곳이므로 간단한 feature demo는 그곳에 둘 수 있습니다. 고급 functional test와 corner-case test는 kernel selftest에 두는 편이 좋습니다.

sample이 test case처럼 보인다면 BPF kernel selftest를 선택하십시오.

bpftool과 iproute2 BPF loader

질문: 언제 bpftool에 code를 추가해야 합니까? 답변: `tools/bpf/bpftool/`의 bpftool은 kernel에서 활성 상태인 BPF program과 map을 debug하고 introspection하는 중앙 userspace tool입니다. BPF 관련 UAPI 변경으로 program이나 map의 추가 정보를 dump할 수 있게 된다면 bpftool도 이를 dump하도록 확장해야 합니다.

질문: 언제 iproute2 BPF loader에 code를 추가해야 합니까? 답변: XDP나 tc layer, 예를 들어 `cls_bpf`와 관련된 UAPI 변경은 관례상 userspace 쪽 iproute2 BPF loader의 control path에도 추가합니다. 이는 UAPI를 실제 사용 가능하게 올바르게 설계하는 데 유용할 뿐 아니라 주요 downstream distribution의 더 넓은 user base에 변경을 제공하는 방법이기도 합니다.

질문: iproute2 BPF loader patch도 받습니까? 답변: 해당 patch는 `netdev@vger.kernel.org`로 보내야 합니다. BPF kernel maintainer가 직접 처리하지는 않지만 review할 수 있도록 이들도 Cc에 남겨 두십시오.

Stephen Hemminger가 운영하는 공식 iproute2 git repository는 `https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/`입니다.

patch subject prefix는 `[PATCH iproute2 master]` 또는 `[PATCH iproute2 net-next]`여야 합니다. `master`와 `net-next`는 patch를 적용할 target branch를 뜻합니다. kernel 변경이 `net-next` kernel tree에 들어갔다면 관련 iproute2 변경도 iproute2 `net-next` branch로 보내고, 그렇지 않으면 `master`를 대상으로 할 수 있습니다. 현재 iproute2 version이 `master`에서 release된 뒤 iproute2 `net-next` branch가 `master`로 merge됩니다.

BPF와 마찬가지로 patch는 netdev project의 patchwork에 들어가고 `shemminger`에게 delegate됩니다. queue는 `http://patchwork.ozlabs.org/project/netdev/list/?delegate=389`에서 확인할 수 있습니다.

Patch 제출 전 최소 요건

질문: BPF patch를 제출하기 위한 최소 요건은 무엇입니까? 답변: 제출 전에 충분한 시간을 들여 patch를 올바르게 test하십시오. 서두르지 마십시오. maintainer가 제대로 test하지 않았음을 발견하면 좋지 않은 인상을 주며, 제출 patch의 test는 필수 요건입니다.

`bpf` tree로 가는 fix에는 반드시 `Fixes:` tag가 있어야 합니다. 영향받은 commit이 `net-next` 또는 경우에 따라 `bpf-next`에 있을 때 `bpf-next`를 대상으로 하는 fix에도 같은 규칙이 적용됩니다. `Fixes:` tag는 follow-up commit을 식별하고 backport 작업을 크게 도우므로 필수입니다.

빈 commit message가 있는 patch도 accept하지 않습니다. 시간을 들여 고품질 commit message를 작성해야 합니다.

한 달 뒤 code를 보는 다른 developer가 특정 변경을 왜 그런 방식으로 했는지, 원 author의 분석이나 가정에 결함이 있었는지 이해할 수 있어야 합니다. 따라서 적절한 근거와 변경의 use case를 설명해야 합니다.

patch가 두 개 이상인 제출에는 series의 high-level description을 담은 cover letter가 반드시 있어야 합니다. 이 summary는 BPF maintainer가 merge commit에 넣으므로 이후에도 git log에서 참조할 수 있습니다.

BPF JIT·LLVM과 BPF_INTERNAL

질문: BPF JIT 또는 LLVM integration이 필요한 새 instruction이나 feature를 추가할 때 무엇을 고려해야 합니까? 답변: in-kernel BPF JIT가 활성화된 환경에서 program이 덜 효율적인 interpreter로 넘어가지 않고 architecture가 달라도 같은 user experience를 보장할 수 있도록 모든 BPF JIT를 최신 상태로 유지하려 노력합니다.

특정 architecture에 필요한 JIT 변경을 구현하거나 test할 수 없다면 관련 BPF JIT developer와 협력해 제때 feature를 구현하십시오. 도움을 줄 사람은 git log의 `arch/*/net/`에서 찾을 수 있습니다.

새 instruction에는 `test_bpf.c`, `test_verifier.c` 같은 BPF test case를 항상 추가해 넓은 coverage를 확보하고 여러 BPF JIT를 runtime에 test할 수 있게 하십시오.

새 BPF instruction 변경이 Linux kernel에 accept된 뒤에는 LLVM BPF back end에도 support를 구현하십시오. 자세한 내용은 아래 LLVM section을 참조하십시오.

질문: `BPF_INTERNAL` symbol namespace는 무엇을 위한 것입니까? 답변: `BPF_INTERNAL`로 export한 symbol은 light skeleton을 사용하는 preload kernel module 같은 BPF infrastructure만 사용할 수 있습니다. `BPF_INTERNAL` 밖의 symbol 대부분도 BPF 외부 code가 사용할 것으로 기대하지 않습니다. namespace보다 오래된 symbol이거나 누락 때문에 designation이 없을 수 있습니다.

Stable kernel에 특정 fix 요청

질문: stable kernel에 특정 BPF commit이 필요하면 어떻게 합니까? 답변: 먼저 관련 `linux-*.y` branch에 그 commit이 이미 적용됐는지 `https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/`에서 확인하십시오.

적용되지 않았다면 `netdev@vger.kernel.org` kernel mailing list를 Cc에 넣고 BPF maintainer에게 mail을 보내 fix를 queue해 달라고 요청하십시오.

일반 절차는 netdev 자체와 같으며 networking subsystem 문서 `Documentation/process/maintainer-netdev.rst`도 참조하십시오.

질문: 현재 stable로 유지보수되지 않는 kernel에도 backport합니까? 답변: 하지 않습니다. stable maintainer가 현재 유지하지 않는 kernel에 특정 BPF commit이 필요하면 직접 처리해야 합니다.

현재 stable 및 longterm stable kernel 목록은 `https://www.kernel.org/`에 있습니다.

Stable 제출과 queue

질문: 제출하려는 BPF patch가 stable에도 들어가야 하면 어떻게 합니까? 답변: 일반 netdev patch 제출과 같은 규칙이 적용되므로 `Documentation/process/maintainer-netdev.rst`를 참조하십시오.

patch description에 `Cc: stable@vger.kernel.org`를 절대 추가하지 말고 BPF maintainer에게 patch를 queue해 달라고 요청하십시오. git log에는 들어가지 않는 patch의 `---` 아래에 note를 적거나 단순히 mail로 요청할 수 있습니다.

질문: stable로 제출될 예정인 BPF patch queue는 어디에서 찾습니까? 답변: critical bug를 고친 patch가 `bpf` tree에 적용되면 `http://patchwork.ozlabs.org/bundle/bpf/stable/?state=*` 아래에서 stable 제출용으로 queue됩니다.

관련 commit이 mainline kernel tree에 들어갈 때까지 최소한 그곳에서 hold됩니다. 더 넓은 환경에 노출된 뒤 BPF maintainer가 queue된 patch를 stable maintainer에게 제출합니다.

BPF selftest 실행과 BTF 준비

질문: BPF selftest를 어떻게 실행합니까? 답변: 새로 compile한 kernel로 boot한 뒤 clone한 git tree root를 현재 directory로 두고 BPF selftests suite로 이동해 build합니다.

$ cd tools/testing/selftests/bpf/
$ make

verifier test는 다음처럼 실행합니다.

$ sudo ./test_verifier

verifier test는 현재 수행하는 모든 check를 출력합니다. 전체 test가 끝나면 성공과 실패 정보를 summary로 표시합니다.

Summary: 418 PASSED, 0 FAILED

모든 BPF selftest를 실행하려면 다음 command가 필요합니다.

$ sudo make run_tests

자세한 내용은 kernel selftest 문서 `</dev-tools/kselftest>`를 참조하십시오. 통과하는 test 수를 최대화하려면 test 대상 kernel의 `.config`를 `tools/testing/selftests/bpf`에 있는 config file fragment와 최대한 가깝게 맞춰야 합니다.

`Documentation/bpf/btf.rst`에서 다루는 최신 BPF Type Format feature를 지원하려면 `CONFIG_DEBUG_INFO_BTF=y`로 build하는 kernel에 pahole version 1.16이 필요합니다. pahole은 dwarves package로 제공되며 `https://github.com/acmel/dwarves` source에서 build할 수도 있습니다.

pahole source와 selftest version

pahole은 commit `21507cd3e97b`("pahole: add libbpf as submodule under lib/bpf") 이후 v1.13부터 libbpf definition과 API를 사용합니다. git repository에서는 `git submodule update --init --recursive`가 libbpf submodule을 갱신하므로 잘 동작합니다.

하지만 기본 GitHub release source code에는 libbpf submodule source가 없어 build 문제가 생깁니다. `https://git.kernel.org/pub/scm/devel/pahole/pahole.git/`의 tarball도 GitHub와 같습니다. 해당 libbpf submodule code를 포함한 source tarball은 `https://fedorapeople.org/~acme/dwarves`에서 받을 수 있습니다.

Fedora와 Gentoo 등 일부 distribution은 이미 pahole version 1.16 package를 제공합니다.

질문: kernel을 어느 BPF kernel selftest version으로 test해야 합니까? 답변: kernel `xyz`를 실행한다면 항상 같은 kernel `xyz`의 BPF kernel selftest를 실행하십시오. 최신 mainline tree의 BPF selftest가 언제나 통과할 것이라고 기대하면 안 됩니다.

특히 `test_bpf.c`와 `test_verifier.c`에는 많은 test case가 있으며 새 BPF test sequence가 계속 추가됩니다. verifier가 더 똑똑해져 특정 항목을 더 잘 추적하는 등의 변경에 맞춰 기존 sequence도 계속 수정됩니다.

LLVM BPF back end 확인

질문: BPF를 지원하는 LLVM은 어디에서 찾습니까? 답변: LLVM의 BPF back end는 version 3.7.1부터 upstream에 포함됐습니다.

현재 모든 주요 distribution이 BPF back end를 활성화한 LLVM을 제공하므로 대부분의 use case에서는 LLVM을 직접 compile할 필요 없이 distribution package를 설치하면 됩니다.

LLVM static compiler가 지원하는 target은 `llc --version`으로 나열할 수 있습니다. 출력에 BPF target이 있는지 확인하십시오. 예시는 다음과 같습니다.

$ llc --version
LLVM (http://llvm.org/):
  LLVM version 10.0.0
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: skylake

  Registered Targets:
    aarch64    - AArch64 (little endian)
    bpf        - BPF (host endian)
    bpfeb      - BPF (big endian)
    bpfel      - BPF (little endian)
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64

LLVM BPF back end에 추가된 최신 feature를 활용하려는 developer는 최신 LLVM release를 사용하는 편이 좋습니다. BPF instruction set 추가 같은 새 BPF kernel feature는 흔히 LLVM support와 함께 개발됩니다.

모든 LLVM release는 `http://releases.llvm.org/`에서 찾을 수 있습니다.

LLVM 직접 build

질문: 그래도 LLVM을 직접 build하려면 어떻게 합니까? 답변: 가장 빠른 incremental build를 원하는 developer에게 Ninja build system을 권장합니다. system package manager에서 보통 `ninja` 또는 `ninja-build` package로 찾을 수 있습니다.

LLVM build prerequisite로 ninja, cmake, gcc-c++가 필요합니다. 준비한 뒤 git repository의 최신 LLVM과 clang을 다음처럼 build합니다.

$ git clone https://github.com/llvm/llvm-project.git
$ mkdir -p llvm-project/llvm/build
$ cd llvm-project/llvm/build
$ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
           -DLLVM_ENABLE_PROJECTS="clang"    \
           -DCMAKE_BUILD_TYPE=Release        \
           -DLLVM_BUILD_RUNTIME=OFF
$ ninja

build된 binary는 `build/bin/` directory에 있으며 이 directory를 `PATH` variable로 지정할 수 있습니다.

`-DLLVM_TARGETS_TO_BUILD`는 build하려는 target과 같게 설정하십시오. 전체 target 목록은 `llvm-project/llvm/lib/Target` directory에서 찾을 수 있습니다.

LLVM BPF 문제 report

질문: LLVM BPF code generation back end 문제나 LLVM이 생성했지만 verifier가 거부하는 code 문제를 BPF kernel maintainer에게 알려야 합니까? 답변: 반드시 알려야 합니다.

LLVM BPF back end는 전체 BPF infrastructure의 핵심이며 kernel 쪽 program verification과 깊이 연결됩니다. 어느 쪽에서든 발생한 문제는 조사하고 필요하면 수정해야 합니다.

따라서 netdev kernel mailing list에 문제를 제기하고 LLVM 및 kernel 부분의 BPF maintainer를 Cc에 포함하십시오.

• Yonghong Song <yhs@fb.com>
• Alexei Starovoitov <ast@kernel.org>
• Daniel Borkmann <daniel@iogearbox.net>

LLVM에는 BPF 관련 bug를 찾을 수 있는 issue tracker `https://bugs.llvm.org/buglist.cgi?quicksearch=bpf`도 있습니다. 하지만 maintainer를 Cc에 넣어 mailing list로 연락하는 편이 더 좋습니다.

새 BPF instruction의 LLVM 통합

질문: kernel에 새 BPF instruction을 추가했다면 LLVM에 어떻게 통합합니까? 답변: LLVM BPF back end에는 BPF instruction set extension을 선택하는 `-mcpu` selector가 있습니다. LLVM version 20 전에는 BPF base instruction set v1인 `generic` processor target을 사용했습니다. LLVM 20부터 default processor target은 instruction set v3로 바뀌었습니다.

LLVM에는 `-mcpu=probe` option도 있습니다. host kernel이 지원하는 BPF instruction set extension을 probe해 최적 집합을 자동 선택합니다.

cross-compilation에서는 특정 version을 수동으로 선택할 수도 있습니다.

$ llc -march bpf -mcpu=help
Available CPUs for this target:

  generic - Select the generic processor.
  probe   - Select the probe processor.
  v1      - Select the v1 processor.
  v2      - Select the v2 processor.
[...]

Linux kernel에 새로 추가하는 BPF instruction도 같은 scheme을 따라야 합니다. instruction set version을 올리고 extension probing을 구현해, `-mcpu=probe` user가 kernel upgrade 시 자동으로 optimization의 이점을 얻도록 하십시오.

새 BPF instruction support를 구현할 수 없다면 BPF developer에게 도움을 요청하십시오. BPF kernel selftest도 더 나은 test coverage를 위해 `-mcpu=probe`로 실행됩니다.

clang target이 생성 code에 미치는 영향

질문: 어떤 경우에는 clang flag `--target=bpf`를 쓰고 다른 경우에는 underlying architecture와 일치하는 default clang target을 씁니다. 차이는 무엇이며 언제 어느 것을 사용해야 합니까? 답변: LLVM IR 생성과 optimization은 architecture independent하게 유지하려 하지만 `--target=<arch>`는 생성 code에 여전히 영향을 줍니다.

• BPF program이 file-scope inline assembly code가 있는 header file을 재귀적으로 include할 수 있습니다. default target은 이를 잘 처리하지만 BPF backend assembler는 대부분 이 assembly code를 이해하지 못하므로 `bpf` target이 실패할 수 있습니다.
• `-g` 없이 compile하면 default target의 object file에는 `.eh_frame`, `.rela.eh_frame` 같은 ELF section이 추가될 수 있지만 `bpf` target에는 생기지 않습니다.
• default target은 C switch statement를 switch table lookup과 jump operation으로 바꿀 수 있습니다. switch table은 global readonly section에 놓이므로 BPF program load가 실패합니다. `bpf` target은 switch table optimization을 지원하지 않습니다. clang option `-fno-jump-tables`로 switch table 생성을 끌 수 있습니다.
• clang `--target=bpf`에서는 underlying clang binary, default target 또는 kernel이 32-bit인지와 무관하게 pointer와 `long`/`unsigned long` type의 width가 항상 64-bit임을 보장합니다. native clang target은 underlying architecture convention을 따르므로 32-bit architecture에서는 BPF context structure의 해당 type도 32-bit가 되지만 BPF LLVM back end는 여전히 64-bit로 동작합니다. native target은 주로 CPU register width가 중요한 tracing에서 `pt_regs`나 다른 kernel structure를 순회할 때 필요합니다. 그 밖에는 일반적으로 `clang --target=bpf`를 권장합니다.

Default target과 bpf target 선택

다음 경우에는 default target을 사용해야 합니다.

• program이 `ptrace.h` 같은 header file을 include하고, 그 header가 결국 file-scope host assembly code를 포함한 header를 가져옵니다.
• switch table 문제를 피하기 위해 `-fno-jump-tables`를 추가할 수 있습니다.

그 밖의 경우에는 `bpf` target을 사용할 수 있습니다. 다음 경우에는 반드시 `bpf` target을 사용해야 합니다.

• program이 BPF helper 또는 context data structure와 interface하는 pointer나 `long`/`unsigned long` type의 data structure를 사용합니다. verifier가 이 structure access를 검사하므로 native architecture가 64-bit인 BPF architecture와 일치하지 않으면 verification failure가 발생할 수 있습니다. 예를 들어 `BPF_PROG_TYPE_SK_MSG`는 `--target=bpf`를 요구합니다.

원문의 selftests link는 `https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/`를 가리킵니다.

즐거운 BPF hacking을 기원합니다.