[P4-dev] Intrinsic metadata and some other questions

Sandor Laki lakis at elte.hu
Tue Jun 23 08:16:20 EDT 2015


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 <mailto: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
>     <mailto: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 <tel:%2B36%201%20372%202869> /
>         Cell: +36 70 374 2646 <tel:%2B36%2070%20374%202646>
>
>
>
>
>     -- 
>     Antonin
>
>     _______________________________________________
>     P4-dev mailing list
>     P4-dev at p4.org <mailto: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/20150623/55be2d52/attachment-0001.html>


More information about the P4-dev mailing list