[P4-dev] generate_digest vs copy_to_cpu

Andy Fingerhut andy.fingerhut at gmail.com
Wed Aug 29 23:19:30 EDT 2018


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.

Andy



On Wed, Aug 29, 2018 at 4:26 PM <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.
>
>
>
> Hemant
>
>
>
> *From:* Andy Fingerhut <andy.fingerhut at gmail.com>
> *Sent:* Wednesday, August 29, 2018 7:03 PM
> *To:* richard.mayers92 at gmail.com
> *Cc:* hemant at mnkcg.com; p4-dev <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.
>
>
>
> Andy
>
>
>
> On Wed, Aug 29, 2018 at 3:34 PM ec <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,
>
> Richard
>
>
>
> On 29 Aug 2018, at 16:34, 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
>
> 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) , there is also an
> example to send a packet to a specific port.  Search for "to_cpu" in the
> doc and see the example.
>
>
>
> Hemant
>
>
>
>
>
> -----Original Message-----
> From: P4-dev <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
> 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,
>
> Richard
>
>
>
> _______________________________________________
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20180829/69045de5/attachment.html>


More information about the P4-dev mailing list