DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] Why rte_pipeline.c only support forwarding to same table in different entries?
@ 2018-06-07  7:19 hongbo liu
  2018-06-07 14:02 ` Shyam Shrivastav
  0 siblings, 1 reply; 3+ messages in thread
From: hongbo liu @ 2018-06-07  7:19 UTC (permalink / raw)
  To: dev

Hi,

I am frustrated when designing pipeline table.

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

And I noticed that the following checks in rte_pipeline.c:
/****************************************************************
if ((entry->action == RTE_PIPELINE_ACTION_TABLE) &&
table->table_next_id_valid &&
(entry->table_id != table->table_next_id)) {
RTE_LOG(ERR, PIPELINE,
"%s: Tree-like topologies not allowed\n", __func__);
return -EINVAL;
}
****************************************************************/

Is there any reason why adding this limitation?

In openflow, the limitation is the forward table_id must be larger than
current table_id, and the final
table should not have forward table action.

By the way, it still does not work after removing upper checks.

Is it difficult to support forwarding to multiple tables in different
entries?

--
Hobby

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] Why rte_pipeline.c only support forwarding to same table in different entries?
  2018-06-07  7:19 [dpdk-dev] Why rte_pipeline.c only support forwarding to same table in different entries? hongbo liu
@ 2018-06-07 14:02 ` Shyam Shrivastav
  2018-06-12 11:04   ` Dumitrescu, Cristian
  0 siblings, 1 reply; 3+ messages in thread
From: Shyam Shrivastav @ 2018-06-07 14:02 UTC (permalink / raw)
  To: hongbo liu; +Cc: dev

Looking at code, another change might make this work. Make sure that
default entry action of each table points to next table except for last one
which normally should be drop

Please look at if (lookup_miss_mask != 0)  handling in rte_pipeline_run ()

.



On Thu, Jun 7, 2018 at 12:49 PM, hongbo liu <cnliuhb@gmail.com> wrote:

> Hi,
>
> I am frustrated when designing pipeline table.
>
> I am trying to have one ACL table 0 to forward different traffic to
> different table, but it failed.
>
> And I noticed that the following checks in rte_pipeline.c:
> /****************************************************************
> if ((entry->action == RTE_PIPELINE_ACTION_TABLE) &&
> table->table_next_id_valid &&
> (entry->table_id != table->table_next_id)) {
> RTE_LOG(ERR, PIPELINE,
> "%s: Tree-like topologies not allowed\n", __func__);
> return -EINVAL;
> }
> ****************************************************************/
>
> Is there any reason why adding this limitation?
>
> In openflow, the limitation is the forward table_id must be larger than
> current table_id, and the final
> table should not have forward table action.
>
> By the way, it still does not work after removing upper checks.
>
> Is it difficult to support forwarding to multiple tables in different
> entries?
>
> --
> Hobby
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] Why rte_pipeline.c only support forwarding to same table in different entries?
  2018-06-07 14:02 ` Shyam Shrivastav
@ 2018-06-12 11:04   ` Dumitrescu, Cristian
  0 siblings, 0 replies; 3+ messages in thread
From: Dumitrescu, Cristian @ 2018-06-12 11:04 UTC (permalink / raw)
  To: Shyam Shrivastav, hongbo liu; +Cc: dev

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-06-12 11:04 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-07  7:19 [dpdk-dev] Why rte_pipeline.c only support forwarding to same table in different entries? hongbo liu
2018-06-07 14:02 ` Shyam Shrivastav
2018-06-12 11:04   ` Dumitrescu, Cristian

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).