[dpdk-dev] perfomance of rte_lpm rule subsystem

Alexander Kiselev kiselev99 at gmail.com
Wed Apr 20 07:06:44 CEST 2016


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. 

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


More information about the dev mailing list