[P4-dev] generate_digest vs copy_to_cpu

hemant at mnkcg.com hemant at mnkcg.com
Thu Aug 30 06:42:22 EDT 2018

DRL is known for at least a decade.  Still, a major router’s vendor melted in MIT’s network when IPv6 was turned on in 2014.  Too many punted packets to cpu caused the cpu to hang.  




Thanks, Andy and Richard for your notes.




From: Andy Fingerhut <andy.fingerhut at gmail.com> 
Sent: Wednesday, August 29, 2018 11:20 PM
To: hemant at mnkcg.com
Cc: ecm <richard.mayers92 at gmail.com>; p4-dev <p4-dev at lists.p4.org>
Subject: Re: [P4-dev] generate_digest vs copy_to_cpu


Such a note warning about the attack vector in the PSA spec seems reasonable, and I have created a Github issue to remind the arch working group of the idea.  It is a reasonable well-known kind of attack among router/switch implementers, but sure, I guess with people writing their own P4 code they might be surprised by that kind of thing if they haven't seen it before.  We could also add a note about not writing bugs in your P4 or control plane code (just kidding :-)


There is already a Github issue open suggesting the idea of adding an option to the Digest extern for de-duplicating the entries, at least among the recently created messages.  That is an enhancement over the basic digest mechanism that I suspect some implementations might not do.






On Wed, Aug 29, 2018 at 4:26 PM <hemant at mnkcg.com <mailto:hemant at mnkcg.com> > wrote:

Maybe, the PSA doc could also add a note, that data-plane to control-plane punted packets are also an attack vector and Divert Rate Limiting (DRL) should be implemented.   One does not want to bunch digest messages into a larger one if source Mac|IP address|port is same in all messages. 




From: Andy Fingerhut <andy.fingerhut at gmail.com <mailto:andy.fingerhut at gmail.com> > 
Sent: Wednesday, August 29, 2018 7:03 PM
To: richard.mayers92 at gmail.com <mailto:richard.mayers92 at gmail.com> 
Cc: hemant at mnkcg.com <mailto:hemant at mnkcg.com> ; p4-dev <p4-dev at lists.p4.org <mailto:p4-dev at lists.p4.org> >
Subject: Re: [P4-dev] generate_digest vs copy_to_cpu


The only benefit I can think of for using a digest, vs. a truncated packet sent to the CPU, is that an implementation is free to batch many digest messages into one larger message to the CPU, whereas the CPU would typically have to process each packet independently.  Thus there could be a performance benefit in some cases.  The canonical example is using digest to send (input port, source MAC address) pairs for packets that get a miss when looking up their source MAC address in a MAC table, so the control plane can decide whether to add a new entry to that table or not.  If the input port were represented in 2 bytes, for example, then one could pack 128 such pairs into a single ~1Kbyte message to the CPU, versus 128 separate messages.


That said, if the open source implementations of the digest capability are not yet as easy to use as copying a packet, by all means go for the copy-to-cpu approach.


I am not aware of any documentation for the thrift API, other than the open source code available.




On Wed, Aug 29, 2018 at 3:34 PM ec <richard.mayers92 at gmail.com <mailto:richard.mayers92 at gmail.com> > wrote:

Thanks for the reply Hemant,


I know that digest is to send something small, and that sending to cpu sends the entire packet (still you can make it small by truncating).


I was asking more about, if there is any big difference, if one is a better practice than the other in the general case. 


Furthermore, where can I find documentation for the thrift API ?


Kind regards,



On 29 Aug 2018, at 16:34, hemant at mnkcg.com <mailto:hemant at mnkcg.com>  wrote:


Hi Richard,


Please see documentation on digest in the PSA specification:  <https://p4.org/p4-spec/docs/PSA-v1.0.0.html> https://p4.org/p4-spec/docs/PSA-v1.0.0.html  

Just section 7.14.  The digest is used to send abbreviated data to the control-plane.


In the P4-16 specification ( <https://p4.org/p4-spec/docs/P4-16-v1.1.0-draft.html> https://p4.org/p4-spec/docs/P4-16-v1.1.0-draft.html) , there is also an example to send a packet to a specific port.  Search for "to_cpu" in the doc and see the example.





-----Original Message-----
From: P4-dev <p4-dev-bounces at lists.p4.org <mailto:p4-dev-bounces at lists.p4.org> > On Behalf Of ecm
Sent: Tuesday, August 28, 2018 7:40 PM
To: p4-dev at lists.p4.org <mailto:p4-dev at lists.p4.org> 
Subject: [P4-dev] generate_digest vs copy_to_cpu


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,




P4-dev mailing list

 <mailto:P4-dev at lists.p4.org> P4-dev at lists.p4.org

 <http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org


P4-dev mailing list
P4-dev at lists.p4.org <mailto:P4-dev at lists.p4.org> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20180830/960e019c/attachment.html>

More information about the P4-dev mailing list