From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) by dpdk.org (Postfix) with ESMTP id 488E26CBA for ; Wed, 18 May 2016 22:58:43 +0200 (CEST) Received: by mail-lf0-f41.google.com with SMTP id y84so25241087lfc.0 for ; Wed, 18 May 2016 13:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=N3AH859PQkZVAVFu1FoZCsK7xJdF5Sil16UCDnpVxZo=; b=w9eOC1svnotHexAo7bdWfkQItxpYNdIjqi4PWlXynWpjYdXVRuWnBbyPokgyoTqdIv d/eKqPxwFYIJCAebPM8IgKVsB4ULfOsWo4OmKBoDeb3/ri/4nxPgSpS0qXpyPccnQ1xs 37ZRz8uzU0TjRIsoi6UzC9Ch6JpAdvir4QS+sbyM+Oy3xtnTx8Yg8ciqBul/ZEfAYlgB EWrHKvqkD/vrqLyYigPLBgUwQEJ7bkkCuRH49LQV/yFiExmxI9igjtxzx1w6SJyNa0FC 5NDGBOeLpRpIHCJL4/H23gc1JTVXnuVsenmi05c3bbg6CB+w0gs06mTjrn53pSrLlese 6lCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=N3AH859PQkZVAVFu1FoZCsK7xJdF5Sil16UCDnpVxZo=; b=AsJU2IShHp/dD/I7HzhEJGLyoTTJ89fgLZCG+IT3u1uWrQf5NjAP9XpE5Y3GFbE7LR z8q/Ey3KwqB6PRLV/CND2l7jpu5cBERJFxZ2gyqwmuXvXLuzu2Pbdu2YuYvqZGByOgU4 OwaP25NSahLyzETI00WLzTv0idTCTJ0CPrbVn1cyjAeQj5uZ2ZNUKNbDjkEWhLimRltQ HsXaAlVvT7//YLtnnqscZbXozVvRdAU1J6OFqglwnR0p6RidsFnE4BopCATzzUP2I/e+ YUz6TNO7eLI3y/pqxsuz19RLfcJlupUL0XeuM0jsKPCBH2H1Asjj21kUUvpeVHJQB+ci o3dg== X-Gm-Message-State: AOPr4FUekmBvvAlOVj2JKqfEEJUEbW8xCAGtUel0/FaA0/ifTGWeq+fXmFbreYoWov2B04NLl7jpI9sTGq7BHw== MIME-Version: 1.0 X-Received: by 10.25.215.16 with SMTP id o16mr2665882lfg.31.1463605122893; Wed, 18 May 2016 13:58:42 -0700 (PDT) Received: by 10.25.89.146 with HTTP; Wed, 18 May 2016 13:58:42 -0700 (PDT) In-Reply-To: <54CBAA185211B4429112C315DA58FF6DE2BCEF@IRSMSX103.ger.corp.intel.com> References: <54CBAA185211B4429112C315DA58FF6DE2BCEF@IRSMSX103.ger.corp.intel.com> Date: Wed, 18 May 2016 21:58:42 +0100 Message-ID: From: Bradley Kite To: "Singh, Jasvinder" Cc: "users@dpdk.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] Ability to clear/reset pipeline table? X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 20:58:43 -0000 On 17 May 2016 at 17:13, Singh, Jasvinder 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.