Hi Yusuf,
Comments inline as [SGM]
On 25/02/2017 15:32, yusuf khan wrote:
Hi,
comments inline as [YK]
Br,
Yusuf
On Sat, Feb 25, 2017 at 12:27 AM, Kinsella, Ray
<ray.kinse...@intel.com <mailto:ray.kinse...@intel.com>> wrote:
inline
On 24/02/2017 16:56, yusuf khan wrote:
Hi,
On my test setup, which is server machine with Intel(R)
Xeon(R) CPU
E5-2680 v3 @ 2.50GHz and 16GB RAM. I am comparing dpdk aesni_mb
l2fwd-crypto decryption results with VPP dpdk-esp-decrypt
node. I see 1
Mpps difference. l2wd-crypto can process 3 Mpps(size 168) but
vpp dpdk
crypto can only process around 2 Mpps.
Right but there is no comparison in terms of L2 feature support,
the DPDK code is sample code only, VPP is a full l2 stack.
[YK] VPP without ipsec(encryption) can process around 12 Mpps, beyond
that mostly H/W has limitations(82599 Nic). L2fwd-crypto can do
around 3 Mpps. I took basic assumption of Greatest common divisor,
which is 3 Mpps.
[SGM] Are you comparing VPP IPsec to DPDK l2fwd-crypto or ipsec-secgw
sample app?
- l2fwd-crypto is not doing IPsec, it just blindly encrypt
packets.
- ipsec-secgw is not a full l2/l3 stack and is missing some
IPsec features.
So neither are implementing the same functionality, but ipsec-secgw does
the ESP encap/decap, etc.
There is 1 Mpps difference. May be due to the fact that
dpdk-input and
crypto-input are process on the same core?
Well VPP does a double pass to route the encrypted packet, that
the DPDK IPSEC sample code does not do, but again I would argue
that is behaviour you want.
[YK] May be i can try null encryption test and see the impact. That
would still be double pass but without encryption.
[SGM] For the null encryption test, you are probably better of faking
the capabilities (ie. fake support of AES-CBC/SHA) on the NULL crypto
PMD (you would need to patch DPDK NULL crypto PMD for this) as it is not
yet supported by VPP IPsec.
Is it possible to run dpdk-esp-decrypt node on another core
just for
encryption decryption. This way we can avoid re-ordering of
the packets
and at the same time use multicore for single ipsec flow.
Each core run's an entire copy of the VPP stack, you can't break a
pipeline up over multiple core's easily AFAIK.
[YK] It is similar to I/O and worker thread concept where I/O thread
has input graph node(i guess) and rest of the node with worker thread.
But i guess now I/O thread model is deprecated!
Pipeline model of graph node might not be straight forward but may be
needed to leverage multiple cores for single flow. Otherwise with
current model handling ordering is very complicated.
[SGM] AFAIK VPP has already pipeline support for INPUT/OUTPUT nodes (old
I/O thread model and Hierarchical QOS), not so much INTERNAL nodes.
That is to say that there is already infra to do INPUT/OUTPUT pipeline
but probably new infra would be required to do it on any node.
Even if you were to re-enable the I/O thread model, you would still have
the ordering issue to take care of.
Sergio
Ray K
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
