From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Kiselev Subject: Re: [PATCH v3 1/2] librte_lpm: Improve performance of the delete and add functions Date: Thu, 12 Jul 2018 12:29:53 +0300 Message-ID: <9143297.20180712122953@therouter.net> References: <20180711175356.035761B462@dpdk.org> <20180711133025.256a8ae1@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" , Bruce Richardson To: Stephen Hemminger Return-path: Received: from relay-out6.mail.masterhost.ru (relay-out6.mail.masterhost.ru [83.222.12.16]) by dpdk.org (Postfix) with ESMTP id DD2C11B42C for ; Thu, 12 Jul 2018 11:30:03 +0200 (CEST) In-Reply-To: <20180711133025.256a8ae1@xeon-e3> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > On Wed, 11 Jul 2018 20:53:46 +0300 > Alex Kiselev wrote: >> librte_lpm: Improve lpm6 performance ... >> >> /* LPM Tables. */ >> - struct rte_lpm6_rule *rules_tbl; /**< LPM rules. */ >> + struct rte_mempool *rules_pool; /**< LPM rules mempool. */ >> + struct rte_hash *rules_tbl; /**< LPM rules. */ >> struct rte_lpm6_tbl_entry tbl24[RTE_LPM6_TBL24_NUM_ENTRIES] >> __rte_cache_aligned; /**< LPM tbl24 table. */ >> struct rte_lpm6_tbl_entry tbl8[0] >> @@ -93,22 +106,81 @@ struct rte_lpm6 { >> * and set the rest to 0. > What is the increased memory overhead of having a hash table? compared to the current rules array it's about 2 times since a prefix is stored in a rule (mempool) and in a rule key (hashtable). I am only talking here about the rule storage. And I've just realised it doesn't have to be this way, I don't need the rules mempool anymore. I only need the rules hashtable, since it could contains everything a rule needs. A rule prefix is stored in a hash key, and a next hop index could be stored in a hash value. That would eliminate memory overhead. I'll try this way in next patch series. > Wouldn't it make more sense to use something like tree, and use left/right > in the rules entry. That way the memory is spread and scales with the number > of rules. Maybe. But there is no tree library in the DPDK. So I choose a fast and simple way to implement rules storage using the existent hashtable lib. And it gives good perfomance results. Anyway, it's not a data plane, add/delete operations are executed not very often, so it's not critical to find the most efficient (in terms of memory consumption) way, a good one is ok. > Remember on a internet router, it is not unusual to 2M or more rules. > Also. Please run checkpatch shell script on your patches. For example, there > should be blank line between declarations and code. I have. It didn't give me any warnings. -- Alex