Enable variable-width extraction for the TC backend #4695
Conversation
vbnogueira
force-pushed
the
varbit_extract_support
branch
from
5231a9e
to
f391d31
Compare
Enable variable-width extraction for the TC backend However note that it still doesn't add varbit support for the deparser
vbnogueira
force-pushed
the
varbit_extract_support
branch
2 times, most recently
from
511bab5
to
3e4fd20
Compare
Added testcase crafted by mouse |
There was a problem hiding this comment.
Code changes are done in common ebpf code, Do we need to do these changes explicitly for tc backend? or applicable to ebpf backend as well? If the changes are only for tc backend, then changes have to be done in different way by creating tc specific children classes
| @@ -0,0 +1,159 @@ | |||
| /* -*- P4_16 -*- */ | |||
There was a problem hiding this comment.
Please add this testcase to the CMakelist in backends/tc folder and generate output files from compiler and place them
There was a problem hiding this comment.
As per your suggestion, modified simple_exact_example.p4 instead of creating a new test case so that the diff is easier to see
Modify simple_exact_example to parse ipv4 options Intent is to make it easier for reviewers to understand the changes added by the previous commit
vbnogueira
force-pushed
the
varbit_extract_support
branch
from
3e4fd20
to
c620194
Compare
Any updates on this point? |
| unsigned alignment = hdrOffsetBits % 8; | ||
| unsigned widthToExtract = type->as<IHasWidth>().widthInBits(); | ||
| auto program = state->parser->program; | ||
| cstring msgStr; | ||
| cstring fieldName = field->name.name; | ||
|
|
||
| builder->appendFormat("/* EBPF::StateTranslationVisitor::compileExtractField: field %s", |
There was a problem hiding this comment.
These are additional comments generated in the code. Do we really need this change in the code?
Not yet, I forwarded your comments to mouse |
Enable variable-width extraction for the TC backend.
However note that it still doesn't add varbit support for the deparser, only for the parser