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

Singh, Jasvinder jasvinder.singh at intel.com
Tue May 17 18:13:39 CEST 2016

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:


> Any help or advice would be most appreciated.
> Many thanks
> --
> Brad.

More information about the users mailing list