[P4-dev] Is metadata considered in deparsing?

Shouxi Luo rithmns at gmail.com
Tue Jun 21 05:34:10 EDT 2016

Hi Antonin,

Would P4 support header and metadata unions in the future (like C/C++)?


On Tue, Jun 21, 2016 at 1:51 AM 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
> _______________________________________________
> P4-dev mailing list
> P4-dev at lists.p4.org
> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20160621/de64f2b3/attachment-0002.html>

More information about the P4-dev mailing list