[P4-dev] Binding a table to an interface

Ganesh C S ch.sa.ganesh at gmail.com
Thu Jan 18 20:03:26 EST 2018


You are right. The most prevalent relationship between ports to pipeline is
many to many. In few cases, it is one to one where one high-speed port
(400GbE/1TbE) has its dedicated pipeline. I am yet to see a many to one
high-speed data plane where all pipeline table entries must be global.

regs
Ganesh

On Fri, Jan 19, 2018 at 5:58 AM, Andy Fingerhut <andy.fingerhut at gmail.com>
wrote:

> Several high-speed data planes I am aware of have multiple pipelines, but
> each pipeline handles packets to/from more than one physical port.  So a
> single pipeline must handle a mix of traffic to/from multiple ports, and
> will typically not have any tables dedicated for use solely by one physical
> port.
>
> Andy
>
> 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
>>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> 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/90379168/attachment-0002.html>


More information about the P4-dev mailing list