From 6678e4d3d2ff19212fce4ac3025ff16f40da1f55 Mon Sep 17 00:00:00 2001 From: Billy McFall <22157057+Billy99@users.noreply.github.com> Date: Wed, 2 Oct 2024 11:43:18 -0400 Subject: [PATCH] Address comments To be squashed after review. Signed-off-by: Billy McFall <22157057+Billy99@users.noreply.github.com> --- docs/developer-guide/develop-operator.md | 30 ++++++---- docs/developer-guide/image-build.md | 34 ++++++------ docs/developer-guide/testing.md | 67 +++++++++++------------ docs/developer-guide/xdp-overview.md | 2 +- docs/getting-started/building-bpfman.md | 16 +++--- docs/getting-started/cli-guide.md | 34 ++++++++---- docs/getting-started/example-bpf-local.md | 4 +- docs/getting-started/launching-bpfman.md | 2 +- docs/getting-started/running-rpm.md | 6 +- 9 files changed, 110 insertions(+), 85 deletions(-) diff --git a/docs/developer-guide/develop-operator.md b/docs/developer-guide/develop-operator.md index 8be668c50..e85bcd621 100644 --- a/docs/developer-guide/develop-operator.md +++ b/docs/developer-guide/develop-operator.md @@ -18,7 +18,7 @@ For building and deploying the bpfman-operator simply see the attached `make hel output. ```bash -make help +$ make help Usage: make @@ -44,8 +44,10 @@ Development generate-typed-clients Generate typed client code generate-typed-listers Generate typed listers code generate-typed-informers Generate typed informers code + vendors Refresh vendors directory. fmt Run go fmt against code. verify Verify all the autogenerated code + lint Run linter (golangci-lint). test Run Unit tests. test-integration Run Integration tests. bundle Generate bundle manifests and metadata, then validate generated files. @@ -53,11 +55,14 @@ Development Build build Build bpfman-operator and bpfman-agent binaries. - build-images Build bpfman, bpfman-agent, and bpfman-operator images. - push-images Push bpfman, bpfman-agent, bpfman-operator images. - load-images-kind Load bpfman, bpfman-agent, and bpfman-operator images into the running local kind devel cluster. + build-images Build bpfman-agent and bpfman-operator images. + build-operator-image Build bpfman-operator image. + build-agent-image Build bpfman-agent image. + push-images Push bpfman-agent and bpfman-operator images. + load-images-kind Load bpfman-agent, and bpfman-operator images into the running local kind devel cluster. bundle-build Build the bundle image. bundle-push Push the bundle image. + catalog-update Generate catalog yaml file. catalog-build Build a catalog image. catalog-push Push a catalog image. @@ -67,6 +72,7 @@ CRD Deployment Vanilla K8s Deployment setup-kind Setup Kind cluster + destroy-kind Destroy Kind cluster deploy Deploy bpfman-operator to the K8s cluster specified in ~/.kube/config with the csi driver initialized. undeploy Undeploy bpfman-operator from the K8s cluster specified in ~/.kube/config. Call with ignore-not-found=true to ignore resource not found errors during deletion. kind-reload-images Reload locally build images into a kind cluster and restart the ds and deployment so they're picked up. @@ -75,6 +81,8 @@ Vanilla K8s Deployment Openshift Deployment deploy-openshift Deploy bpfman-operator to the Openshift cluster specified in ~/.kube/config. undeploy-openshift Undeploy bpfman-operator from the Openshift cluster specified in ~/.kube/config. Call with ignore-not-found=true to ignore resource not found errors during deletion. + catalog-deploy Deploy a catalog image. + catalog-undeploy Undeploy a catalog image. ``` ### Project Layout @@ -187,7 +195,7 @@ If any of the files are modified, then regenerate these files using: ```bash -cd bpfman/bpfman-operator/ +cd bpfman-operator/ make generate ``` @@ -203,14 +211,14 @@ During development, it may be quicker to find and fix build errors by just build To build the code: ```bash -cd bpfman/bpfman-operator/ +cd bpfman-operator/ make build ``` To build the container images, run the following command: ```bash -cd bpfman/bpfman-operator/ +cd bpfman-operator/ make build-images ``` @@ -234,7 +242,7 @@ launch bpfman in a Kubernetes cluster. To run locally in a Kind cluster with an up to date build simply run: ```bash -cd bpfman/bpfman-operator/ +cd bpfman-operator/ make run-on-kind ``` @@ -243,14 +251,14 @@ The `make run-on-kind` will run the `make build-images` if the images do not exi Then rebuild and load a fresh build run: ```bash -cd bpfman/bpfman-operator/ +cd bpfman-operator/ make build-images make kind-reload-images ``` -Which will rebuild the bpfman-operator, bpfman-agent, and bpfman images and load them into the kind cluster. +Which will rebuild the bpfman-operator and bpfman-agent images, and load them into the kind cluster. -By default, the `make run-on-kind` uses the `quay.io/bpfman/bpfman*` images described above. +By default, the `make run-on-kind` uses the local images described above. The container images used for `bpfman`, `bpfman-agent`, and `bpfman-operator` can also be manually configured: ```bash diff --git a/docs/developer-guide/image-build.md b/docs/developer-guide/image-build.md index a7ec87d7e..c6e22831d 100644 --- a/docs/developer-guide/image-build.md +++ b/docs/developer-guide/image-build.md @@ -1,8 +1,9 @@ # bpfman Container Images Container images for `bpfman` are automatically built and pushed to `quay.io/` under the -`:latest` tag whenever code is merged into the `main` branch of the `github.com/bpfman/bpfman` -and `github.com/bpfman/bpfman-operator` repositories. +`:latest` tag whenever code is merged into the `main` branch of the +[bpfman](https://github.com/bpfman/bpfman) and [bpfman-operator](https://github.com/bpfman/bpfman-operator) +repositories. * [quay.io/bpfman](https://quay.io/organization/bpfman): This repository contains images needed to run bpfman. @@ -45,7 +46,7 @@ to the bpfman-operator or bpfman-agent container images. The local Makefile will build and load both images based on the current changes: ```sh -cd $HOME/src/bpfman-operator/ +cd bpfman-operator/ make build-images make run-on-kind @@ -59,7 +60,7 @@ By default, bpfman-agent uses `quay.io/bpfman/bpfman:latest`. To build the bpfman binaries in a container image, run: ```sh -cd $HOME/src/bpfman/ +cd bpfman/ docker build -f ./Containerfile.bpfman.local . -t quay.io/$QUAY_USER/bpfman:test ``` @@ -69,7 +70,7 @@ Next, build and deploy the bpfman-operator and bpfman-agent with the locally bui image. ```sh -cd $HOME/src/bpfman-operator/ +cd bpfman-operator/ BPFMAN_IMG=quay.io/$QUAY_USER/bpfman:test make build-images BPFMAN_IMG=quay.io/$QUAY_USER/bpfman:test make run-on-kind @@ -77,13 +78,14 @@ BPFMAN_IMG=quay.io/$QUAY_USER/bpfman:test make run-on-kind To use, the Kind cluster must have access to the image. So either the image needs to be pushed to a registry and made public (make -public via the repo GUI after the push): +public via the repo GUI after the push) before executing the `make run-on-kind` +command shown above: ```sh docker push quay.io/$QUAY_USER/bpfman:test ``` -OR load into kind cluster: +OR it can be loaded into the kind cluster after the cluster is running: ```sh kind load docker-image quay.io/$QUAY_USER/bpfman:test --name bpfman-deployment @@ -142,8 +144,8 @@ bpfman image build -f Containerfile.bytecode.multi.arch -t quay.io/$QUAY_USER/tc bpfman image build -f Containerfile.bytecode.multi.arch -t quay.io/$QUAY_USER/xdp-dispatcher:test -c .output/xdp_dispatcher_v2.bpf/ ``` -!!! NOTE - To build images for multiple architectures on a local system, docker may need additional configuration +!!! Note + To build images for multiple architectures on a local system, docker (or podman) may need additional configuration settings to allow for caching of non-native images. See [https://docs.docker.com/build/building/multi-platform/](https://docs.docker.com/build/building/multi-platform/) for more details. @@ -208,8 +210,8 @@ $ make build-bc-xdp USER_BC=$QUAY_USER TAG_BC=test-bc PLATFORM=linux/amd64,linux => pushing quay.io/$QUAY_USER/go-xdp-counter:test-bc with docker ``` -!!! NOTE - To build images for multiple architectures on a local system, docker may need additional configuration +!!! Note + To build images for multiple architectures on a local system, docker (or podman) may need additional configuration settings to allow for caching of non-native images. See [https://docs.docker.com/build/building/multi-platform/](https://docs.docker.com/build/building/multi-platform/) for more details. @@ -220,7 +222,7 @@ If an example userspace container image needs to be built locally, use the follo build the userspace container images, (optionally passing the `USER_US` and `TAG_US` for the image): ```sh -cd ~/src/bpfman/examples/ +cd bpfman/examples/ # Build all images $ make build-us-images USER_US=$QUAY_USER TAG_US=test-us @@ -248,8 +250,8 @@ $ make build-us-xdp USER_US=$QUAY_USER TAG_US=test-us PLATFORM=linux/amd64,linux => pushing quay.io/$QUAY_USER/go-xdp-counter:test-us with docker ``` -!!! NOTE - To build images for multiple architectures on a local system, docker may need additional configuration +!!! Note + To build images for multiple architectures on a local system, docker (or podman) may need additional configuration settings to allow for caching of non-native images. See [https://docs.docker.com/build/building/multi-platform/](https://docs.docker.com/build/building/multi-platform/) for more details. @@ -270,7 +272,7 @@ integration tests, several steps need to be performed. ## Signing Container Images -It is encouraged to sign the eBPF container images, which can easily be done using +Signing eBPF container images is encouraged and can be easily done using [cosign](https://docs.sigstore.dev/signing/quickstart/). Below is a summary of the steps needed to sign an image. @@ -282,7 +284,7 @@ go install github.com/sigstore/cosign/v2/cmd/cosign@latest Then sign the image. The `cosign` command will generate a URL. -Follow the URL to a `sigstore` login and login with either GitHub, Google to Microsoft. +Follow the `sigstore` URL and login with either GitHub, Google to Microsoft. That will generate a verification code that will complete the `cosign` command. ```console diff --git a/docs/developer-guide/testing.md b/docs/developer-guide/testing.md index e0ac9be91..e47f0b312 100644 --- a/docs/developer-guide/testing.md +++ b/docs/developer-guide/testing.md @@ -10,7 +10,8 @@ Unit testing is executed as part of the `build` job by running the following command in the top-level bpfman directory. ``` - cargo test +cd bpfman/ +cargo test ``` ## Go Example Tests @@ -25,6 +26,7 @@ The full set of basic integration tests are executed by running the following command in the top-level bpfman directory. ```bash +cd bpfman/ cargo xtask integration-test ``` @@ -72,17 +74,7 @@ the eBPF test programs can be found in the `tests/integration-test/bpf` directory. These programs are compiled by executing `cargo xtask build-ebpf --libbpf-dir ` -We also load some tests from local files to test the `load-from-file` option. - -The `bpf` directory also contains a script called `build_push_images.sh` that -can be used to build and push new images to quay if the code is changed. -Images get pushed automatically when code gets merged, however, it's still -useful to be able to push them manually sometimes. For example, when a new test -case requires that both the eBPF and integration code be changed together. It -is also a useful template for new eBPF test code that needs to be pushed. -However, as a word of caution, be aware that existing integration tests will -start using the new programs immediately, so this should only be done if the -modified program is backward compatible. +We also load some tests from local files to test the `bpfman load file` option. ## Kubernetes Operator Tests @@ -91,42 +83,49 @@ modified program is backward compatible. To run all of the unit tests defined in the bpfman-operator controller code run `make test` in the bpfman-operator directory. +```bash +cd bpfman-operator/ +make test +``` + ### Kubernetes Operator Integration Tests To run the Kubernetes Operator integration tests locally: 1. Build the example test code userspace images locally. -```bash - # in bpfman/examples + ```bash + cd bpfman/examples/ make build-us-images -``` + ``` 2. (optional) build the bytecode images - In order to rebuild all of the bytecode images for a PR, ask a maintainer to do so, - they will be built and generate by github actions with the tag - `quay.io/bpfman-bytecode/:` + In order to rebuild all of the bytecode images for a PR, ask a maintainer to do so, + they will be built and generate by github actions with the tag + `quay.io/bpfman-bytecode/:` -3. Build the bpfman images locally with the `int-test` tag. +3. Build the bpfman images locally with a unique tag, for example: `int-test` -```bash - # in bpfman/bpfman-operator - BPFMAN_AGENT_IMG=quay.io/bpfman/bpfman-agent:int-test BPFMAN_IMG=quay.io/bpfman/bpfman:int-test BPFMAN_OPERATOR_IMG=quay.io/bpfman/bpfman-operator:int-test make build-images -``` + ```bash + cd bpfman-operator/ + BPFMAN_AGENT_IMG=quay.io/bpfman/bpfman-agent:int-test BPFMAN_OPERATOR_IMG=quay.io/bpfman/bpfman-operator:int-test make build-images + ``` -4. Run the integration test suite. +4. Run the integration test suite with the images from the previous step: -```bash - # in bpfman/bpfman-operator - BPFMAN_AGENT_IMG=quay.io/bpfman/bpfman-agent:int-test BPFMAN_IMG=quay.io/bpfman/bpfman:int-test BPFMAN_OPERATOR_IMG=quay.io/bpfman/bpfman-operator:int-test make test-integration -``` + ```bash + cd bpfman-operator/ + BPFMAN_AGENT_IMG=quay.io/bpfman/bpfman-agent:int-test BPFMAN_OPERATOR_IMG=quay.io/bpfman/bpfman-operator:int-test make test-integration + ``` -Additionally the integration test can be configured with the following environment variables: + If an update `bpfman` image is required, build it separately and pass to `make test-integration` using `BPFMAN_IMG`. + See [Locally Build bpfman Container Image](./image-build.md#locally-build-bpfman-container-image). -* **KEEP_TEST_CLUSTER**: If set to `true` the test cluster will not be torn down - after the integration test suite completes. -* **USE_EXISTING_KIND_CLUSTER**: If this is set to the name of the existing kind - cluster the integration test suite will use that cluster instead of creating a - new one. + Additionally the integration test can be configured with the following environment variables: + * **KEEP_TEST_CLUSTER**: If set to `true` the test cluster will not be torn down + after the integration test suite completes. + * **USE_EXISTING_KIND_CLUSTER**: If this is set to the name of the existing kind + cluster the integration test suite will use that cluster instead of creating a + new one. diff --git a/docs/developer-guide/xdp-overview.md b/docs/developer-guide/xdp-overview.md index 158bdf0e4..e7fab0c5f 100644 --- a/docs/developer-guide/xdp-overview.md +++ b/docs/developer-guide/xdp-overview.md @@ -17,7 +17,7 @@ XDP programs on a given interface. This tutorial will show you how to use `bpfman` to load multiple XDP programs on an interface. -!!! Note: +!!! Note The TC hook point is also associated with an interface. Within bpfman, TC is implemented in a similar fashion to XDP in that it uses a dispatcher with stub functions. diff --git a/docs/getting-started/building-bpfman.md b/docs/getting-started/building-bpfman.md index 13f16228e..f1e81c928 100644 --- a/docs/getting-started/building-bpfman.md +++ b/docs/getting-started/building-bpfman.md @@ -36,7 +36,7 @@ Major kernel features leveraged by bpfman: * **Relaxed CAP_BPF Requirement:** Prior to Kernel 5.19, all eBPF system calls required CAP_BPF. This required userspace programs that wanted to access eBPF maps to have the CAP_BPF Linux capability. With the kernel 5.19 change, CAP_BPF is only required for load and unload requests. -* **TCX:** TCX support was added in Kernel 6.6, and added to bpfman in v0.5.2. +* **TCX:** TCX support was added in Kernel 6.6 and is expected to be added to bpfman in v0.5.2. TCX has performance improvements over TC and adds support in the kernel for multiple TCX programs to run on a given TC hook point. @@ -188,7 +188,7 @@ See [kind](https://kind.sigs.k8s.io/) for documentation and installation instruc ([kubernetes/kubernetes#112597](https://github.com/kubernetes/kubernetes/pull/112597)) that addresses a gRPC Protocol Error that was seen in the CSI client code and it doesn't appear to have been backported. - It is recommended to install kind v0.20.0 or later. + kind v0.20.0 or later is recommended. If the following error is seen, it means there is an older version of Kubernetes running and it needs to be upgraded. @@ -276,8 +276,8 @@ taplo fmt --check ## Clone the bpfman and bpfman-operator Repositories You can build and run bpfman from anywhere. -For simplicity throughout this documentation, all examples will assume -`$HOME/src/bpfman/` and `$HOME/src/bpfman-operator/`. +For simplicity throughout this documentation, all examples will reference +`bpfman/` and `bpfman-operator/` to indicate which repository is being used. bpfman-operator only needs to be cloned if deploying in Kubernetes. ``` @@ -292,7 +292,7 @@ git clone https://github.com/bpfman/bpfman-operator.git If you are building bpfman for the first time OR the eBPF code has changed: ```console -cd ~/src/bpfman/ +cd bpfman/ cargo xtask build-ebpf --libbpf-dir /path/to/libbpf ``` @@ -314,7 +314,7 @@ cargo build Optionally, to build the CLI TAB completion files, run the following command: ```console -cd ~/src/bpfman/ +cd bpfman/ cargo xtask build-completion ``` @@ -354,7 +354,7 @@ For these shells, generated file must be manually installed. Optionally, to build the CLI Manpage files, run the following command: ```console -cd ~/src/bpfman/ +cd bpfman/ cargo xtask build-man-page ``` @@ -374,7 +374,7 @@ Once installed, use `man` to view the pages. man bpfman list ``` -!!! NOTE +!!! Note `bpfman` commands with subcommands (specifically `bpfman load`) have `-` in the manpage subcommand generation. So use `man bpfman load-file`, `man bpfman load-image`, `man bpfman load-image-xdp`, diff --git a/docs/getting-started/cli-guide.md b/docs/getting-started/cli-guide.md index 6f717ed53..eed8a66ac 100644 --- a/docs/getting-started/cli-guide.md +++ b/docs/getting-started/cli-guide.md @@ -213,7 +213,8 @@ Options: Example loading from local file (`--path` is the fully qualified path): ```console -sudo bpfman load file --path $HOME/src/bpfman/tests/integration-test/bpf/.output/xdp_pass.bpf.o --name "pass" xdp --iface eno3 --priority 100 +cd bpfman/ +sudo bpfman load file --path tests/integration-test/bpf/.output/xdp_pass.bpf.o --name "pass" xdp --iface eno3 --priority 100 ``` Example from image in remote repository: @@ -260,7 +261,8 @@ Options: The following is an example of the `tc` command using short option names: ```console -sudo bpfman load file -p $HOME/src/bpfman/tests/integration-test/bpf/.output/tc_pass.bpf.o -n "pass" tc -d ingress -i mynet1 -p 40 +cd bpfman/ +sudo bpfman load file -p tests/integration-test/bpf/.output/tc_pass.bpf.o -n "pass" tc -d ingress -i mynet1 -p 40 ``` For the `tc_pass.bpf.o` program loaded with the command above, the name @@ -305,7 +307,8 @@ sudo bpfman load image --image-url quay.io/bpfman-bytecode/kretprobe:latest --na #### TC ```console -sudo bpfman load file --path $HOME/src/bpfman/examples/go-tc-counter/bpf_x86_bpfel.o --name "stats" tc --direction ingress --iface eno3 --priority 110 +cd bpfman/ +sudo bpfman load file --path examples/go-tc-counter/bpf_x86_bpfel.o --name "stats" tc --direction ingress --iface eno3 --priority 110 ``` #### Uprobe @@ -323,7 +326,8 @@ sudo bpfman load image --image-url quay.io/bpfman-bytecode/uretprobe:latest --na #### XDP ```console -sudo bpfman load file --path $HOME/src/bpfman/examples/go-xdp-counter/bpf_x86_bpfel.o --name "xdp_stats" xdp --iface eno3 --priority 35 +cd bpfman/ +sudo bpfman load file --path bpfman/examples/go-xdp-counter/bpf_x86_bpfel.o --name "xdp_stats" xdp --iface eno3 --priority 35 ``` ### Setting Global Variables in eBPF Programs @@ -331,10 +335,11 @@ sudo bpfman load file --path $HOME/src/bpfman/examples/go-xdp-counter/bpf_x86_bp Global variables can be set for any eBPF program type when loading as follows: ```console -sudo bpfman load file -p $HOME/src/bpfman/tests/integration-test/bpf/.output/tc_pass.bpf.o -g GLOBAL_u8=01 GLOBAL_u32=0A0B0C0D -n "pass" tc -d ingress -i mynet1 -p 40 +cd bpfman/ +sudo bpfman load file -p bpfman/tests/integration-test/bpf/.output/tc_pass.bpf.o -g GLOBAL_u8=01 GLOBAL_u32=0A0B0C0D -n "pass" tc -d ingress -i mynet1 -p 40 ``` -Note, that when setting global variables, the eBPF program being loaded must +Note that when setting global variables, the eBPF program being loaded must have global variables named with the strings given, and the size of the value provided must match the size of the given variable. For example, the above command can be used to update the following global variables in an eBPF program. @@ -354,12 +359,13 @@ program's return value. For example, the default `proceed-on` configuration for an `xdp` program can be modified as follows: ```console -sudo bpfman load file -p $HOME/src/bpfman/tests/integration-test/bpf/.output/xdp_pass.bpf.o -n "pass" xdp -i mynet1 -p 30 --proceed-on drop pass dispatcher_return +cd bpfman/ +sudo bpfman load file -p tests/integration-test/bpf/.output/xdp_pass.bpf.o -n "pass" xdp -i mynet1 -p 30 --proceed-on drop pass dispatcher_return ``` ### Sharing Maps Between eBPF Programs -!!! WARNING +!!! Warning Currently for the map sharing feature to work the LIBBPF_PIN_BY_NAME flag **MUST** be set in the shared bpf map definitions. Please see [this aya issue](https://github.com/aya-rs/aya/issues/837) for future work that will @@ -370,7 +376,8 @@ maps. One eBPF program must own the maps. ```console -sudo bpfman load file --path $HOME/src/bpfman/examples/go-xdp-counter/bpf_x86_bpfel.o -n "xdp_stats" xdp --iface eno3 --priority 100 +cd bpfman/ +sudo bpfman load file --path examples/go-xdp-counter/bpf_x86_bpfel.o -n "xdp_stats" xdp --iface eno3 --priority 100 6371 ``` @@ -379,7 +386,8 @@ the program id of the eBPF program that owns the maps using the `--map-owner-id` parameter: ```console -sudo bpfman load file --path $HOME/src/bpfman/examples/go-xdp-counter/bpf_x86_bpfel.o -n "xdp_stats" --map-owner-id 6371 xdp --iface eno3 --priority 100 +cd bpfman/ +sudo bpfman load file --path examples/go-xdp-counter/bpf_x86_bpfel.o -n "xdp_stats" --map-owner-id 6371 xdp --iface eno3 --priority 100 6373 ``` @@ -794,6 +802,12 @@ Example of directory with Cilium generated bytecode objects: bpfman image build -f Containerfile.bytecode.multi.arch -t quay.io/$QUAY_USER/go-xdp-counter:test -c ./examples/go-xdp-counter/ ``` +!!! Note + To build images for multiple architectures on a local system, docker (or podman) may need additional configuration + settings to allow for caching of non-native images. See + [https://docs.docker.com/build/building/multi-platform/](https://docs.docker.com/build/building/multi-platform/) + for more details. + ### bpfman image generate-build-args The `bpfman image generate-build-args` command is a utility command that generates the labels used diff --git a/docs/getting-started/example-bpf-local.md b/docs/getting-started/example-bpf-local.md index 6aa902a49..4d6c51b69 100644 --- a/docs/getting-started/example-bpf-local.md +++ b/docs/getting-started/example-bpf-local.md @@ -50,10 +50,10 @@ The output should show the count and total bytes of packets as they pass through interface as shown below: ```console -cd ~/src/bpfman/examples/go-xdp-counter/ +cd bpfman/examples/go-xdp-counter/ go run -exec sudo . --iface eno3 -2023/07/17 17:43:58 Using Input: Interface=eno3 Priority=50 Source=/home/<$USER>/src/bpfman/examples/go-xdp-counter/bpf_bpfel.o +2023/07/17 17:43:58 Using Input: Interface=eno3 Priority=50 Source=/home/$USER/src/bpfman/examples/go-xdp-counter/bpf_bpfel.o 2023/07/17 17:43:58 Program registered with id 6211 2023/07/17 17:44:01 4 packets received 2023/07/17 17:44:01 580 bytes received diff --git a/docs/getting-started/launching-bpfman.md b/docs/getting-started/launching-bpfman.md index 6a9d54614..ff5a0234f 100644 --- a/docs/getting-started/launching-bpfman.md +++ b/docs/getting-started/launching-bpfman.md @@ -52,7 +52,7 @@ sudo RUST_LOG=info bpfman list ``` The examples (see [Deploying Example eBPF Programs On Local Host](./example-bpf-local.md)) -are Go based programs, so they are building and sending RPC messaged to the rust based binary +are Go based programs, so they are building and sending RPC messages to the rust based binary `bpfman-rpc`, which in turn calls the `bpfman` library. ```console diff --git a/docs/getting-started/running-rpm.md b/docs/getting-started/running-rpm.md index 7465b9129..d68cf5eab 100644 --- a/docs/getting-started/running-rpm.md +++ b/docs/getting-started/running-rpm.md @@ -36,8 +36,10 @@ sudo dnf copr enable @ebpf-sig/bpfman-next ``` !!! Note - If both the bpfman and bpfman-next copr repos are enabled DNF will - automatically pull from bpfman-next. To disable one or the other simply run + If both the `bpfman` and `bpfman-next` copr repos are enabled, `dnf` will + automatically pull from `bpfman-next`. + Either repo can be disabled. + For example, to disable `bpfman-next` run: ```console sudo dnf copr disable @ebpf-sig/bpfman-next