with apply and build
Using patch: lng-odp_PATCH_v2_test_performance_add_crypto_test.mbox
Trying to apply patch
Patch applied
WARNING: 'Imediately' may be misspelled - perhaps 'Immediately'?
#645: FILE: test/performance/odp_crypto.c:582:
+ print_mem("Imediately encrypted packet", mem,
total: 0 errors, 1 warnings, 0 checks, 958 lines checked
And compiling
odp_crypto.c: In function ‘create_session_from_config’:
odp_crypto.c:428:33: error: storage size of ‘ses_create_rc’ isn’t known
enum odp_crypto_ses_create_err ses_create_rc;
^
odp_crypto.c:428:33: error: unused variable ‘ses_create_rc’
[-Werror=unused-variable]
odp_crypto.c: In function ‘main’:
odp_crypto.c:777:17: error: implicit declaration of function
‘odp_cpumask_def_worker’ [-Werror=implicit-function-declaration]
num_workers = odp_cpumask_def_worker(&cpumask,
^
odp_crypto.c:777:3: error: nested extern declaration of
‘odp_cpumask_def_worker’ [-Werror=nested-externs]
num_workers = odp_cpumask_def_worker(&cpumask,
^
odp_crypto.c:795:4: error: too few arguments to function
‘odph_linux_pthread_create’
odph_linux_pthread_create(&thr, &cpumask,
^
In file included from odp_crypto.c:20:0:
../../helper/include/odp/helper/linux.h:67:5: note: declared here
int odph_linux_pthread_create(odph_linux_pthread_t *thread_tbl,
^
cc1: all warnings being treated as errors
So it looks like it needs a rebase.
On 4 November 2015 at 10:07, Nicolas Morey-Chaisemartin <[email protected]>
wrote:
>
> On 11/04/2015 09:12 AM, [email protected] wrote:
> > From: Alexandru Badicioiu <[email protected]>
> >
> > Test program to measure crypto operation performance.
> > Measures the time required to launch and get the result
> > of ODP crypto operations in async and sync API mode with
> > configurable payload size, crypto algorithms and iteration
> > number.
> > Both asynchronous scheduled and polled are supported.
> > In scheduled mode a separate worker thread is used to
> > get the crypto completion events.
> > Output packet can be reused as the input of the next
> > operation or a new packet can be allocated for each
> > operation.
> > Based on a previous work :
> > https://lists.linaro.org/pipermail/lng-odp/2014-September/003251.html.
> >
> > Signed-off-by: Alexandru Badicioiu <[email protected]>
> > v1
> > ---
> > - replaced cspeed with crypto
> > - removed unused parameter core_count
> > v2
> > --
> > - alphabetical order in Makefile.am
> > - replaced pool params memset with init call
> >
> > ---
> > test/performance/Makefile.am | 5 +-
> > test/performance/odp_crypto.c | 935
> ++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 939 insertions(+), 1 deletion(-)
> > create mode 100644 test/performance/odp_crypto.c
>
> > +/**
> > + * Snap current time values and put them into 'rec'.
> > + */
> > +static void
> > +fill_time_record(time_record_t *rec)
> > +{
> > + gettimeofday(&rec->tv, NULL);
> > + getrusage(RUSAGE_SELF, &rec->ru_self);
> > + getrusage(RUSAGE_THREAD, &rec->ru_thread);
> This is *very* linux oriented and not platform agnostic.
> getrusage is POSIX 2001 (though we don't support it) but RUSAGE_THREAD is
> _GNU_SOURCE and kernel > 2.6.26
>
> Couldn't we use ODP API to keep track of time ?
>
Nicolas, in the call today we put out the idea that it would be better to
use an odp time api, but that maybe it was ok to use linux for now.
Re reading the patch I think this is problem since it will break on your
platform and not just be less clean, is that correct ?
> > +int main(int argc, char *argv[])
> > +{
> > + crypto_args_t cargs;
> > + odp_pool_t pool;
> > + odp_queue_param_t qparam;
> > + odp_pool_param_t params;
> > + odph_linux_pthread_t thr;
> > + odp_queue_t out_queue = ODP_QUEUE_INVALID;
> > + thr_arg_t thr_arg;
> > + int num_workers = 1;
> > + odp_cpumask_t cpumask;
> > + char cpumaskstr[ODP_CPUMASK_STR_SIZE];
> > +
> > + /* Parse and store the application arguments */
> > + parse_args(argc, argv, &cargs);
> > +
> > + /* Init ODP before calling anything else */
> > + if (odp_init_global(NULL, NULL)) {
> > + app_err("ODP global init failed.\n");
> > + exit(EXIT_FAILURE);
> > + }
> > +
> > + /* Init this thread */
> > + odp_init_local(ODP_THREAD_WORKER);
> > +
> > + /* Create packet pool */
> > + odp_pool_param_init(¶ms);
> > + params.pkt.seg_len = SHM_PKT_POOL_BUF_SIZE;
> > + params.pkt.len = SHM_PKT_POOL_BUF_SIZE;
> > + params.pkt.num = SHM_PKT_POOL_SIZE / SHM_PKT_POOL_BUF_SIZE;
> > + params.type = ODP_POOL_PACKET;
> > + pool = odp_pool_create("packet_pool", ¶ms);
> > +
> > + if (pool == ODP_POOL_INVALID) {
> > + app_err("packet pool create failed.\n");
> > + exit(EXIT_FAILURE);
> > + }
> > + odp_pool_print(pool);
> > +
> > + if (cargs.schedule) {
> > + qparam.sched.prio = ODP_SCHED_PRIO_DEFAULT;
> > + qparam.sched.sync = ODP_SCHED_SYNC_NONE;
> > + qparam.sched.group = ODP_SCHED_GROUP_ALL;
> > + out_queue = odp_queue_create("crypto-out",
> > + ODP_QUEUE_TYPE_SCHED,
> &qparam);
> > + } else if (cargs.poll) {
> > + out_queue = odp_queue_create("crypto-out",
> > + ODP_QUEUE_TYPE_POLL, NULL);
> > + }
> > + if (cargs.schedule || cargs.poll) {
> > + if (out_queue == ODP_QUEUE_INVALID) {
> > + app_err("crypto-out queue create failed.\n");
> > + exit(EXIT_FAILURE);
> > + }
> > + }
> > +
> > + if (cargs.schedule) {
> > + printf("Run in async scheduled mode\n");
> > +
> > + thr_arg.crypto_args = cargs;
> > + thr_arg.crypto_alg_config = cargs.alg_config;
> > + num_workers = odp_cpumask_def_worker(&cpumask,
> > + num_workers);
> > + (void)odp_cpumask_to_str(&cpumask, cpumaskstr,
> > + sizeof(cpumaskstr));
> > + printf("num worker threads: %i\n",
> > + num_workers);
> > + printf("first CPU: %i\n",
> > + odp_cpumask_first(&cpumask));
> > + printf("cpu mask: %s\n",
> > + cpumaskstr);
> It would be good to have an option for the number of workerds (or a core
> bitmask), as was recently added to odp_l2fwd
>
Sounds sensible
> > + } else if (cargs.poll) {
> > + printf("Run in async poll mode\n");
> > + } else {
> > + printf("Run in sync mode\n");
> > + }
> > +
> > + if (cargs.alg_config) {
> > + if (cargs.schedule) {
> > + odph_linux_pthread_create(&thr, &cpumask,
> > + run_thr_func, &thr_arg);
> > + odph_linux_pthread_join(&thr, num_workers);
> > + } else {
> > + run_measure_one_config(&cargs, cargs.alg_config);
> > + }
> Why is there only multithreading in schedule mode?
>
Not sure, Alex is there a technical reason ?
> _______________________________________________
> lng-odp mailing list
> [email protected]
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
