[dpdk-dev] Why rte_pipeline.c only support forwarding to same table in different entries?

[Dumitrescu, Cristian]

Hi Hobby, Shyam,

> >
> > I am trying to have one ACL table 0 to forward different traffic to
> > different table, but it failed.
> >


> >
> > Is there any reason why adding this limitation?
> >

The current librte_pipeline implementation is limited to supporting a chain of tables as opposed to a tree of tables. Basically, all entries in table A that are connected to another table (as opposed to dropping packets or sending them to an output port) have to point to the same table B.

The reason is related to simplicity of implementation (performance) while the same functionality can be easily achieved in a slightly different way.

The current implementation has a single buffer where the current burst of packets under processing is stored:
- as packets are dropped or sent to output ports, this array of packets starts to develop "holes"
- after current table processing is completed, the remaining packets move to the next table
- the current pipeline iteration is completed when no packets are left in the array

A tree of table topology or a chain where some tables can be skipped by some packets would be more complex and probably lower performance:
- each table should have an input queue of packets; as packets are sent to another table, they are stored in the input array of that table
- a scheduler is needed to track which table has packets to process and schedule them

How to achieve the same thing by using external recirculation through a SW queue/ring:
- have table A send the packets logically destined to table B to a pipeline output port instead; this output port sits on top of a SW queue/ring (ring writer port type)
- have an additional pipeline input port created on top of the same SW queue/ring (ring reader port type)
- connect this pipeline input port directly to table B

The same effect can also be achieved by having table B as part of a different pipeline than table A, with the second pipeline executed by the same (or different, your choice) CPU core as the first pipeline.

Makes sense?

Regards,
Cristian