Hi,
I admit that our use-case is very special, and getting traffic from 100K
users at the same time is the worst case scenario (however, this is not
impossible, especially with IoT), but some 100s of users at the same
time may easily happen. For x86 DPDK+libcrypto, we use one
EVP_CIPHER_CTX per thread, and change the key for each packet (and get
quite a good performance). I don't know if changing the key is as simple
for other architectures as that is for x86, where we have no HW support...
Gabor
On 02/18/2016 11:02 AM, Bala Manoharan wrote:
Hi Nikhil,
On 18 February 2016 at 15:24, Nikhil Agarwal <nikhil.agar...@nxp.com
<mailto:nikhil.agar...@nxp.com>> wrote:
Hi,
It seems none of your statement is true. Comments inline.
It is platform implementation specific that how many crypto
sessions it supports. If it does not support required number of
sessions, then only way out as of today is to create n destroy
session.
Bala,
If this is a generic use-case, shall a light weight modify
session API be considered to be added, as 100K session might be
costly to maintain, provided they are used only once in a long run?
Agreed.100K session might be very costly to maintain and might defeat
the purpose of creating crypto session. The user in that case might
very well given all the session parameters to odp_crypto_operation()
function.
IMO modify crypto session might not be a good idea since there might
be packets inflight which are using a particular session and changing
the session parameter creates ambiguity for packets under processing.
Regards,
Bala
Regards
Nikhil
*From:*lng-odp [mailto:lng-odp-boun...@lists.linaro.org
<mailto:lng-odp-boun...@lists.linaro.org>] *On Behalf Of *Gábor
Sándor Enyedi
*Sent:* Thursday, February 18, 2016 1:58 PM
*To:* Bala Manoharan <bala.manoha...@linaro.org
<mailto:bala.manoha...@linaro.org>>
*Cc:* lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org>
*Subject:* Re: [lng-odp] crypto contexts
OK, so back to the original question: I have up to ~100K users
(but always higher than 32 by orders of magnitude) all with its
own crypto key. In worst case, all of them are sending packets at
the same time, so I need to decrypt a lot of packets from other
users, before I face a packet from the same user again, so I
cannot have 'n' different sessions. Since I cannot change the
crypto key, the only way to do this is creating and destroying a
session per packet. I looked into the x86 code, and it seemed that
the code was intentionally written in a way that session
create/destroy is relatively quick, since there is no malloc and
free and crypto contexts are not destroyed at all.
I think, there are three possibilities at this point:
1. ODP was intentionally designed in the way that
creating/destroying crypto session is fast, i.e. I can expect that
this is a cheap operation on each platform.
[Nikhil] This is implementation specific, and cannot be guaranteed
to be fast on each platform.(As this is supposed to be one time
API per session)
2. This is just a bug in API, and should be fixed by adding some
way to change the crypto key.
[Nikhil] You cannot change crypto key for a session.
3. There is already some solution, which I don't know... E.g. the
cipher_key.data field in the session is just a pointer, one
possibility is changing the memory content at the address where it
points to. :)
[Nikhil] There is no way as of today that you can modify crypto
keys of a session.
Please confirm that #1 is the correct answer.
Gabor
On 02/17/2016 05:56 PM, Bala Manoharan wrote:
Hi,
Crypto key in crypto session cannot be changed and in this
case you need 'n' different crypto sessions only and it cannot
be reused.
Regards,
Bala
On 17 February 2016 at 21:11, Gábor Sándor Enyedi
<gabor.sandor.eny...@ericsson.com
<mailto:gabor.sandor.eny...@ericsson.com>> wrote:
How can you change the crypto key? Each user has its own.
Gabor
On 02/17/2016 12:13 PM, Bala Manoharan wrote:
Hi,
There is no need to create a crypto session for each
packet. The application needs to create a crypto
session for a unique cipher/auth key (ie all the
parameters in odp_crypto_session_params_t ).
A crypto session is created so that application can
create a crypto session and reuse it for packets which
need similar processing. The parameters of crypto
session are as follows
typedef struct odp_crypto_session_params {
odp_crypto_op_t op; /**< Encode versus decode */
odp_bool_t auth_cipher_text; /**<
Authenticate/cipher ordering */
odp_crypto_op_mode_t pref_mode; /**< Preferred sync
vs async */
odp_cipher_alg_t cipher_alg; /**< Cipher algorithm */
odp_crypto_key_t cipher_key; /**< Cipher key */
odp_crypto_iv_t iv; /**< Cipher Initialization
Vector (IV) */
odp_auth_alg_t auth_alg; /**< Authentication
algorithm */
odp_crypto_key_t auth_key; /**< Authentication key */
odp_queue_t compl_queue; /**< Async mode
completion event queue */
odp_pool_t output_pool; /**< Output buffer pool */
} odp_crypto_session_params_t
If you see the odp_crypto_operation() function it
reuses an existing crypto session and only provides
parameters which are unique per packet (ie cipher/auth
range, input packet, etc )
The limit of 32 crypto sessions is a limitation on the
linux-generic implementation and this value might
depend on individual platforms.
Regards,
Bala
On 16 February 2016 at 18:40, Gábor Sándor Enyedi
<gabor.sandor.eny...@ericsson.com
<mailto:gabor.sandor.eny...@ericsson.com>> wrote:
Hi,
I want to keep up IPSec connections with up to
~100K users simultaneously. After looking into the
code, it seems that both linux-generic and
odp-dpdk can allocate at most 32 crypto sessions
(with odp_crypto_session_create). Please confirm,
that this is not a bug, but crypto sessions are
considered to be a very limited resource and an
ODP application should create and destroy a crypto
session for each packet, when all the users are
sending traffic at the same time.
Thanks,
Gabor
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
<mailto:lng-odp@lists.linaro.org>
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
