SNP Spams Receive calls

[paulober]

Hi there,
i'm currently working on a SNP Driver for a GEM. Since I got my GetStatus and other functions fixed I now get spamed with Receive calls where i always have to return an EFI_NOT_READY because Transmit gets not even called once and where should the pckts come from...
Any idea why this could be happening?
I also think these calls are blocking so much that most of the time I can't use UEFI shell anymore because after 2 or 3 chars it would stop responding to any keyboard inputs. I fixed an issue where GetStatus was always returning EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT, but that didn't stop the spaming of SNP Receive calls to my driver.

Any ideas on how to work on this issue?

[mdkinney]

The network stack uses UEFI Timer Events to poll for network traffic. If the timer period is close to or smaller than the execution time of your GetStatus() function, then you can get a live lock condition because all the execution time is in UEFI timer event handling with none left over for TPL_APPLICATION. If you have DEBUG() messages in your GetStatus() path, then try disabling those and make sure your GetStatus() function the fastest check possible.

[paulober]

The network stack uses UEFI Timer Events to poll for network traffic. If the timer period is close to or smaller than the execution time of your GetStatus() function, then you can get a live lock condition because all the execution time is in UEFI timer event handling with none left over for TPL_APPLICATION. If you have DEBUG() messages in your GetStatus() path, then try disabling those and make sure your GetStatus() function the fastest check possible.

Many thanks. This did solve my GetStatus spaming issue though I have some other smaller issue so I want to make sure I don't have this timing issue anymore:
GetStatus: ~815462ns
Receive: ~3805555ns-6148759ns
ReceiveFilters: ~22222ns
Transmit: ~3685000ns-4046148ns-8988722ns

What do you think of these execution times. (Note that it only shows the execution times for call where the whole function has been executed)
In the UEFI shell I still get the keyboard just not respond after a few chars or it will lock up and spam the last char pressed or XhciSched.c assert will crash edk2.
Or if i remove any debug from "Receive":

XhcStopEndpoint: Stop Endpoint Failed, Status = Time out
XhcDequeueTrbFromEndpoint: Stop Endpoint Failed, Status = Time out
XhcTransfer[Type=1]: XhcDequeueTrbFromEndpoint failed!
XhcControlTransfer: error - Time out, transfer - 0

[mdkinney]

UEFI Driver Writer's Guide has a section on this topic:

https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/4_general_driver_design_guidelines/42_maximize_platform_compatibility/429_reduce_poll_frequency.html#429-reduce-poll-frequency