[Pcsclite-muscle] CCID: Reduce status change latency by using the status from RDR_to_PC_NotifySlotChange?

[Ludovic Rousseau]

Hello Ran,

Sorry for the delay. Your email was in my spam folder.

Le mer. 11 déc. 2024 à 21:41, Ran Benita <ran at unusedvar.com> a écrit :
>
> For readers which support it, the CCID driver listens for
> RDR_to_PC_NotifySlotChange notifications on the interrupt endpoint. This
> replaces the need for polling. When a RDR_to_PC_NotifySlotChange notification
> is received, the CCID driver then issues a PC_to_RDR_GetSlotStatus to get the
> new status and notify the application.
>
> However, the RDR_to_PC_NotifySlotChange already contains the new status of the
> slot(s). If the CCID driver were to use it, it could skip the
> PC_to_RDR_GetSlotStatus roundtrip, thereby removing the 10-20ms latency it
> adds (by my measurement with a couple of readers) before the application gets
> the status change. IMO, 10-20ms latency for SCardGetStatusChange, while not a
> lot, is not insignificant.

I tried with a Gemalto PC Twin reader and I do not get the same numbers.

03806987 [140463466800832] ../src/ccid_usb.c:1618:InterruptRead() after (0) (0)
00000029 [140463466800832] NotifySlotChange: 50 03
00000009 [140463466800832] ../src/ifdhandler.c:1983:IFDHICCPresence()
usb:08e6/3437:libudev:0:/dev/bus/usb/001/006 (lun: 0)
00000005 [140463466800832] -> 000000 65 00 00 00 00 00 0A 00 00 00
00000400 [140463466800832] <- 000000 81 00 00 00 00 00 0A 01 00 00
00000005 [140463466800832] ../src/ifdhandler.c:2109:IFDHICCPresence()
Card present

The PC_to_RDR_GetSlotStatus command takes 400 µs to be treated by the reader.

I also tried with a Alcor Micro AU9540 and this time the first
PC_to_RDR_GetSlotStatus command needs 9925 µs (~10 ms).
The next PC_to_RDR_GetSlotStatus command requires only 796 µs.

If your readers need 20 ms then maybe you have a problem with your readers.
What readers have you used?
Are they contactless readers?
Can you provide traces as described in https://pcsclite.apdu.fr/#support ?

> What are your opinion on this idea? As a proof of concept, I modified
> `InterruptRead` to return the new status to `IFDHPolling`, which stashes it in
> the `CcidSlots`; then `IFDHICCPresence` uses this status, if it is set,
> instead of calling `CmdGetSlotStatus`. This seems to work from rudimentary
> testing, although there is some business with `bPowerFlags` that I haven't
> gotten to the bottom of. Hopefully someone more familiar with the code can do
> it properly, if the idea is sound.

It should work.
It would add complexity to the driver for a (very) limited gain.

Bye

-- 
 Dr. Ludovic Rousseau