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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Thursday, April 27, 2023 1:32 PM To: Ken Liu <Ken.Liu@arm.commailto:Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Wednesday, April 26, 2023 9:01 PM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Thursday, April 27, 2023 7:02 AM To: tf-m@lists.trustedfirmware.orgmailto: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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Wednesday, April 26, 2023 12:56 PM To: tf-m@lists.trustedfirmware.orgmailto: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.