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 

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 
- 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?


Reply via email to