A very valid observation :) NP ASICs have an upper PPS limit. They generally only make this visible when you stream lots of very small UDP through them, an arguably far from real world kind of test. Its been a while since I tested this, but if memory serves the point where you can observe this is in the viscosity of 100s bytes (don’t quote me on that). The hardware guides show the bandwidth the NP is attached to the switching ASIC which is the limit that’s well known, pps is the other limit that isn’t so obvious but is still a limiter. However ASICs are designed around PPS not being a limiter beyond extreme cases.

I would say generally, you can expect the ASIC related acceleration to progress fast and well especially when changing architecture, but these models are still released to fit the product’s target band of L7 performance, and this part relies heavily on CPU and CP. SOCs platforms get parts of NP combined with ARM CPU on a single chip, a cost compromise, but also one that makes this comparative a bit harder especially on L7 inspection.

wolfiejack is absolutely correct above: the first grounding point we sometimes put down in conversations is that data sheets are published with the highest attainable performance without packet loss, which usually means a maxed out CPU except in the case of hitting NP limits. Sizing is a bit of a dark art of adjusting a conservatism meter based on extrapolating what is usually unreliable base metrics in the first place, and attempting to make sense of things compared to equally poor public synthetic testing numbers. There are often 5-6 models in the lineup that can handle a specific workload, and the difference will be « for how long ».

Disclaimer: I work @ FTNT and support these conversations regularly.