[P4-dev] Intrinsic metadata and some other questions

Antonin Bas antonin at barefootnetworks.com
Tue Jun 16 13:10:35 EDT 2015

I just realized that I hit reply instead of reply-all when I answered a few
days ago. Here was my answer to Sandor:


Hi Sandor,

Please see answer inline:

On Fri, Jun 12, 2015 at 5:24 AM, Sandor Laki <lakis at elte.hu> wrote:

> Dear Antonin, All,
> If I understand correctly, non-standard intrinsic metadata is always
> target specific. Is there any description on how this kind of metadata can
> be used with the current p4 compiler?
> For example in l2_switch target there is an intrinsic_matadata_t with four
> fields. For example, if field lf_field_list is removed from the definition,
> the compiler crashes. However, in the p4 program this field is not modified
> or read at all. So, the question is if it is a bug or a normal behavior
> (meaning that the intrinsic metadata definition is determined by the target
> and cannot be changed by the developer). I think this problem is mostly
> related to l2 programs using core functionalities of the underlying
> hardware.

Yes this metadata is target specific. The behavioral model assumes the
existence of certain intrinsic metadata fields in order to support some
features. In the l2_switch program, the metadata is defined as:

header_type intrinsic_metadata_t {
    fields {
        eg_mcast_group : 4;
        replication_id : 4;
        lag_hash : 16;
        lf_field_list: 32;

The first 3 fields are needed to do multicast, the last one is needed to do
Even though lf_field_list is not explicitly modified in the P4 program, it
will be used when the generate_digest action primitive is called.
We are looking into ways to improve this.
Note that if you don't find the metadata field names to your liking, you
can change them by editing the dictionary values (not the keys) in this
metadata file:

> Another question is that do we understand correctly that according to the
> specification parsing phase can be done in a lazy way, resulting that some
> headers are parsed on-demand based on the tables (matching rules) to be
> applied. In the current implementation of most of the switches uses lazy
> parsing.
Are you referring to a specific part of the spec?
If some headers show up in the parser definition but are not used in any
match-action tables, you could in theory skip them during the parsing
(while making sure that they are handled correctly by the deparser).
However, this is a target specific optimization and the behavioral model
does no such thing.

> My last question is related to the interface of the switch. Do you plan to
> provide a standardized way - e.g. something like that is used by openflow
> between switches and controllers?

The high-level semantic library (https://github.com/p4lang/switchapi)
complements the switch P4 program (
We are also looking into OpenFlow and SAI (Switch Abstraction Interface)

Best regards,


> Thank you in advance!
> Best,
> Sandor
> --
> Sándor Laki
> Department of Information Systems
> Eötvös Loránd University
> Pázmány Péter stny. 1/C
> H-1117, Budapest, Hungary
> Room 2.506
> Web: http://lakis.web.elte.hu
> Phone: +36 1 372 2869 /
> Cell: +36 70 374 2646

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20150616/1b3983bc/attachment-0001.html>

More information about the P4-dev mailing list