Hi Brian,

Thanks, will try it locally first and then see why.

BTW, there would be 5 days public holiday for most team members so the response would be delayed to next Thursday at least, sorry.

/Ken

From: Quach, Brian <brian@ti.com>
Sent: Friday, April 28, 2023 2:44 AM
To: Ken Liu <Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: RE: psa_call performance

Hi Ken,

I forgot to mention I’m using “medium profile” with GCC compiler.

-DTFM_PROFILE=profile_medium \

-DTFM_ISOLATION_LEVEL=1 \

-DCMAKE_BUILD_TYPE=Debug \

Regards,
Brian

From: Quach, Brian via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Thursday, April 27, 2023 1:32 PM
To: Ken Liu <Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [EXTERNAL] [TF-M] Re: psa_call performance

Hi Ken,

I created my own IPC-based secure partition and service for testing.  Within the SP, the psa call only saves the DWT cycle count so I can measure time to and from the psa call (DWT cycle count is also recorded before and after the PSA call on the NSPE). 

For you to reproduce it, I think it’s easiest to create a simple IPC-based partition and call the psa_connect().  Capture the cycle count before and after the call to determine the delta.  I observed psa_connect() call time is now ~6000 cycles (previously ~3400 cycles in TF-M v1.1).

void my_sp_main(void *param)

{

    uint32_t signals = 0;

    psa_msg_t msg;

    psa_status_t r;

    while (1)

    {

        signals = psa_wait(PSA_WAIT_ANY, PSA_BLOCK);

        if (signals & MY_SP_SERVICE_SIGNAL)

        {

            psa_get(MY_SP_SERVICE_SIGNAL, &msg);

            switch (msg.type)

            {

                case PSA_IPC_CONNECT:

                    if (inuse)

                    {

                        r = PSA_ERROR_CONNECTION_REFUSED;

                    }

                    else

                    {

                        inuse      = 1;

                        myClientId = msg.client_id;

                        r          = PSA_SUCCESS;

                    }

                    psa_reply(msg.handle, r);

                    break;

           }

      }

}

Regards,
Brian

From: Ken Liu via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, April 26, 2023 9:01 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [EXTERNAL] [TF-M] Re: psa_call performance

Hi Brian,

Could you provide more details about the test? Which configuration are you using (a profile or customized configurations) and which service you are using for the testing?

Or provide the build command?

Thanks.

/Ken

From: Quach, Brian via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Thursday, April 27, 2023 7:02 AM
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Re: psa_call performance

I also observed psa_connect() call time is now ~6000 cycles (previously ~3400 cycles in TF-M v1.1).

Regards,
Brian

From: Quach, Brian via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, April 26, 2023 12:56 PM
To: tf-m@lists.trustedfirmware.org
Subject: [EXTERNAL] [TF-M] psa_call performance

Hi,

Using isolation level 1 and IPC secure partition, I noticed psa_call() overhead for TFM v1.7 is significantly worse for than v1.1.   Is this expected?

Assuming 1 invec and 0 outvec for the PSA call….

TF-M version	Psa_call() round trip cycles
v1.1	4038
v1.7	6051

Regards,

Brian Quach

SimpleLink MCU

Texas Instruments Inc.