-
Notifications
You must be signed in to change notification settings - Fork 445
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
p4c-ubpf: new uBPF back-end for p4c #2134
Changes from 1 commit
ecd39c0
ec22005
a687110
75fdcf6
2fcdcf8
acfaa6e
99d6854
78335fa
93643c2
118b2b2
884c40a
d57742f
dcf0903
3d64116
9231f53
dbb237e
1090527
c0bc2c5
0df4fa5
5a86d96
b96fcca
b880030
3089cbb
edcbb1d
cfaa628
5cc9931
c63a939
322f5c1
1adffa0
b3eb458
5893f22
0ca94d3
085294b
8ab0e2a
302d279
381d4ee
e4330a8
1fd859e
08b7de0
b8b3f06
e22ad6f
38acee5
c648326
c5c324e
7f0b72e
2b6020c
997d5db
db6c4db
2e12ee3
6bc8674
7ec6f33
2be7ec7
b1479ad
668e808
6ae22e4
cc59b0d
fb07d84
daad335
f5bcc01
89eb992
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -37,7 +37,7 @@ namespace UBPF { | |
void UbpfTarget::emitTableLookup(Util::SourceCodeBuilder *builder, | ||
cstring tblName, | ||
cstring key, | ||
cstring value) const { | ||
UNUSED cstring value) const { | ||
builder->appendFormat("ubpf_map_lookup(&%s, &%s)", | ||
tblName.c_str(), key.c_str()); | ||
} | ||
|
@@ -68,4 +68,41 @@ namespace UBPF { | |
builder->appendFormat("ubpf_packet_data(%s)", ctxVar.c_str()); | ||
} | ||
|
||
void UbpfTarget::emitUbpfHelpers(EBPF::CodeBuilder *builder) const { | ||
builder->append( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this looks a bit brittle. Is there a guarantee that the numbers associated with these functions will never change? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a strict requirement, which is specific to target that we use (P4rt-OVS). Perhaps, it could be generalized in the future, but at the moment the BPF program would not work otherwise. |
||
"static void *(*ubpf_map_lookup)(const void *, const void *) = (void *)1;\n" | ||
"static int (*ubpf_map_update)(void *, const void *, void *) = (void *)2;\n" | ||
"static int (*ubpf_map_delete)(void *, const void *) = (void *)3;\n" | ||
"static int (*ubpf_map_add)(void *, const void *) = (void *)4;\n" | ||
"static uint64_t (*ubpf_time_get_ns)() = (void *)5;\n" | ||
"static uint32_t (*ubpf_hash)(const void *, uint64_t) = (void *)6;\n" | ||
"static void (*ubpf_printf)(const char *fmt, ...) = (void *)7;\n" | ||
"static void *(*ubpf_packet_data)(const void *) = (void *)9;\n" | ||
"static void *(*ubpf_adjust_head)(const void *, uint64_t) = (void *)8;\n" | ||
"\n"); | ||
builder->newline(); | ||
builder->appendLine( | ||
"#define write_partial(a, w, s, v) do { *((uint8_t*)a) = ((*((uint8_t*)a)) " | ||
"& ~(BPF_MASK(uint8_t, w) << s)) | (v << s) ; } while (0)"); | ||
builder->appendLine("#define write_byte(base, offset, v) do { " | ||
"*(uint8_t*)((base) + (offset)) = (v); " | ||
"} while (0)"); | ||
builder->newline(); | ||
builder->append("static uint32_t\n" | ||
"bpf_htonl(uint32_t val) {\n" | ||
" return htonl(val);\n" | ||
"}"); | ||
builder->newline(); | ||
builder->append("static uint16_t\n" | ||
"bpf_htons(uint16_t val) {\n" | ||
" return htons(val);\n" | ||
"}"); | ||
builder->newline(); | ||
builder->append("static uint64_t\n" | ||
"bpf_htonll(uint64_t val) {\n" | ||
" return htonll(val);\n" | ||
"}\n"); | ||
builder->newline(); | ||
} | ||
|
||
} |
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.
I would suggest documenting these functions.
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.
In particular, for mark_to_drop() and mark_to_pass(), what is the default behavior after a packet is done processing? Probably pass?
Then if the P4 program does mark_to_drop() and/or mark_to_pass() calls, whichever one was last determines whether the packet is passed or dropped later?
And there are no user-visible P4 variables that are modified by mark_to_drop() or mark_to_pass()? I would not ask, except this was an issue for several years with v1model's mark_to_drop(), and why it was changed to take a parameter later. It appears you have nothing that corresponds to standard_metadata, so it would make sense if in your architecture, mark_to_drop() and mark_to_pass() only modify state "hidden from the user's P4 program" inside the architecture implementation.
Another good thing to document about these extern functions is which of the architecture's parsers/controls they are allowed to be called in, e.g. maybe you intended something like "mark_to_drop() and mark_to_pass() may only be called in the filter control".
Comments in the p4include/v1model.p4 file would be good to look at for examples. If any of them happen to match the behavior you provide (e.g. that might be true for your Register extern compared to v1model's register extern), feel free to copy and paste whatever is accurate for your architecture.