[dpdk-users] Ability to clear/reset pipeline table?

[Bradley Kite]

On 17 May 2016 at 17:13, Singh, Jasvinder <jasvinder.singh at intel.com> wrote:

> Hi Bradley
>
> > -----Original Message-----
> > From: users [mailto:users-bounces at dpdk.org] On Behalf Of Bradley Kite
> > Sent: Monday, May 16, 2016 5:32 PM
> > To: users at dpdk.org
> > Subject: [dpdk-users] Ability to clear/reset pipeline table?
> >
> > Hi there,
> >
> > The application I am writing needs to be able to clear all entries from
> a table
> > and then bulk-load a new set of entries - eg due to a "commit" action by
> a
> > user when applying new configuration, or perhaps by a CLI command (eg to
> > clear a NAT table).
> >
> > I could not find a particularly easy way of doing this via the API's, so
> am I
> > correct in thinking that I need the application to also keep lists of
> all keys
> > within the table and then call rte_pipeline_table_entry_delete_bulk()
> > followed by rte_pipeline_table_entry_add_bulk()?
> >
> > Does this approach not require twice as much memory if both the
> application
> > and the DPDK library keep copies of the keys for a table?
>
> Yes, in this case, two copies of the table entries will be maintained.
> This approach has been implemented in examples/ip_pipeline sample
> application. You can look at any pipeline (flow classification, firewall,
> routing, etc), all of them implement this  strategy.
>
> The two copies are in sync with each other while used for different
> purposes:
> -fast table copy: It is used by data plane thread and is implemented using
> the rte_table API. The lookup operation is packet-oriented (works with a
> packet burst), and optimized for performance.
> -slow table copy: It is used by the application control/management plane
> thread, not necessarily slow for lookup but optimized for handling user
> queries such as display of the entries etc., without impacting the data
> plane performance. Table entries are entered in this table first and then
> request is send to the data plane thread to update the fast table copy.
>
> More description can be found at the links below:
> http://www.dpdk.org/doc/guides/sample_app_ug/ip_pipeline.html#table-copies
>
> http://www.dpdk.org/doc/guides/prog_guide/packet_framework.html#shared-data-structures
>
>
> Jasvinder
>
> > Any help or advice would be most appreciated.
> >
> > Many thanks
> > --
> > Brad.
>

Hi there Jasvinder,

Many thanks for your response.

In my case, I am looking to implement SNAT and DNAT tables, so the master
thread wont know about the entries as they are created by the fast-path -
however I still need to implement a "clear table" command that the master /
CLI thread can send, so with the current API the fast-path will need to
keep two copies of the SNAT / DNAT entries.

In order to avoid this, I will try to make a patch to DPDK - the draft
version is attached. Once I have done some more testing with it I will
submit it to the dev mailing list - but if you have any feedback at this
point in time then please let me know and I will look to improve it.

Regards and thanks for your help.

--
Brad.