[P4-discuss] (no subject)

Antonin Bas antonin at barefootnetworks.com
Fri Jun 19 11:56:21 EDT 2015

Hi Simon,

Thanks for your interest in the p4 project. Please see my answers inline.

On Fri, Jun 19, 2015 at 5:36 AM, SIMON JOUET <s.jouet.1 at research.gla.ac.uk>

>  Hi P4 community,
> First off, thanks for the work on the P4 project, even though it’s still
> in the early days, reading the specifications and playing with the compiler
> is a interesting experience.
> I started prototyping with P4 for about a week now, and I've ran into some
> limitations, most that are probably due to my limited knowledge of the
> language. I’ve listed below some of the questions I have, hoping to get a
> better understanding of the language:
>    - The specification document and the p4-bm have some differences
>    (mostly in the actions definition), at this early stage which one of the
>    two should be considered as the reference? For instance in the
>    specification to execute a meter *meter()* should be used while in the
>    bm *execute_meter()* is used. (similar difference with
>    *modify_field_with_hash_based_offset*)
Yes you will observe some small differences between the specification and
the actual implementation in p4-hlir and p4-bm. Most of them are for legacy
reasons: changes were made to the spec and were not propagated to the
behavioral model. This is the case for the
modify_field_with_hash_based_offset action primitive. The name has not been
updated to set_field_to_hash_index yet. The story for execute_meter is
slightly different. Our p4 parser (in p4-hlir) uses "meter" as a keyword
(used to declare meter arrays), but for implementation reasons action
primitive names cannot be keywords. We will eventually try to resolve these

>    - The default set of actions does not provide any mechanism to add
>    entries to a table, in the description of *generate_digest()* (page
>    41) it is described that this “might be used to represent a self-update
>    operation”. In the current behavioral model is this possible? or is it a
>    design decision not to have actions capable of add entries and this logic
>    should be left to the controller? (in such case self-learning is impossible)
As of now, in the current behavioral model implementation, all table
updates have to be done through the control plane. self-learning would be a
useful addition and we are investigating it.

>    - For the use case I was playing with, I had to keep track of the byte
>    count of some flows in a self-learning way, for this and with respect to
>    the specs I would assume a meter is the most suitable. However at this
>    point I had a problem with the index being either a immediate value or a
>    table entry parameter and not a field preventing to use for instance a hash
>    of some fields as the index. As a consequence I moved to using registers
>    instead of meters and managed to get something working, however I’m not
>    sure this approach is correct. Should registers be used to store ~large
>    amount of data for instance 10000 entries or be kept small only for state
>    information ? Should the registers internal to the dataplane are be
>    queryable by the controller similarly to counters and meters ?
A register is indeed the best way -in my opinion- to do this. I see no
issues with having a register array with 10,000 entries of 32 bits each, it
does not sound huge to me. If you are compiling to hardware, your choice
will of course eventually be dictated by the amount of memory available on
your switch device. We are working on making the registers accessible by
the control plane.

> Thanks, I hope this is not completely out of context and that the discuss
> mailing list is the right point of contact for such questions. I would be
> happy to provide more details if required.
> Best regards,
> Simon
> _______________________________________________
> P4-discuss mailing list
> P4-discuss at mail.p4.org
> Listinfo - http://mail.p4.org/mailman/listinfo/p4-discuss_p4.org
> Archives - http://mail.p4.org/pipermail/p4-discuss_p4.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-discuss_lists.p4.org/attachments/20150619/3a269b38/attachment-0001.html>

More information about the P4-discuss mailing list