[P4-dev] Binding a table to an interface

Vladimir Gurevich vladimir.gurevich at barefootnetworks.com
Thu Jan 18 20:12:59 EST 2018


Hello Ganesh,

As the author of the presentation you are referring to, I still believe
that Slide 15 in that presentation is quite accurate: the device has 4
pipelines. In fact, most high-speed devices I am familiar with have 1, 2 or
4 pipelines. However, the number of ports is much higher and so each
pipeline serves many ports (the number is probably around 16-64, depending
on the device).

Doing it the other way (i.e. one port per pipeline) would be quite
challenging  in general (and at high speeds in particular). Here are some
challenges you would have:

   1. Most of the processing is usually common and thus requires the same
   tables with the same contents for each ports. Examples include standard L2
   forwarding tables, L3 routing tables, etc. Implementing these tables as a
   centralized resource that can be accessed in parallel every clock by dozens
   of independent pipelines would be extremely difficult. Having 16 copies of
   the same table (one per pipeline) would be quite expensive both from the
   silicon area point of view as well as from the control plane point of view.
   2. It would also be extremely difficult to implement stateful elements
   (e.g. meters) where changes, caused by a packet ingressing on one port
   (e.g. decrementing the number of tokens in the meter bucket) must be
   visible by packets ingressing in all other ports.

By the way, the same challenges would arise (although would probably be not
as visible) if you decide to implement a software switch with a thread per
port with these threads running on multiple CPU cores: suddenly you will
see that the amount of resources spent on ensuring memory coherency starts
to grow significantly.

happy hacking,
Vladimir

*Vladimir Gurevich*

*Barefoot Networks*
*Technical Lead, Customer Engineering*
Email: vag at barefootnetworks.com
Phone: (408) 833-4505


On Thu, Jan 18, 2018 at 12:52 PM, Ganesh C S <ch.sa.ganesh at gmail.com> wrote:

> [First of all, thanks to Antonin for the inputs.]
>
> Hi Vladimir/Hardik,
>
> Do we really have a single pipeline high-speed data plane switch/router
> hardware ?
>
> A quick search points me to Sl. 15 of the below presentation showing
> multiple ingress/egress pipelines.
> https://open-nfp.org/s/pdfs/Sponsor-Lecture-Vladimir-Data-
> Plane-Acceleration-at-Terabit-Speeds.pdf
>
> Is this outdated ?
>
> regs
> Ganesh
>
> On Wed, Jan 17, 2018 at 5:25 PM, Hardik Soni <hardik.soni at inria.fr> wrote:
>
>> Hi Vladimir/Ganesh,
>>
>> Following are two possible scenarios.
>>
>> if the hardware router has multiple physical pipeline equivalent, then it
>> may not be required to have a mux table in the p4 program.
>> Because, with this, incoming packets on two interfaces can be
>> "programmed" to follow the first table (which implements relevant logic to
>> the interface) of required pipeline, provided hardware supports it.
>> According to my understanding, this is architecture specific thing and
>> not P4 language.
>> Where the hardware router facilitates the interface to pipeline table
>> binding and P4 can allow it to program it using arch.p4.
>> 3rd option proposed by Antonin (in the other email) can do this.
>> In this case, there is no need of a global table.
>>
>> But, if there is a single physical pipeline or equivalent processing unit
>> in the router, then all the packets from all the interfaces will go through
>> the same first table.
>> Here, there is no option, but to separate ingress logic per interface
>> using Vladimir's code.
>>
>> If it is the first scenario, the mux will be in hardware.
>>
>> -Hardik
>>
>> ------------------------------
>>
>> *From: *"Vladimir Gurevich" <vladimir.gurevich at barefootnetworks.com>
>> *To: *"Ganesh C S" <ch.sa.ganesh at gmail.com>
>> *Cc: *"Hardik Soni" <hardik.soni at inria.fr>, "p4-dev" <p4-dev at lists.p4.org
>> >
>> *Sent: *Wednesday, 17 January, 2018 3:17:48 AM
>> *Subject: *Re: [P4-dev] Binding a table to an interface
>>
>>
>> Hello Ganesh,
>>
>> I do not think that the proposed solutions are "a hack". You need to
>> consider how exactly this "separate ingress logic per port" is implemented
>> in these routers. Obviously, if the data plane is done in the software then
>> anything is possible, but if you closely examine a modern high-speed
>> dataplane, you will find out that the algorithm is more-or-less the same as
>> was proposed by Hardik. Instead, it is the control plane (e.g. your NOS
>> command line) that creates *an illusion* of these separate tables.
>>
>> There are certainly other methods to achieve that in pure P4 (in this
>> case P4_14, but P4_16 can be used too) and, again, the control plane will
>> create an allusion of this binding.
>> For example:
>>
>> action do_table_1() {}
>> action do_table_2() {}
>> . . .
>> action do_table_n() {}
>>
>> table my_mux {
>>     reads {
>>         standard_metadata.ingress_port : exact;
>>     }
>>     actions {
>>         do_table_1; do_table_2; . . . do_table_N;
>>     }
>> }
>>
>> control table_mux {
>>     apply(my_mux) {
>>         do_table_1 { apply(table_1); }
>>         do_table_2 { apply(table_2); }
>>         . . .
>>         do_table_N { apply(table_N); }
>>     }
>> }
>>
>> This particular method still requires 1 stage and provides flexible
>> binding that can be changed at run-time.
>>
>> Happy Hacking
>> Vladimir
>>
>>
>> *Vladimir Gurevich*
>>
>> *Barefoot Networks*
>> *Technical Lead, Customer Engineering*
>> Email: vag at barefootnetworks.com
>> Phone: (408) 833-4505
>>
>>
>> On Mon, Jan 15, 2018 at 10:32 PM, Ganesh C S <ch.sa.ganesh at gmail.com>
>> wrote:
>>
>>> Having a global table with interface identifier looks to be a hack.
>>>
>>> Some routers have separate ingress that can be populated with locally
>>> relevant logic. I am looking for p4 equivalent of this.
>>>
>>> regs
>>> Ganesh
>>>
>>> On Sun, Jan 14, 2018 at 5:21 AM, Hardik Soni <hardik.soni at inria.fr>
>>> wrote:
>>>
>>>> put InControl.inputPort as a match field for the tables.
>>>>
>>>> -Hardik
>>>>
>>>> ------------------------------
>>>>
>>>> *From: *"Ganesh C S" <ch.sa.ganesh at gmail.com>
>>>> *To: *p4-dev at lists.p4.org
>>>> *Sent: *Sunday, 14 January, 2018 12:16:06 PM
>>>> *Subject: *[P4-dev] Binding a table to an interface
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I am new to P4 and am trying to bind specific match-action tables to
>>>> interfaces. In my case, a packet received on ingress interface A, it should
>>>> look at table A. Similarly, ingress interface B should look at table B and
>>>> so on.
>>>>
>>>> Any way of binding the tables to the interfaces ?
>>>>
>>>> regs
>>>> Ganesh
>>>>
>>>> _______________________________________________
>>>> 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/20180118/54cf9c1b/attachment-0002.html>


More information about the P4-dev mailing list