[dpdk-dev] [PATCH v6 00/10] examples/ipsec-secgw: make app to use ipsec library
Ananyev, Konstantin
konstantin.ananyev at intel.com
Fri Jan 4 18:04:59 CET 2019
> On 1/4/2019 5:59 PM, Ananyev, Konstantin wrote:
> > Hi Akhil,
> >
> >> Hi Konstantin,
> >>
> >> With this patchset, I am seeing a 3% drop in legacy mode lookaside and
> >> 12% drop with -l option.
> >> I am debugging this. Will let you know if I find something.
> > Ok, thanks.
> > For legacy mode do you know which patch in the series causing 3% drop?
> > Is it still: " fix crypto-op might never get dequeued" or a different one?
> > Konstantin
> >
> for legacy mode you may consider this diff in 3/10
>
> diff --git a/examples/ipsec-secgw/ipsec-secgw.c
> b/examples/ipsec-secgw/ipsec-secgw.c
> index 4f7a77d8d..d183862b8 100644
> --- a/examples/ipsec-secgw/ipsec-secgw.c
> +++ b/examples/ipsec-secgw/ipsec-secgw.c
> @@ -1015,10 +1015,13 @@ main_loop(__attribute__((unused)) void *dummy)
>
> if (nb_rx > 0)
> process_pkts(qconf, pkts, nb_rx, portid);
> - }
> +// }
>
> - drain_inbound_crypto_queues(qconf, &qconf->inbound);
> - drain_outbound_crypto_queues(qconf, &qconf->outbound);
> + if (UNPROTECTED_PORT(portid))
> + drain_inbound_crypto_queues(qconf,
> &qconf->inbound);
> + else
> + drain_outbound_crypto_queues(qconf,
> &qconf->outbound);
> + }
> }
> }
>
> The 3% gap was on single core performance. But on multi cores scenario,
> there is no significant drop.
>
> But I see a bigger functional problem in case of non-legacy mode.
> I am trying a multi tunnel scenario with 32 kind of flows on one side
> each with different tunnels.
> The flows are kind of dest ip: 192.168.101.1 ........... 192.168.x.1
> ......... 192.168.132.1.
> Each IP has a different tunnel.
> All are pumped from same port. I can see that some of the IPs are not
> getting forwarded.
> like 192.168.103.1, 192.168.104.1, 192.168.105.1, 192.168.114.1,
> 192.168.115.1, 192.168.116.1, 192.168.122.1, 192.168.125.1,
> 192.168.126.1, 192.168.130.1
>
> The same setup/flows works perfectly fine with legacy mode.
I'll try to reproduce it on my box.
To clarify:
you are using one core, one port.
each dest ip assigned to different SA
(i.e. for dst=192.168.103.1, spi=1, dst=192.168.104.1, spi=2, ...)
and for some SAs packets are not forwarded.
I presume each rx burst contains packets from different SAs.
correct?
Is that failure for inbound or outbound packets or both?
Any particular details about mode(tunnel/transport), algorithm?
Thanks
Konstantin
More information about the dev
mailing list