-
Notifications
You must be signed in to change notification settings - Fork 546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamically load/unload xdp dll #3770
Conversation
Codecov Report
@@ Coverage Diff @@
## main #3770 +/- ##
==========================================
- Coverage 75.59% 75.56% -0.04%
==========================================
Files 56 56
Lines 15554 15554
==========================================
- Hits 11758 11753 -5
- Misses 3796 3801 +5 |
Out of curiosity, why is run-time linking better than load time linking in our context? From some light research, with load time linking you can bundle everything into a self-contained executable and performance wise load time linking is a bit better (correct me if I am wrong). Happy to learn something new! |
b7e3c60
to
700c12d
Compare
Yup, absolutely, load time linking can perform more performance optimizations and some of them are quite valuable, especially with Spectre mitigations. The reason we want run-time linking is to (eventually) allow MsQuic to use XDP if it happens to be installed and available on the system, and otherwise use regular sockets. If the XDP DLL isn't present on the system, then load-time linking will prevent the MsQuic DLL from loading, which we do not want. |
Ahh I see, thanks! So in the past, we just always assumed XDP was always available, otherwise MsQuic.dll wouldn't have been able to load. |
Description
Use
XdpLoadApi
which uses run-time linking instead ofXdpOpenApi
which uses load-time linking.Testing
CI/CD
Documentation
No.