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