[2/3] Integrate XSK maps into the core XDP datapath#6003
[2/3] Integrate XSK maps into the core XDP datapath#6003ProjectsByJackHe wants to merge 36 commits into
Conversation
Codecov Report❌ Patch coverage is
❌ Your patch check has failed because the patch coverage (60.00%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #6003 +/- ##
==========================================
+ Coverage 84.88% 85.05% +0.16%
==========================================
Files 60 60
Lines 18797 18802 +5
==========================================
+ Hits 15956 15992 +36
+ Misses 2841 2810 -31 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Planning on waiting until #6006 gets resolved to address the next wave of feedback. |
|
It's not clear to me why we don't have end-to-end tests exercising everything from providing the XSKMAP before creating a registration through actual XDP data paths flowing? Since we intend to officially support this feature, it is risky for both us and our partners to supply/depend on an API that does not have regression test coverage and a paved pattern to follow. |
That's in the works. I took the approach of building up an E2E flow manually first to see the shape of how the datapath integration would look like. There's likely going to be some limitations in the CI environment that prevents some scenarios from being exercised, but I am currently adding coverage for the parts that can be automated now that the skeleton of the general changes is mapped out in the current PR iteration. |
|
Let's ensure we add tests with each chunk of work we do. I understand it may be a lot of work to add tests, but the best time to protect the code with automation and review the coverage is when making the change. |
tests all working now
XDP needs to release a new driver version consumable by MsQuic in the CI before I can push my tests. I have them right now working over a local VM with the latest xdp drivers installed, and find that everything is working. |
|
Either we merge #6034 (or wait until the next XDP release) to add automated coverage, or having a one-off manual dispatch for the tests + manual local VM runs is good enough to give confidence to merge this integration. Let's decide on this first and align timelines. Currently, the map tests are pushed for review, but disabled. |
| { config: "Debug", plat: "windows", os: "windows-2022", arch: "x64", tls: "schannel", sanitize: "-SanitizeAddress", build: "-Test", log: "Full.Verbose" }, | ||
| { config: "Debug", plat: "windows", os: "windows-2022", arch: "x64", tls: "schannel", xdp: "-UseXdp", sanitize: "-SanitizeAddress", build: "-Test" }, | ||
| { config: "Debug", plat: "windows", os: "windows-2022", arch: "x64", tls: "schannel", xdp: "-UseXdp", qtip: "-UseQtip", sanitize: "-SanitizeAddress", build: "-Test" }, | ||
| # { config: "Debug", plat: "windows", os: "windows-2022", arch: "x64", tls: "schannel", xdp: "-UseXdp", xdpmapmode: "-XdpMapMode", sanitize: "-SanitizeAddress", build: "-Test", testfilter: "XdpMapMode*" }, # Disabled until CI has XDP driver with map mode support |
There was a problem hiding this comment.
Un-comment this when we figure out how to ingest the latest XDP version properly.
| inline | ||
| bool | ||
| QUIC_API | ||
| ListenerAcceptConnectionBasic( |
There was a problem hiding this comment.
This should not be in a precomp header.
Don't we already have helpers for this? (auto-accept listener?)
| QUIC_STATUS GetLocalAddr(_Out_ QuicAddr &localAddr); | ||
| QUIC_STATUS GetStatistics(_Out_ QUIC_LISTENER_STATISTICS &stats); | ||
|
|
||
| HQUIC GetListener() const { return QuicListener; } |
There was a problem hiding this comment.
Extend the class with the helpers you need rather than exposing the handle
| // | ||
| // Server port rules. | ||
| // | ||
| if (Params.UseCibir) { |
There was a problem hiding this comment.
This is not the place or file to setup the XDP rule.
This file list tests (and probably already deserved to be split).
Make a new file for rule configuration helpers, and consider invoking your helper at the beginning of the test function rather than hidden in the fixture.
Fixture are good for generic setup that doesn't matter to the test logic, but it makes test hard to understand when it causes important setup to be out of sight.
| // enabled for all sockets. Reject an explicit XdpEnabled = FALSE since | ||
| // it contradicts map mode — there is no OS datapath to fall back to. | ||
| // | ||
| if (Source->IsSet.XdpEnabled && |
There was a problem hiding this comment.
nit: Style, would likely fit on a line.
| if ($DuoNic) { | ||
| $TestArguments += " -DuoNic" | ||
| } | ||
| if ($XdpMapMode) { |
There was a problem hiding this comment.
nit: Follow the pattern $useXdp already established above for enabling duonic and xdp
(assuming we do need a map mode here)
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
no need for these 3 extra contexts.
| _In_ bool UseQtip | ||
| ) | ||
| { | ||
| UNREFERENCED_PARAMETER(UseQtip); // QTIP is configured globally by the fixture |
There was a problem hiding this comment.
If it isn't used, it doesn't need to be a parameter.
| // | ||
| // Open a bidirectional stream and send a small ping payload. | ||
| // | ||
| auto Stream = |
There was a problem hiding this comment.
This is the only difference with the handshake test?
Why do we need the two? This one is a strict superset, but also doesn't bring extra validation since once we connection is established, using map or not has no impact over sending stream frames.
| // and inserts them into the XSKMAPs we provided. | ||
| // | ||
| { | ||
| MsQuicRegistration TempReg("XdpMapModeInit"); |
There was a problem hiding this comment.
Won't the registration used by the test do that anyway?
| } | ||
| #endif | ||
| #if defined(_WIN32) | ||
| if (UseXdpMapMode) { |
There was a problem hiding this comment.
I don't think that relying on the global environment and test parameters is a good approach.
It can work for things that are basically re-running the entire test suite in different conditions like XDP.
But here, this is only for a few specific tests.
This should be part of the fixture for those specific tests (or in a RAII helper called at the start of the test).
Having so much conditional in the test setup cannot scale.
Description
Full E2E demo using tools from this PR : DEMO
Part 2 of the plan: #5982
Fixes #5972
Adds the core msquic datapath integrations for the new API contract defined in #5983
Key design decisions:
Testing
Added datapath unit tests. See the E2E demo.
It's going to be extremely difficult to add automation to exercise what I did in the E2E demo.
Documentation
Will come as part 3 in the plan: #5982