* [dpdk-dev] perfomance of rte_lpm rule subsystem
@ 2016-04-19 11:11 Александр Киселев
2016-04-19 15:46 ` Stephen Hemminger
0 siblings, 1 reply; 6+ messages in thread
From: Александр Киселев @ 2016-04-19 11:11 UTC (permalink / raw)
To: dev
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
P.S. the patch was made for 2.2.0 version.
P.P.S. Would it be more convinient to include full source file instead of
patch?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] perfomance of rte_lpm rule subsystem
2016-04-19 11:11 [dpdk-dev] perfomance of rte_lpm rule subsystem Александр Киселев
@ 2016-04-19 15:46 ` Stephen Hemminger
2016-04-19 20:46 ` Vladimir Medvedkin
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Stephen Hemminger @ 2016-04-19 15:46 UTC (permalink / raw)
To: Александр
Киселев
Cc: dev
On Tue, 19 Apr 2016 14:11:11 +0300
Александр Киселев <kiselev99@gmail.com> wrote:
> 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
>
We forked LPM back several versions ago.
I sent the patches to use BSD red-black tree for rules but the patches were
ignored. mostly because it broke ABI.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] perfomance of rte_lpm rule subsystem
2016-04-19 15:46 ` Stephen Hemminger
@ 2016-04-19 20:46 ` Vladimir Medvedkin
2016-04-20 5:06 ` Alexander Kiselev
2016-05-02 19:38 ` Александр Киселев
2 siblings, 0 replies; 6+ messages in thread
From: Vladimir Medvedkin @ 2016-04-19 20:46 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Александр
Киселев,
dev
Hi Alexander,
Why next_hop is 64 bit long?
2016-04-19 18:46 GMT+03:00 Stephen Hemminger <stephen@networkplumber.org>:
> On Tue, 19 Apr 2016 14:11:11 +0300
> Александр Киселев <kiselev99@gmail.com> wrote:
>
> > 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
> >
>
> We forked LPM back several versions ago.
> I sent the patches to use BSD red-black tree for rules but the patches were
> ignored. mostly because it broke ABI.
>
--
Regards,
Vladimir
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] perfomance of rte_lpm rule subsystem
2016-04-19 15:46 ` Stephen Hemminger
2016-04-19 20:46 ` Vladimir Medvedkin
@ 2016-04-20 5:06 ` Alexander Kiselev
2016-04-20 14:19 ` Wiles, Keith
2016-05-02 19:38 ` Александр Киселев
2 siblings, 1 reply; 6+ messages in thread
From: Alexander Kiselev @ 2016-04-20 5:06 UTC (permalink / raw)
To: dev
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] perfomance of rte_lpm rule subsystem
2016-04-20 5:06 ` Alexander Kiselev
@ 2016-04-20 14:19 ` Wiles, Keith
0 siblings, 0 replies; 6+ messages in thread
From: Wiles, Keith @ 2016-04-20 14:19 UTC (permalink / raw)
To: Alexander Kiselev, dev
>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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] perfomance of rte_lpm rule subsystem
2016-04-19 15:46 ` Stephen Hemminger
2016-04-19 20:46 ` Vladimir Medvedkin
2016-04-20 5:06 ` Alexander Kiselev
@ 2016-05-02 19:38 ` Александр Киселев
2 siblings, 0 replies; 6+ messages in thread
From: Александр Киселев @ 2016-05-02 19:38 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
Stephen, what was the main reason you use red-black tree instead of dir-24-8?
Did you switch to using trees because of too big memory working set of
dir-24-8 algorithm?
2016-04-19 18:46 GMT+03:00 Stephen Hemminger <stephen@networkplumber.org>:
> On Tue, 19 Apr 2016 14:11:11 +0300
> Александр Киселев <kiselev99@gmail.com> wrote:
>
> > 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
> >
>
> We forked LPM back several versions ago.
> I sent the patches to use BSD red-black tree for rules but the patches were
> ignored. mostly because it broke ABI.
>
--
--
Kiselev Alexander
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-05-02 19:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-19 11:11 [dpdk-dev] perfomance of rte_lpm rule subsystem Александр Киселев
2016-04-19 15:46 ` Stephen Hemminger
2016-04-19 20:46 ` Vladimir Medvedkin
2016-04-20 5:06 ` Alexander Kiselev
2016-04-20 14:19 ` Wiles, Keith
2016-05-02 19:38 ` Александр Киселев
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).