[P4-dev] Binding a table to an interface

Andy Fingerhut andy.fingerhut at gmail.com
Thu Jan 18 19:28:45 EST 2018


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-
> 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
>>>
>>
>>
>>
>
> _______________________________________________
> 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/aaf81ba5/attachment-0002.html>


More information about the P4-dev mailing list