On 18 February 2016 at 13:58, Gábor Sándor Enyedi <
gabor.sandor.eny...@ericsson.com> wrote:
> 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.
>
2. This is just a bug in API, and should be fixed by adding some way to
> change the crypto key.
> 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. :)
>
> Please confirm that #1 is the correct answer.
>
> Gabor
>
Unfortunately the method in which crypto session is created/destroyed is
implementation specific it might be faster but I personally wouldn't bet on
this. Since as discussed earlier the idea of crypto session is only to
reuse the parameters during odp_cryto_operation() function for better
performance so crypto session create/destroy might not be upto the mark
required in a fast path execution.
IMO there is two possible ways to address your use-case,
1. add override_cipher_key and override_auth_key parameters to
odp_crypto_op_params_t struct which is an input to odp_cryto_operations()
function so that if these value is a not-null then the implementation will
override the values in crypto session but the drawback of this approach is
that then for general use-case where the cipher/auth key is same per
session the implementation will always have to check the
override_cipher_key/override_auth_key parameter which actually is just a
simple check but since this code runs in fast path and it is per packet
might impact the performance.
2. A more preferable approach in my point of view is to add a new API
odp_crypto_operation_key() where cipher key and auth key are given as input
parameter along with session so that the applications which need to pass
individual cipher/auth key per user can use this new API so that the
performance of odp_crypto_operation() is not changed.
your suggestions/ comments are most welcome and I will send an RFC based on
option 2 for further discussion and you can provide your comments on the
same.
Regards,
Bala
>
>
> 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> 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> 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
>>> 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
