-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Add attach_xdp to reference_guide.md #3450
Conversation
[buildbot, test this please] |
Based on the kernel code, I think this is not true. But if you have a XDP_FLAGS_REPLACE, you will be able to do that.
xdp itself is a pretty big topic. We have https://github.com/xdp-project and https://docs.cilium.io/en/stable/bpf/ has much more information about xdp and some of them uses iproute2 though. For bcc's perspecitve, I think you current version is a good first step. If you can dig into a little bit more and explain default and available flags, that will be great. You can refer to the flag definitions in src/python/bcc/init.py.
|
Hi, @yonghong-song Thanks for replying.
I see. Thank you very much. But I can't find those flags definition in |
Hi @masibw This feature is already supported in #3447. This is my personal understanding and I don't know if it helps you. 1. XDP_FLAGS_UPDATE_IF_NOEXISTIf an XDP program is already attached to the specified driver, attaching the XDP program again will fail. 2. XDP_FLAGS_SKB_MODEDriver doesn’t have support for XDP, but the kernel fakes it. XDP program works, but there’s no real performance benefit because packets are handed to kernel stack anyways which then emulates XDP – this is usually supported with generic network drivers used in home computers, laptops, and virtualized HW. 3. XDP_FLAGS_DRV_MODEDriver has XDP support and can hand then to XDP without kernel stack interaction – Few drivers can support it and those are usually for enterprise HW. 4. XDP_FLAGS_HW_MODEXDP can be loaded and executed directly on the NIC – just a handful of NICs can do that. 5. XDP_FLAGS_REPLACEProvides a mechanism to safely replace one particular XDP program with another. |
Hi @chenyuezhou, Thanks for the comments. Would you mind if I use your description in this PR? |
Never mind. It's okay. BTW. Maybe you can come up with a better description. https://pantheon.tech/what-is-af_xdp/ This article summarizes three modes of XDP. ( you can find the describe of Hope this helps you. |
Thank you @chenyuezhou I read both posts. Then I have a question about the bcc's behaviour.
But flags started from 1. What is the default behaviour? Maybe this is the function that determines behaviour, but I can't understand... |
Hi @masibw bcc is using https://github.com/libbpf/libbpf. This is a mirror of bpf-next Linux source tree's As you said, bcc does call In my current kernel version (5.10.35), the default value of flags is 0 if flags is not set in
struct nlattr *xdp[IFLA_XDP_MAX + 1];
u32 xdp_flags = 0;
...
if (xdp[IFLA_XDP_FLAGS]) {
xdp_flags = nla_get_u32(xdp[IFLA_XDP_FLAGS]);
...
}
... There may be different behavior in different kernel versions. |
@masibw Previously I said:
This is not true actually. In early days, kernel internal xdp is not bpf_link based, so you actually can replace a bpf program without flags = 0. But this changed when xdp utilized bpf_link (https://lore.kernel.org/bpf/20200722064603.3350758-5-andriin@fb.com/, bpf command BPF_LINK_CREATE) in which case, you can only replace a bpf program with XDP_FLAGS_REPLACE. Currently, bcc does not use BPF_LINK_CREATE, instead it still uses old netlink based approach, so XDP_FLAGS_REPLACE will not apply. BTW, the current patch has a merge conflict with master branch. Please rebase when you submit your new pull request. |
The default is to replace the old program if there is an old program. |
Thanks, @yonghong-song, @chenyuezhou. I now understand the default behavior and the history of xdp.
So..bcc is using an old netlink based approach, Is it able to use flags? I mean if there is no use writing
Ok, I'll do rebase. |
The documentation can skip XDP_FLAGS_REPLACE for now. Thanks! |
Sorry for my late response. I have described the flag, what do you think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Overall looks good. Added a few comments.
docs/reference_guide.md
Outdated
@@ -1721,6 +1722,55 @@ BPF.attach_raw_socket(bpf_func, ifname) | |||
|
|||
Examples in situ: | |||
[search /examples](https://github.com/iovisor/bcc/search?q=attach_raw_socket+path%3Aexamples+language%3Apython&type=Code) | |||
### 9. attach_xdp() | |||
Syntax: ```BPF.attach_xdp(dev="device", fn=b.load_func("fn_name",BPF_XDP))``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
flags are also supported. BPF.attach_xdp(dev="device", fn=b.load_func("fn_name",BPF_XDP), flags)
docs/reference_guide.md
Outdated
### 9. attach_xdp() | ||
Syntax: ```BPF.attach_xdp(dev="device", fn=b.load_func("fn_name",BPF_XDP))``` | ||
|
||
Instruments the network driver described by ```dev``` , and then receives the packet, run the BPF function ```fn_name()```. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
run the BPF function fn_name()
with flags
.
docs/reference_guide.md
Outdated
|
||
You can use flags like this ```BPF.attach_xdp(dev="device", fn=b.load_func("fn_name",BPF_XDP), flags=BPF.XDP_FLAGS_UPDATE_IF_NOEXIST)``` | ||
|
||
For historical reasons, XDP_FLAGS_REPLACE does not make sense in BCC. The default value of 0 has the same meaning. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The flag 0 means if there is no xdp program with device
, the fn
will run with that device
. If there is an xdp program running with device
, the old program will be replaced with new fn
program.
Currently, bcc does not support XDP_FLAGS_REPLACE flag. The following are the descriptions of other flags.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, then how about this?
For historical reasons, XDP_FLAGS_REPLACE does not make sense in BCC. The default value of 0 has the same meaning. | |
The default value of flgas is 0. This means if there is no xdp program with `device`, the fn will run with that device. If there is an xdp program running with device, the old program will be replaced with new fn program. | |
Currently, bcc does not support XDP_FLAGS_REPLACE flag. The following are the descriptions of other flags. |
docs/reference_guide.md
Outdated
#### 4. XDP_FLAGS_HW_MODE | ||
XDP can be loaded and executed directly on the NIC – just a handful of NICs can do that. | ||
|
||
#### 5. XDP_FLAGS_REPLACE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove this. It can only cause confusion. We can add it later if xdp load part is enhanced with BPF_LINK_CREATE syscall command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All right, thank you.
LGTM. Thanks! |
[buildbot, test this please] |
- Add attach_xdp to reference_guide.md - Add description about flags
Hi all, this PR will resolve #3414.
I wrote the document about
attach_xdp
, but I am a beginner at eBPF and XDP.I am assuming that multiple calls to attach_xdp will overwrite the previous one and not run, is this correct? Is this correct and should I write this?
Can you give me the advice to improve the quality of documents?
Best Regards.