Minimal e2e implementation of packet trace.

[c8ef]

With this patch we will have a minimal and workable implementation of packet trace.

From https://github.com/p4lang/behavioral-model/blob/main/targets/simple_switch/tests/testdata/queueing.json we will get:

input {
}
root {
  events {
    pipeline_stage {
      stage_name: "parser"
      stage_kind: PARSER
      direction: ENTER
    }
  }
  events {
    pipeline_stage {
      stage_name: "parser"
      stage_kind: PARSER
      direction: EXIT
    }
  }
  events {
    pipeline_stage {
      stage_name: "ingress"
      stage_kind: CONTROL
      direction: ENTER
    }
  }
  events {
    pipeline_stage {
      stage_name: "ingress"
      stage_kind: CONTROL
      direction: EXIT
    }
  }
  events {
    pipeline_stage {
      stage_name: "egress"
      stage_kind: CONTROL
      direction: ENTER
    }
  }
  events {
    pipeline_stage {
      stage_name: "egress"
      stage_kind: CONTROL
      direction: EXIT
    }
  }
  events {
    pipeline_stage {
      stage_name: "deparser"
      stage_kind: DEPARSER
      direction: ENTER
    }
  }
  events {
    pipeline_stage {
      stage_name: "deparser"
      stage_kind: DEPARSER
      direction: EXIT
    }
  }
}

[c8ef]

cc @matthewtlam @fruffy @jafingerhut @grg

[fruffy]

How could we test this? E.g., for the compiler we have golden tests to ensure that the output matches our expectations. We could also use gtests and pattern match, but that is harder to maintain and review and might not capture the full picture of a trace.

[c8ef]

How could we test this? E.g., for the compiler we have golden tests to ensure that the output matches our expectations. We could also use gtests and pattern match, but that is harder to maintain and review and might not capture the full picture of a trace.

During development I have a local smoke test script(which generates the trace in the pr description). Though I haven't think very thoroughly on how to test this. Since it is using existing infrastructure I hope we could reuse the existing nanomsg backend testing, but not sure if that exists.

[fruffy]

How could we test this? E.g., for the compiler we have golden tests to ensure that the output matches our expectations. We could also use gtests and pattern match, but that is harder to maintain and review and might not capture the full picture of a trace.

During development I have a local smoke test script(which generates the trace in the pr description). Though I haven't think very thoroughly on how to test this. Since it is using existing infrastructure I hope we could reuse the existing nanomsg backend testing, but not sure if that exists.

Basically you want avoid that this feature slowly bitrots. Ideally, we have infra for E2E tests that run BMv2, generate a trace and then we compare outputs.

[matthewtlam]

@c8ef I think we should be producing golden tests for this and adding appropriate test cases so that we can see if the behavior is as we expect. Ideally, we would iterate over the different P4 pipelines that we have define and send the corresponding input packets through BMv2 and then we output the packet trace in a golden file (.expected file). Since you added the Bazel support, we can do some golden tests. Here are a couple of examples:

This is the corresponding test runner: https://github.com/google/p4-infra/blob/f107159078db6ba189a413d7308f00b4c0d1d9fe/p4_pdpi/references_test_runner.cc

This is a sample expected file: https://github.com/google/p4-infra/blob/f107159078db6ba189a413d7308f00b4c0d1d9fe/p4_pdpi/references.expected

We can also add the golden tests to the Github workflow.