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

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

[Bradley Kite]

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?

Any help or advice would be most appreciated.

Many thanks
--
Brad.

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

[Singh, Jasvinder]

Hi Bradley

> -----Original Message-----
> From: users [mailto:users-bounces@dpdk.org] On Behalf Of Bradley Kite
> Sent: Monday, May 16, 2016 5:32 PM
> To: users@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.

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

[Bradley Kite]

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

> Hi Bradley
>
> > -----Original Message-----
> > From: users [mailto:users-bounces@dpdk.org] On Behalf Of Bradley Kite
> > Sent: Monday, May 16, 2016 5:32 PM
> > To: users@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.