Re: [dpdk-dev] perfomance of rte_lpm rule subsystem

["Wiles, Keith" <keith.wiles@intel.com>]

>I just realizied that my patch could be confusing. I want to emphasize that it contains two completly different and independent set of changes. One is new rule subsystem and the other is 64 bit next hop. Maybe I should've prepared a patch with only rule changes, but I wanted to discuss fist and if there would be interest spend some time and make the final patch containing only rule changes.

Normally if you have two or more distinct changes then you need split them up into different patch sets. Each change needs to be a complete patch and independent unless you have a order issue with the patches.

> 
>
>Please ignore the next hop changes. They have nothing to do with rule subsystem changes. The rule changes don't need new next hop and I don't want 64 bit next hop to be part of dpdk.
>
>>> Hi.
>>> 
>>> Doing some test with rte_lpm (adding/deleting bgp full table rules) I
>>> noticed that
>>> rule subsystem is very slow even considering that probably it was never
>>> designed for using
>>> in a data forwarding plane. So I want to propose some changes to the "rule"
>>> subsystem.
>>> 
>>> I reimplemented rule part ot the lib using rte_hash, and perfomance of
>>> adding/deleted routes have increased dramatically.
>>> If increasing speed of adding deleting routes makes sence for anybody else
>>> I would like to discuss my patch.
>>> The patch also include changes that make next_hop 64 bit, so please just
>>> ignore them. The rule changes are in the following
>>> functions only:
>>> 
>>> rte_lpm2_create
>>> 
>>> rule_find
>>> rule_add
>>> rule_delete
>>> find_previous_rule
>>> delete_depth_small
>>> delete_depth_big
>>> 
>>> rte_lpm2_add
>>> rte_lpm2_delete
>>> rte_lpm2_is_rule_present
>>> rte_lpm2_delete_all
>


Regards,
Keith