[dpdk-users] Ability to clear/reset pipeline table?
bradley.kite at gmail.com
Wed May 18 22:58:42 CEST 2016
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
> > 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
> > 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
> -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.
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.
More information about the users