BMV2 multi-architecture support #544
Conversation
- Comments on how to handle the semantics of multiple PRE invocations - and design option of splitting the PRE into PRE and BQE (Buffering and Queueing Engine) - added PRE as argument to Ingress and Egress - added missing 'in' qualifiers and random distribution - add size types instead of indefinite int - update with @mbudiu-vmw comments to pass through compiler - ActionProfile and ActionSelector externs
This commit refactors bmv2 backend to support multiple pipelien
architectures. JsonConverter is refactored into a pass manager
which is more conformed to the rest of the compiler design.
Added files:
backend.cpp - the new backend pass manager
convert*.cpp - compiler passes for control, parser, deparser,
externs and headers
inferArchitecture - a new frontend pass to parse the architecture p4
into a data object which is then used by json
generator
model.cpp - a v2model that oriented for p4-16 IR
TODO:
tov1model - a pass to convert v2model to v1model to execute
on simple-switch
There was a problem hiding this comment.
@hanw This is a monster of a commit! I've tried to go through it and I kind of got the gist. However, there are several issues that will be much easier to sort out if we sit together, and will really help focus the review. It is also difficult to track new changes from the old jsonConverter since the code is now in different files.
I have to say that I'm happy you were able to get it here, we'll wrap it up in the next few days. THANKS!
|
|
||
| namespace BMV2 { | ||
|
|
||
| class DirectMeterMap final { |
There was a problem hiding this comment.
Why is this class needed for DirectMeters from all the externs?
There was a problem hiding this comment.
That does seem odd -- this class seems to be tracking the (color) output, but that should also be needed for meters and registers, which also have destination fields that are written by the extern.
There was a problem hiding this comment.
Yeah, this is odd. This is the last piece that needs to be taken out of jsonconverter.cpp (which is now backend.cpp). Will separate it to its own file.
| void setSize(const IR::IDeclaration* meter, unsigned size); | ||
| }; | ||
|
|
||
| class Backend { |
| }; | ||
|
|
||
| /// Method_Model : Block_Model<Param_Model> : Type_Model | ||
| struct Method_Model : public Block_Model<Param_Model> { |
There was a problem hiding this comment.
Are the parameters to the method defined as the elems in Block_Model? Is there ever the case that we need to distinguish between constructor params and data plane params?
| }; | ||
|
|
||
| /// Extern_Model : Block_Model<Method_Model> : Type_Model | ||
| struct Extern_Model : public Block_Model<Method_Model> { |
There was a problem hiding this comment.
How do you distinguish between decls and methods in an extern? Can externs have only Methods?
| std::vector<Control_Model*> controls; | ||
| std::vector<Extern_Model*> externs; | ||
| std::vector<Type_Model*> match_kinds; | ||
| ::Model::Elem action_profile; |
| @@ -114,7 +116,8 @@ common_frontend_UNIFIED = \ | |||
| frontends/common/resolveReferences/referenceMap.cpp \ | |||
| frontends/common/resolveReferences/resolveReferences.cpp \ | |||
| frontends/common/parseInput.cpp \ | |||
| frontends/common/constantParsing.cpp | |||
| frontends/common/constantParsing.cpp \ | |||
There was a problem hiding this comment.
we should really keep these files in alphabetical order to reduce merge conflicts.
|
|
||
| #include "frontends/common/model.h" | ||
|
|
||
| /// take v2model and turn it into v1model |
There was a problem hiding this comment.
Do we really need to convert the model? I would have thought that we can serialize v2 to the json from the v1model.
|
Close temporarily for now to reducing spam to people. Will reopen later. |
[do NOT merge yet]
Bmv2 multi-architecture support