>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
