DPDK usage discussions
 help / color / mirror / Atom feed
From: "Singh, Jasvinder" <jasvinder.singh@intel.com>
To: Bradley Kite <bradley.kite@gmail.com>, "users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] Ability to clear/reset pipeline table?
Date: Tue, 17 May 2016 16:13:39 +0000	[thread overview]
Message-ID: <54CBAA185211B4429112C315DA58FF6DE2BCEF@IRSMSX103.ger.corp.intel.com> (raw)
In-Reply-To: <CA+JxU+5bwS5m2r+WxBFTTYXbhO_Q5y4it1zK4OpXgySvnzeOtQ@mail.gmail.com>

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.

  reply	other threads:[~2016-05-17 16:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-16 16:32 Bradley Kite
2016-05-17 16:13 ` Singh, Jasvinder [this message]
2016-05-18 20:58   ` Bradley Kite

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54CBAA185211B4429112C315DA58FF6DE2BCEF@IRSMSX103.ger.corp.intel.com \
    --to=jasvinder.singh@intel.com \
    --cc=bradley.kite@gmail.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).