Hi Uvarov, Problem has been fixed, thanks. As I re-write the makefile of ODP on aarch64 of SUSE11, the TEST_THRMASK macro was missed, which caused this compiling failure.
Thank you very much. -----邮件原件----- 发件人: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] 代表 lng-odp-requ...@lists.linaro.org 发送时间: 2016年2月18日 18:03 收件人: lng-odp@lists.linaro.org 主题: lng-odp Digest, Vol 23, Issue 207 Send lng-odp mailing list submissions to lng-odp@lists.linaro.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.linaro.org/mailman/listinfo/lng-odp or, via email, send a message with subject or body 'help' to lng-odp-requ...@lists.linaro.org You can reach the person managing the list at lng-odp-ow...@lists.linaro.org When replying, please edit your Subject line so it is more specific than "Re: Contents of lng-odp digest..." Today's Topics: 1. Re: [QUESTION] test: validation:thread: some functions cannot be found (Maxim Uvarov) 2. Re: crypto contexts (Bala Manoharan) 3. Re: crypto contexts (Bala Manoharan) ---------------------------------------------------------------------- Message: 1 Date: Thu, 18 Feb 2016 12:54:42 +0300 From: Maxim Uvarov <maxim.uva...@linaro.org> To: lng-odp@lists.linaro.org Subject: Re: [lng-odp] [QUESTION] test: validation:thread: some functions cannot be found Message-ID: <56c594e2.2070...@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed On 02/18/16 12:09, Xu Zaibo wrote: > > Hi, > > In my compiling test validation, some functions, such as > ‘thread_test_odp_thrmask_and’, ’ thread_test_odp_thrmask_or’…. cannot > be found and failed. > > And I search these function in the home directory of ODP, but get > nothing. So, is it the problem of ‘validation/thread.c’? > > Zaibo Xu > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp Hello Xu, if it compiles than code is in. Take a look at: ./test/validation/common/mask_common.h #define MASK_API_PREFIX(n) odp_thrmask_##n #define MASK_TESTFUNC(n) void thread_test_odp_thrmask_##n(void) Can you please provide log and conditions where it fails? ./test/validation/thread/thread_main.log: Test: thread_test_odp_thrmask_and ...passed Thank you, Maxim. ------------------------------ Message: 2 Date: Thu, 18 Feb 2016 15:25:20 +0530 From: Bala Manoharan <bala.manoha...@linaro.org> To: Gábor Sándor Enyedi <gabor.sandor.eny...@ericsson.com> Cc: "lng-odp@lists.linaro.org" <lng-odp@lists.linaro.org> Subject: Re: [lng-odp] crypto contexts Message-ID: <CAGr7dC1A=jR0j5uFCaj4H3XNzbKC4MRRC5CO=91u8nmuwt-...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" 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 >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linaro.org/pipermail/lng-odp/attachments/20160218/2ab52cb4/attachment-0001.html> ------------------------------ Message: 3 Date: Thu, 18 Feb 2016 15:32:41 +0530 From: Bala Manoharan <bala.manoha...@linaro.org> To: Nikhil Agarwal <nikhil.agar...@nxp.com> Cc: Hemant Agrawal <hemant.agra...@nxp.com>, "lng-odp@lists.linaro.org" <lng-odp@lists.linaro.org> Subject: Re: [lng-odp] crypto contexts Message-ID: <cagr7dc2xwg83cmb1dsm6zp5yj4kuav51kh2polgzvaajqto...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Nikhil, On 18 February 2016 at 15:24, Nikhil Agarwal <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] *On Behalf > Of *Gábor Sándor Enyedi > *Sent:* Thursday, February 18, 2016 1:58 PM > *To:* Bala Manoharan <bala.manoha...@linaro.org> > *Cc:* 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> 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 > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linaro.org/pipermail/lng-odp/attachments/20160218/7821fce3/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp ------------------------------ End of lng-odp Digest, Vol 23, Issue 207 **************************************** _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
