[P4-dev] General question on P4

Andy Fingerhut andy.fingerhut at gmail.com
Fri Apr 7 17:37:41 EDT 2017


I don't have experience with all NPUs, but many I have seen top out on the
order of hundreds of millions of packets per second with current technology.

With the same current technology, it is possible to design fixed function
ASICs, and programmable ASICs like Barefoot's Tofino, that achieve billions
of packets per second.

The main difference that I am aware of is that many NPUs are based on
parallel arrays of 32-bit or 64-bit processor cores, and each core requires
many cycles for things like constructing table search keys and performing
side effects on the 'packet vector' (state maintained while forwarding the
packet about that packet only).  If you want to go at billions of packets
per second, the only way I know to get there is to have fixed or
configurable hardware that can do those things in 1 or 2 clock cycles per
packet.

You can write a compiler that compiles a P4 program to run on an NPU as
described above, and it will achieve portability of the P4 program, but it
won't make that NPU able to go at billions of packets per second.  It is
limited in performance by its hardware architecture.

There are proprietary methods for programming some ASICs that can go at
billions of packets per second, but all that I know of are lower level than
P4 and non-portable.

Andy

On Thu, Apr 6, 2017 at 6:37 PM, Michael Borokhovich <michaelbor at gmail.com>
wrote:

> Hi Remy,
>
> I'm not confusing hardware with the language... What I mean is that P4 +
> ASIC that supports it claims to give us programmable data-plane and this is
> claimed to be the innovation. But that is exactly the purpose of NPUs - to
> give us programmable data-plane and NPUs are around for a very long time.
> So maybe I'm missing the point of innovation that P4 + ASIC that supports
> it gives. As Nate said, and I agree, one big advantage is portability and
> the other - ability to do verification.
> So, P4 brings kind of an open standard for programmable ASICs which is
> analogous to a programming language (e.g., C) for regular CPUs. While each
> NPU currently have its own language and a programming style.
>
> What do you think?
>
> Thanks,
> Michael.
>
>
> On Thu, Apr 6, 2017 at 2:07 PM, Remy Chang <remy at barefootnetworks.com>
> wrote:
>
>> Hi Michael,
>> It seems you're conflating hardware with language.  NPU, programmable
>> ASIC, general purpose CPU, and even GPU can all potentially execute p4
>> code.
>>
>> Regards,
>> Remy
>>
>>
>>
>> On Apr 6, 2017 10:57, "Michael Borokhovich" <michaelbor at gmail.com> wrote:
>>
>> Thanks for the reply Nate!
>>
>> So, to summarize, the benefits of P4 approach are: portability and
>> performance. Other than that you probably can achieve the same (if not
>> better) flexibility/programmability with an NPU. Is this correct?
>>
>>
>> On Thu, Apr 6, 2017 at 1:01 AM, Nate Foster <jnfoster at cs.cornell.edu>
>> wrote:
>>
>>> Your question seems to be more about the relative merits of various
>>> architectures than the P4 language. But yes an ASIC is generally more
>>> efficient than an NPU, at least at scale.
>>>
>>> Beyond efficiency there are other benefits to expressing a data plane
>>> algorithm in an open framework like P4. For example, a P4 programs should
>>> be relatively easy to port to a different target. The same is unlikely to
>>> be true for C programs written against closed SDKs.
>>>
>>> -N
>>>
>>> On Wed, Apr 5, 2017 at 6:59 PM, Michael Borokhovich <
>>> michaelbor at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> P4 allows for configurable data-plane, e.g., we can easily support new
>>>> custom protocols. However, the same functionality may be achieved by using
>>>> a network processor, e.g., EZchip (the one I had experience with).
>>>>
>>>> As I understand, the advantages of programmable ASIC/FPGA that supports
>>>> P4 is better performance and a lower price than a network processor?
>>>>
>>>> What do you think?
>>>>
>>>> Thanks!
>>>> Michael.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>>
>
> _______________________________________________
> 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/20170407/9af7c7a0/attachment-0002.html>


More information about the P4-dev mailing list