[P4-dev] [P4_16] [copy_to_cpu] how to drop packet payload only

Antonin Bas antonin at barefootnetworks.com
Wed Jun 14 13:04:58 EDT 2017

It is fine from a P4_16 syntax point of view and should run on bmv2.
However, hardware targets usually use special (limited) memory for header
fields, which can be heavily constrained, so depending on your P4 compiler
and the hardware you want to compile your program to, it may not be
possible to have such a huge varbit field. An operation like truncate is
likely to be more portable IMO.

On Tue, Jun 13, 2017 at 9:12 PM, Hu Dingyuan <h-dy at outlook.com> wrote:

> Thanks Antonin!
> I have no idea about buffer the packet.
> But for drop packet payload, I have an idea.
> Can I define the payload as a special header, and don’t emit it in
> deparser?
> header payload_t{
>        varbit<9000> content;
> }
> ---
> Dingyuan
> From: Antonin Bas <antonin at barefootnetworks.com>
> Date: Tuesday, 13 June 2017 at 02:54
> To: Dingyuan <h-dy at outlook.com>
> Cc: P4-dev <p4-dev at lists.p4.org>
> Subject: Re: [P4-dev] [P4_16] [copy_to_cpu] how to drop packet payload only
> Hi,
> Encapsulating a packet is easy, you just need to define additional header
> instances and write your deparser code appropriately.
> If you only want to send some packet header values to the control-plane,
> then you may consider using learning instead of something like packet-in.
> v1model.p4 includes the "digest" extern method (https://github.com/p4lang/
> p4c/blob/master/p4include/v1model.p4#L113). digest is a good way to
> achieve mac address learning for example. It enables you to select some
> field values that you wish to transmit to a "receiver". The notion of
> "receiver" is not well-defined. It could be a control-plane receiver or it
> could be pure hardware learning in some targets. In the case of bmv2
> simple_switch, the "receiver" is always a nanomsg PUB/SUB channel (
> http://nanomsg.org/). Using "digest" can be a little involved from a
> control-plane perspective though, so if you are just starting to experiment
> with P4, I would highly recommend not starting with it. At this time, I do
> not consider using "digest" in a P4 program to be very portable.
> The most popular way of sending packet to the control-plane IMO is to
> clone your original packet, encapsulate the copy in the desired headers and
> send it to your control-plane "port". If you really want to discard the
> packet payload, maybe you could try using truncate on the clone (
> https://github.com/p4lang/p4c/blob/master/p4include/v1model.p4#L141).
> Regarding your last question, no packet buffering capability is exposed to
> the P4 programmer by default. v1model.p4 does expose stateful registers, so
> in theory one may be able to do use that.
> An implementation of "digest" may choose to buffer field values until a
> timeout or until a control-plane request comes, but this is definitely out
> of the scope of P4.
> Your question is pretty vague and it may help if you told us exactly what
> you are trying to achieve, maybe with a mix of P4_16 code and pseudocode.
> Thanks,
> Antonin
> On Mon, Jun 12, 2017 at 2:33 AM, Hu Dingyuan <h-dy at outlook.com> wrote:
> Hi,
> I want to implement copy_to_cpu function. (like OpenFlow Packet-IN)
> When I decided to send a packet to control-plane, I need to encapsulate
> the packet with new ethernet/ip/udp header.
> How can I only send packet header and don’t send the origin payload.
> Another question, can I buffer the packet and wait for control-plane?
> _______________________________________________
> 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/20170614/1b5f6c80/attachment-0002.html>

More information about the P4-dev mailing list