[P4-dev] generate_digest vs copy_to_cpu

Vladimir Gurevich vladimir.gurevich at barefootnetworks.com
Wed Aug 29 19:34:07 EDT 2018

Hello Richard,

There are numerous differences between generate_digest and simply sending a
packet to port, designated as the CPU port. Some of those are fundamental
to how these mechanisms are defined and some are more implementation
specific. There is no "right" or "wrong" mechanism -- all depends on what
you are trying to achieve.

The most fundamental difference is that the digest is generated *in
addition* to the normal forwarding of the packet. So, for example, in the
typical L2 learning case you would still want to forward a packet that
missed the Source MAC lookup, while at the same time send a notification to
the control plane. In that case generate_digest is almost certainly a
better mechanism.

The other important difference is that generate_digest() allows you to
notify the control plane while passing arbitrary metadata to it (as defined
by the corresponding field_list in P4_14 or as deparsed in P4_16), while at
the same time it does *not* allow you to pass packet *payload*. So, for
example, if you encounter an IPv4 packet fragment and would like to send it
to the control plane for reassembly (or if you noticed that the packet
exceeded the outgoing MTU), it would almost certainly make more sense to
send the packet to the CPU port rather than use generate_digest(). Note,
that when you send this packet to the CPU port, you can  also add new
headers to the original packet to pass additional metadata (e.g. the
ingress port, the lookup results, etc.) . Also note, that in this
particular example the packet should not be forwarded anyway.

In other cases, it might be better to use neither generate_digest(), nor
sending the packet to the CPU port. This happens in several important cases:

   1. When you want to pass full packet (with the payload) to the CPU,
   while forwarding it at the same time
   2. When you need to process a packet that experienced parser errors (and
   thus deparsing becomes problematic)
   3. When packet experiences modifications in the course of the
   processing, but you want to see the original packet

In these cases, using ingress_to_egress cloning might be the more
appropriate solution.

There are other differences as well. For example, in most modern devices,
digests are delivered via DMA over PCIe bus and this limits the overall
bandwidth (not to mention that they need to compete with the regular
control traffic, packet DMA, etc.). For example, 2 lanes of Gen3 PCIe (not
an uncommon configuration) max out at about 16Gbps. On the other hand, many
modern switches have 100Gbps ports that can be used for packet traffic
(although this would require your CPU to have a powerful MAC).

You should also consult your vendor: many ASICs have proprietary
enhancements that may become the decisive factors in choosing one mechanism
over another, but you need to be aware of them all. If you are using
Barefoot Tofino ASIC, you are invited to attend Barefoot Academy classes
where we do discuss this and many other topics -- please contact you
Barefoot representative about that.

Happy hacking,

*Vladimir Gurevich*

*Barefoot Networks*
*Director, Customer Training and Education*
Email: vag at barefootnetworks.com
Phone: (408) 833-4505

On Tue, Aug 28, 2018 at 7:40 PM ecm <richard.mayers92 at gmail.com> wrote:

> Hi all,
> I want to know which are the differences between using digests or
> normal switch_ports when writing some sort of control plane. At the
> moment the easiest way I found is to simply send a norma packet to a
> special port where you have a process listening and then if needed
> update the switch using the CLI, thrift, etc..
> When reading the spec, I saw that there was a primitive (not an extern
> in simple_switch) called digest. I never used it due to lack of
> documentation, examples, etc. However, today I wanted to give it a
> try, and after checking the l2 learning example + several mailing list
> posts + some github issues I managed to do something.
> Putting the P4Runtime aside, and considering only digest, and
> copy_to_cpu ( is there more ways of having dp-cp communication ???), I
> would like to know what is the best way to do DP-CP things, or when is
> one more useful than the other ? Because for example using digests
> seems quite cumbersome, since you have to acknowledge every packet you
> receive.
> PD: is there any good documentation of how to use the thrift API? The
> best I found at the moment is the the runtime_CLI.py
> Thanks in advance,
> Richard
> _______________________________________________
> P4-dev mailing list
> P4-dev at lists.p4.org
> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20180829/ddd2ac28/attachment-0001.html>

More information about the P4-dev mailing list