RARE user and assistance email list

[Frédéric LOUI <>]

Hi !

> please find attached the fest runs with dpdk and bmv2. news that we have 
> ipsec!
This is (un)expected (from you) ...

> we're wirespeed at gigabit on 1 core of a i7-3770, and enabling ipsec 
> bumped from 70% 10 130%.
I’d be curious to push this code on 10GE / 100GE NIC server … 

Anyone have this in their closet ?

> it's quite high starting because the host did the iperf that means dpdk had 
> to use pcap to get the packets...

Let’s see if we reproduce the test but without the host generating packet ...

À bientôt,
--  Frederic




> Le 5 sept. 2020 à 17:34, mc36 <> a écrit :
> 
> hi,
> please find attached the fest runs with dpdk and bmv2. news that we have 
> ipsec!
> we're wirespeed at gigabit on 1 core of a i7-3770, and enabling ipsec 
> bumped from 70% 10 130%.
> it's quite high starting because the host did the iperf that means dpdk had 
> to use pcap to get the packets...
> regards,
> cs
> 
> 
> On 9/5/20 7:16 AM, mc36 wrote:
>> hi,
>> please find attached the fresh test runs with bmv2 and dpdk.
>> news is macsec support in p4emu (dpdk, pcap).
>> and even better news is that on a 7 years old i7-3770 it's does gigabit on 
>> 1 cpucore with aes256+sha1!
>> and every interface could have it's own receiver and transmitter core 
>> associated in dpdk...
>> in case of pcap, every interface by default have an own thread to process 
>> packets from the interface...
>> in the i7 case, iperfing at gigabit used 20% 1cpu then enabling macsec 
>> bumped it to 120%. (it used p4dpdk)
>> the opposite was a xeon, iperfing at gigabit used 70% 1cpu then enabling 
>> macsec bumped it to 170% (it used p4pcap, this is why it have so high 
>> initial cpu)
>> so we can safely say that enabling crypto on adds about a five multiplied 
>> to the load so divides the performance by five.
>> regarding the implementation, i linked against libcrypto (from openssl) 
>> and to maintain
>> full locklessness, i reinitalize the thread's own crypto contexts for 
>> every packet.
>> (did a quick testing with common contexts and did now saw any gain in 
>> performance,
>> but there could be algorithms that have much more expensive init 
>> functions:)
>> regarding the rest of the dataplanes, nor bmv2 nor tofino have
>> no crypto at all so until that changes, it'll be p4emu specific...
>> regarding the future plans, obviously i'll go for ipsec!
>> once that happens, we'll have an enterprise grade cpe.... :)
>> regards,
>> cs
> <rtrp4lang-bmv2-.csv><rtrp4lang-bmv2-.html><rtrp4lang-dpdk-.csv><rtrp4lang-dpdk-.html>