From: Alex Kiselev <alex@therouter.net>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Bruce Richardson <bruce.richardson@intel.com>
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 [thread overview]
Message-ID: <9143297.20180712122953@therouter.net> (raw)
In-Reply-To: <20180711133025.256a8ae1@xeon-e3>
> On Wed, 11 Jul 2018 20:53:46 +0300
> Alex Kiselev <alex@therouter.net> 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
next prev parent reply other threads:[~2018-07-12 9:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-11 17:53 [PATCH v3 1/2] librte_lpm: Improve performance of the delete and add functions Alex Kiselev
2018-07-11 20:30 ` Stephen Hemminger
2018-07-12 9:29 ` Alex Kiselev [this message]
2018-07-16 8:10 ` Alex Kiselev
2018-07-16 17:34 ` Alex Kiselev
2018-07-16 17:50 ` Stephen Hemminger
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=9143297.20180712122953@therouter.net \
--to=alex@therouter.net \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.