[P4-dev] complex function like pattern matching

Antonin Bas antonin at barefootnetworks.com
Tue Apr 11 12:42:58 EDT 2017


Please see inline

On Tue, Apr 11, 2017 at 12:41 AM, yunchen chang <y2924uki at gmail.com> wrote:

> Hi Antonin:
> Thanks for your reply.
> I have another questions about primitives function.
> 1) Can I call any C++ functions? (like string compare etc)

Yes, why not? You can write any C++ code.

> 2) This https://github.com/p4lang/p4c-bm/blob/master/p4c_
> bm/primitives.json is uesd by p4 compiler to know the functions it have,
> am I right? But why there are only few functions in this file? Primitive
> functions of simple_switch (https://github.com/p4lang/
> behavioral-model/blob/master/targets/simple_switch/primitives.cpp) don't
> need to be known by compiler?

The standard primitives which are described in the P4_14 spec are in a
different location:

> 3) Because I only see https://github.com/p4lang/
> p4c-bm/blob/master/p4c_bm/primitives.json this code. I want to know what
> the format of properties: types and data_width means.
> For example : modify_field_rng_uniform :
> "type" : ["field", "int", "table_entry_data"]
> and "data_width" : "dst"
> Are there any documents explain the information?

No document, just available examples.
In "type" you can list the acceptable types for a given parameter. Accepted
values are "field", "int" (for an literal constant), "table_entry_data"
(for integral values that come from action data), "header_instance",
"register", "counter", "meter",...
"data_width" is only required for parameters for which "table_entry_data"
is a possible type. This is needed to allocate the appropriate memory for
tables. It can either be an integer value, the name of another parameter
(which cannot itself be of type "table_entry_data") or a field reference.
In the case of "modify_field_rng_uniform" for example, parameters "begin"
and "end" can either be literal constants, field references or table action
data ("table_entry_data"). In the case where "begin" (or "end") comes from
table action data, the number of bits we allocate for it in a table entry
is determined by the bitwidth of the "dst" parameter, which is a field
In the following code:
table t_set_port {
    reads { ... }
    actions { set_port; }
action set_port(b, e) {
  modify_field_rng_uniform(standard_metadata.egress_spec /* 9 bit by
definition */, b, e);
Both "b" and "e" come from action data. They are assumed to be 9-bit, based
on the width for standard_metadata.egress_spec. This is different from
P4_16, where types for action parameters are explicit.

> Thanks you so much.
> Best regards,
> Abbie
> On Fri, Apr 7, 2017 at 2:52 AM, Antonin Bas <antonin at barefootnetworks.com>
> wrote:
>> Hi,
>> Yes you can add your code to primitives.cpp. There are many examples you
>> can look at so this shouldn't be too hard. Don't forget to call the
>> REGISTER_PRIMITIVE macro. Note that after you modify the simple_switch
>> code, it will not be the "standard" simple_switch any more. It will be your
>> own version of it, which supports one extra primitive.
>> In order to have the p4c-bm compiler support your new primitive, you will
>> need to add your primitive description to https://github.com/p4lang/p
>> 4c-bm/blob/master/p4c_bm/primitives.json. Once again, there are many
>> examples there that you can look at, but if you need help you can send an
>> email to the list.
>> Finally, I just want to stress out what Andy already said. Just because
>> it runs on bmv2 simple_switch doesn't mean it will run on other
>> P4-programmable targets.
>> Thanks,
>> Antonin
>> On Thu, Apr 6, 2017 at 1:01 AM, yunchen chang <y2924uki at gmail.com> wrote:
>>> Hello Andy,
>>> Thanks for your response.
>>> 1) I am using mininet(simple_switch.cpp) to be my environment,
>>>     so I want to know where should I implement my C/C++ code? (
>>> primitives.cpp?)
>>> 2) Is there anything I should pay special attention to? ( like:
>>> restrictions of compiler )
>>> Thank you.
>>> Best regards,
>>> Abbie
>>> On Mon, Apr 3, 2017 at 8:35 AM, Andy Fingerhut <andy.fingerhut at gmail.com
>>> > wrote:
>>>> The P4 language is focused on parsing and manipulating packet headers,
>>>> not payloads.
>>>> One could write a custom extension that could search for patterns in a
>>>> payload, but it would be non-portable, and would have to be implemented in
>>>> a target-specific language, e.g. C/C++ for a software model, Verilog for an
>>>> ASIC or FPGA, etc.  It would be similar to having a library written in
>>>> assembler and calling it from C, with the assembler implemented anew for
>>>> each target processor.
>>>> Andy
>>>> On Mon, Mar 27, 2017 at 9:13 AM, yunchen chang <y2924uki at gmail.com>
>>>> wrote:
>>>>> Hello everyone,
>>>>> I am doing an experiment for DPI in P4.
>>>>> (detect packet label in data plane, not in controller)
>>>>> I need some complex funtcions like lookup the host name of payload.
>>>>> Example:
>>>>> host_name: tw.yahoo.com
>>>>> mtach_key: .yahoo.
>>>>> I plan to write function in "primitives.cpp" at first.
>>>>> But after I read this posted : [http://lists.p4.org/pipermail
>>>>> /p4-dev_lists.p4.org/2016-August/000449.html], it pointed that P4
>>>>> can't implement "pattern matching".
>>>>> I want to know is there any solution in current P4?
>>>>> (or any suggestion)
>>>>> Thank you.
>>>>> Best regards,
>>>>> Abbie
>>>>> _______________________________________________
>>>>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20170411/c8f9d93a/attachment-0002.html>

More information about the P4-dev mailing list