[dpdk-dev] L3FWD LPM IP lookup performance question

Chris Pappas chrispappas12 at gmail.com
Thu Sep 26 23:16:12 CEST 2013


Hi,

we are having some numbers regarding the performance of L3FWD and would
like to confirm that they make sense.
So, for L3FWD and 1500byte packets we get 120Gbps out of 12x10Gbps ports
(so we get full throughput) and for 64byte packets we get 80Gbps.

According to Intel documentation [1] these numbers make sense, but we would
like to double check. Is there any information regarding the lookup method
in the forwarding table for LPM lookup? Also, we used a forwarding table
with 500K entries, which fits totally in L3 cache, so there shouldn't be
any delays because of cache misses (which again is in compliance with our
results and Intel documentation). Is the size of the forwarding table
normal or did we use a very small one (or does anyone know how many entries
the forwarding table that was used for Intel's performance numbers)?

[1]
http://www.intel.com/content/dam/www/public/us/en/documents/solution-briefs/communications-packet-processing-brief.pdf
Best regards,
Chris


On Tue, Sep 24, 2013 at 5:53 PM, Vincent JARDIN <vincent.jardin at 6wind.com>wrote:

> I do not know any open source implementation of an efficient LPM. FYI,
> some data with a commercial one:
>   -> up to 160Mpps, the bottleneck was the IOs, not the CPU.
>   http://www.6wind.com/products/**6windgate-protocols/ip-**forwarding/<http://www.6wind.com/products/6windgate-protocols/ip-forwarding/>
>
> Best regards,
>   Vincent
>
>
> On 24/09/2013 15:53, Jun Han wrote:
>
>> Hello,
>>
>> We are trying to benchmark L3FWD application and have a question regarding
>> the IP lookup algorithm as we expect the bottleneck to be at the lookup.
>> Could someone let us know how efficient the lookup algorithm that L3FWD is
>> using (e.g, LPM)? We are asking because we want to obtain highest L3
>> forwarding performance number, and we might need to change the lookup
>> method if the current LPM method is not as efficient.
>>
>> Thank you very much,
>>
>> Jun
>>
>>
>


More information about the dev mailing list