[P4-dev] Intrinsic metadata and some other questions

Changhoon Kim chang at barefootnetworks.com
Thu Jun 25 03:00:09 EDT 2015


Sandor,

These are great feedback and questions.

As you alluded, if a target architecture is best suited for lazy parsing,
would the compiler be able to break the full parse graph into several
pieces and place each individual parsing sub-logic right in front of its
corresponding table? Any reason why we'd have to model such logic-placement
specifications at the P4 level?

Regarding the digest receiver and portability, it seems we could achieve
some decent portability by agreeing on the types and names of a few common
digest receivers, hence hiding the actual target-specific values behind the
common names.

-- Chang

On Tue, Jun 23, 2015 at 5:16 AM, Sandor Laki <lakis at elte.hu> wrote:

>  Hi Chang,
>
> Yes, in my understanding lazy parsing is more than what resubmit can do.
> For example, imagine a situtation when your p4 program parses ethernet and
> IPv4 headers, but the tables applied to the current incoming packet only
> contains "reads" for some ethernet fields. In this case the IPv4 header
> does not take part in the decision making at all. My view that the ability
> of lazy parsing belongs to compiler, but could be allowed by the
> specification. As far as I know, the current specification may allow this
> kind of lazy parsing. According to the discussion with our industrial
> partner (a large vendor, but I have not had the permission to name it yet),
> thier OpenFlow switch does the parsing in a lazy fashion. Actually, the
> parsing always stops as soon as the given table-lookup can be performed.
>
> Besides these, we have further questions related to the example compiler.
> There are some predefined "magic" numbers in the current l2switch p4
> programs, e.g. digest-receiver 1024 is used for mac learning. What is the
> long-term plan with these numbers, since they seems to be target specific
> values? Is it not the case that reduces the portability of a p4 program?
>
> Thanks for you reply in advance!
>
> Best,
> Sandor
>
>
>
> 2015.06.19. 2:39 keltezéssel, Changhoon Kim írta:
>
> Hi Sandor,
>
>  Regarding your question about lazy parsing (a.k.a. incremental parsing),
> have you considered using the "resubmit" primitive action? I got the
> impression that what you intend to do via lazy parsing is probably
> something more than what resubmit can do, but it'd be helpful to hear your
> thoughts on that. If you truly want to introduce parsing logic anywhere in
> the match-action pipeline, then I think it's more fundamental a topic that
> requires flexibility in the "P4 abstract forwarding model (Fig 1)".
>
>  I believe some folks in the P4 community are interested in evolving the
> language spec so P4 could embrace architectural differences of various
> underlying targets.
>
>  -- Chang
>
>
> On Tue, Jun 16, 2015 at 10:10 AM, Antonin Bas <
> antonin at barefootnetworks.com> wrote:
>
>> 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 learning.
>>  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:
>> https://github.com/p4lang/p4c-behavioral/blob/master/p4c_bm/meta_config.json
>>
>>
>>>
>>> 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 (
>> https://github.com/p4lang/p4factory/tree/master/targets/switch/p4src).
>>  We are also looking into OpenFlow and SAI (Switch Abstraction
>> Interface) compatibility.
>>
>>  Best regards,
>>
>>  Antonin
>>
>>
>>>
>>> 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 <%2B36%201%20372%202869> /
>>> Cell: +36 70 374 2646 <%2B36%2070%20374%202646>
>>>
>>>
>>
>>
>> --
>>  Antonin
>>
>> _______________________________________________
>> P4-dev mailing list
>> P4-dev at p4.org
>> Listinfo - http://mail.p4.org/mailman/listinfo/p4-dev_p4.org
>> Archives - http://mail.p4.org/pipermail/p4-dev_p4.org/
>>
>
>
>
> --
> Sándor Laki, PhD
> Assistant Professor
> 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 / 8477
> Cell: +36 70 374 2646
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20150625/372a450e/attachment-0001.html>


More information about the P4-dev mailing list