RARE user and assistance email list

[mc36 <>]

hi,

On 9/5/20 5:56 PM, Frédéric LOUI wrote:
> 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 ?
yeahh that would be great because in my setup i use 4x1gbps etherchannels 
between my nodes
that means that i have 1gbps between exactly the same endpoints, especially 
when crypto hides
the packet's internals from the switches...

> > 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 
> ...
i call exactly the same libcrypto evp_* calls in exactly the same order as 
with macsec so i not expect big differences here...
as i see, on this i7-3770 we can do about 1gigs easily on one cputhread 
easily if that's a dpdk interface and not a pcap...
from that, the above mentioned 7 years old cpu could do 8threads * 1gbps = 
8gbps... which is nice, but it's an i7...:)

regards,

cs


> À 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>