[P4-dev] Binding a table to an interface

Ganesh C S ch.sa.ganesh at gmail.com
Fri Jan 19 00:23:51 EST 2018


Hi Vladimir,

I agreed with you on #2: coherency issues will be a significant even across
pipelines with private memory.

regs
Ganesh

On Fri, Jan 19, 2018 at 6:42 AM, Vladimir Gurevich <
vladimir.gurevich at barefootnetworks.com> wrote:

> 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-Pl
>> ane-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/20180119/6afac869/attachment-0002.html>


More information about the P4-dev mailing list