[P4-dev] Is metadata considered in deparsing?

Javier Blazquez jblazquez at riotgames.com
Mon Jun 20 21:19:07 EDT 2016

Thanks Antonin. I have a few questions about the topological sort you

As you say, if a packet may have header A followed by header B _or_ header
B followed by header A then the static parser graph does indeed have
multiple topological sortings. However, when an actual packet flows through
the pipeline this packet will have only one of the two orderings, hence it
should be possible to reconstruct those headers in the right order.

I assume the issue is that the P4 compiler currently builds its deparser
from a static view of the parse graph, and it therefore can't modify its
behavior at runtime depending on how the input packet looked like? If the
deparser knew which `extract` calls were made in which order then it could
reconstruct the packet correctly in those situations.

What about calls to `add_header`/`push`/etc? Those calls don't appear in
parsers, so how does the deparser find those headers when it reconstructs
the output packet? I assume it visits every single header in the P4 program
and checks its valid bit, and if so writes out the header. If that's the
case, which ordering does it choose for those headers that have been pushed
or added in compound actions? Do they all go after the regular headers that
were extracted in a parser?

On Mon, Jun 20, 2016 at 4:50 PM, Antonin Bas <antonin at barefootnetworks.com>

> Hi,
> As Javier say, the deparser behavior is not rigorously specified in P4
> v1.1, which hopefully should change in the next version of the language. As
> I explained in this previous email to the mailing list (
> http://lists.p4.org/pipermail/p4-dev_lists.p4.org/2016-May/000319.html),
> the P4 compiler uses a topological sorting on the parse graph to determine
> the deparsing behavior. The deparser then follows this ordering and emits
> headers for which the validity bit is set.
> This can make things tricky / ambiguous because a topological sorting is
> not always unique. Furthermore, in some cases, you may wish to emit packets
> (e.g. CPU packets) which the parser may not need to know about. In this
> case, you may have no choice but to add dummy transitions to your parse
> graph. See the copy_to_cpu program in the tutorials repository for an
> example:
> https://github.com/p4lang/tutorials/blob/master/examples/copy_to_cpu/p4src/copy_to_cpu.p4#L45
> In your case, you have no choice but to make appropriate calls to
> add_header / remove_header to mark headers as valid / invalid. Maybe future
> P4 versions will let us program the deparser in a more structured way.
> Best,
> Antonin
> On Mon, Jun 20, 2016 at 4:22 PM, Javier Blazquez <jblazquez at riotgames.com>
> wrote:
>> I think of deparsing as simply the reversal of the parsing process, that
>> is, going through whatever `extract` operations have been executed and
>> copying those headers back from the Parsed Representation into the packet
>> for transmission.
>> In that scenario the use of metadata to switch among parsers shouldn't
>> change things because all that matters is what `extract` operations have
>> been performed on actual headers and in which order. Remember that metadata
>> is by definition not part of the actual packet on the wire so whatever
>> values your metadata headers have shouldn't matter when it comes to
>> assembling the packet for transmission.
>> However, an interesting side question that comes to mind is regarding the
>> `push`, `pop`, `add_header` and `remove_header` primitive actions. These
>> are not used during the parsing phase; they're used as part of compound
>> actions in the ingress or egress pipeline, but they affect the packet that
>> will be assembled for transmission.
>> So deparsing isn't _just_ the reversal of the parsing process, but also
>> the addition/removal of headers as per those primitives above? In which
>> case, does the order of headers in the transmitted packet follow the order
>> in which push/add_header/etc have executed for a given packet? And
>> regarding header stacks, I assume they're always serialized as a single
>> block (i.e. all valid headers in the stack following each other)? The 1.1
>> spec doesn't seem to specify the order in which headers will be serialized
>> to the output packet.
>> On Mon, Jun 20, 2016 at 3:01 PM, Huynhtu Dang <huynh.tu.dang at usi.ch>
>> wrote:
>>> Dear all,
>>> I wonder if metadata is considered in deparsing phase? As I set the
>>> value of metadata in an action and use this metadata value to switch among
>>> parsers. But it seems the deparser skips checking the value of metadata or
>>> the value of metadata is reset before deparsing.
>>> Best,
>>> Tu Dang
>>> _______________________________________________
>>> P4-dev mailing list
>>> P4-dev at lists.p4.org
>>> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org
>> _______________________________________________
>> P4-dev mailing list
>> P4-dev at lists.p4.org
>> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org
> --
> Antonin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20160620/3fe91dd4/attachment-0002.html>

More information about the P4-dev mailing list