Resource Limitations on P4 Code

201 views
Skip to first unread message

David Hancock

unread,
Feb 28, 2017, 7:06:05 PM2/28/17
to open-nfp
Hello,

We have the Agilio ISA 4000 2x40G cards. I believe that means
AMDA0097-0001 and a chip from the nfp-4xxxc series. We have seen a case
where our .p4 code did not build in the IDE because we had too many
elements in a header stack. What other limitations are there:

- maximum number of parse states?

- maximum number of tables?

- maximum number of control functions?

- maximum number of header types?

- maximum number of declared headers?

- maximum field width?

- maximum bytes that can be matched at once?

Is there a document that discloses these limits? I can build until
failure but I wondered if there is a better way. I have a configurable
application that uses extreme amounts of all of these things, but in
particular, it is best to configure it to use the maximum number of
tables and control functions, whatever those numbers are, for the given
device I deploy it to.

Thanks,

David

David George

unread,
Mar 1, 2017, 1:47:14 AM3/1/17
to David Hancock, open-nfp
Hi David

The specific construct limits are often nebulous, as they may be limited by code store, registers or memory. Though in a number of cases, there are hard limits. There is no document describing the limits, but this message has now prompted me to start one.

We have seen a case where our .p4 code did not build in the IDE because we had too many elements in a header stack.

This limit is a maximum of 16; this seems to be hit a bit and it looks like we should try to improve it. What was the use case for the high stack count, if you don't mind my asking? I have seen a high stack count used for P4 INT.

 
What other limitations are there:

- maximum number of parse states?

Limit would eventually be code store
 
- maximum number of tables?

256 tables which include field matches (default only tables don't count towards this)
 
- maximum number of control functions?

Again code store limit
 
- maximum number of header types?
No limit.
 
- maximum number of declared headers?

With lots of headers you eventually run out of local memory; I would estimate 768B of headers and metadata would be approaching the limit. There is some logic to store headers in a way that mutually exclusive ones are stored in the same memory, so the exact number is design dependent. Also lots of headers may contribute to hitting limits code store in deparsing.
 
- maximum field width?
No maximum mostly, though code store and register usage will be increased. Multiple, divide and modulo operations are limited to 32 bits.

 
- maximum bytes that can be matched at once?
 
The absolute maximum for this is 40 16-bit field chunks but this would likely be lower in practice due to implicit header valids (which take up a slot per header) and small fields take up a whole chunk. When the key material for all the tables exceeds 24 32-bit words the lookup caching will be disabled, which will reduce performance.


Is there a document that discloses these limits?  I can build until failure but I wondered if there is a better way.  I have a configurable application that uses extreme amounts of all of these things, but in particular, it is best to configure it to use the maximum number of tables and control functions, whatever those numbers are, for the given device I deploy it to.

As I said, there is no document at the moment. It is really helpful to me to see what limits you want to know, particularly when writing a document. If you have more you could send those to me directly.

Regards,
David George
 
 

David Hancock

unread,
Mar 1, 2017, 10:56:04 AM3/1/17
to open...@googlegroups.com

Thank you, this is very helpful!

My use case is a P4 program that virtually hosts other P4 programs, like a hypervisor.  So the more resources my hypervisor has, the more numbers and types of programs it can host.  To implement a dynamically programmable parser, I have a header stack of say 100 elements where each element is a generic header type with a single, one byte-wide field.  I extract a default number of bytes (say 20) and then in the ingress pipeline I have some tables that look at what has been extracted.  Potentially, this could result in an action that includes the resubmit primitive, after first setting a metadata field with the number of bytes that should be extracted.  Once the packet is resubmitted, this field is read by the parser, triggering the branches among parse states that result in extracting the correct number of bytes.  I know this approach sounds convoluted but it arose at a time when parser exceptions were not available - today I will look at simply extracting bytes until a parser exception is triggered.

I can mitigate the 16-element limit by using a mix of generic header types, some with larger fields, to continue supporting a dynamically programmable parser capable of extracting up to 100 bytes.  I just need to discover and take into account platform specific limitations like that to allow the hypervisor to be deployed on a variety of platforms.  I've been using the Barefoot Networks bmv2 simple switch, which as a software switch is virtually unlimited in the amount of resources available, and it is time to explore hardware.

--David
--
You received this message because you are subscribed to the Google Groups "open-nfp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-nfp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-nfp/CAA1sxtwDJu3z_aJp4PLfBgdZde_wuSQeTV39eOhbO1FM61M4uQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Abhishek Dixit

unread,
Apr 5, 2024, 1:36:26 AM4/5/24
to open-nfp
Hi David Hancock and David George, I am trying to use Headerstack for a uni project, and when I use .next to parse it, I get an "ambiguous parsing order" error. 
And when I try to use them index-wise, I get an error saying "compile failed error: Header(s) ['patrns[0]', 'patrns[15]', 'patrns[2]', 'patrns[14]', 'patrns[1]', 'patrns[7]', 'patrns[10]', 'patrns[5]', 'patrns[13]', 'patrns[11]', 'patrns[12]', 'patrns[3]', 'patrns[8]', 'patrns[6]', 'patrns[4]', 'patrns[9]'] extracted in the parser but are not referenced in the deparser".

Please point me to some resources demonstrating using header stacks in Netronome for p4? Thank you so much.

Reply all
Reply to author
Forward
0 new messages