Skip to content

[2/3] Integrate XSK maps into the core XDP datapath#6003

Open
ProjectsByJackHe wants to merge 36 commits into
mainfrom
jackhe/xdp_map_dp_int_pr_2_core
Open

[2/3] Integrate XSK maps into the core XDP datapath#6003
ProjectsByJackHe wants to merge 36 commits into
mainfrom
jackhe/xdp_map_dp_int_pr_2_core

Conversation

@ProjectsByJackHe
Copy link
Copy Markdown
Contributor

@ProjectsByJackHe ProjectsByJackHe commented May 18, 2026

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:

  • If map mode is enabled, then we do not create the WinSock or Epoll or .... datapaths. No more best effort!
  • Init failures in map mode hard fails the datapath initialization. No silent failures!

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

@codecov
Copy link
Copy Markdown

codecov Bot commented May 18, 2026

Codecov Report

❌ Patch coverage is 60.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.05%. Comparing base (f87bfd3) to head (9716cef).

Files with missing lines Patch % Lines
src/core/settings.c 33.33% 2 Missing ⚠️

❌ 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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Comment thread submodules/xdp-for-windows
Comment thread src/inc/quic_datapath.h Outdated
Comment thread src/inc/quic_datapath.h Outdated
Comment thread src/platform/datapath_raw_win.c Outdated
Comment thread src/platform/datapath_raw_xdp_win.c Outdated
Comment thread src/platform/platform_internal.h
Comment thread src/platform/platform_internal.h Outdated
@ProjectsByJackHe
Copy link
Copy Markdown
Contributor Author

Planning on waiting until #6006 gets resolved to address the next wave of feedback.

Comment thread src/platform/datapath_raw_xdp_win.c Outdated
Comment thread src/platform/datapath_raw_xdp_win.c Outdated
@mtfriesen
Copy link
Copy Markdown
Contributor

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.

@ProjectsByJackHe
Copy link
Copy Markdown
Contributor Author

ProjectsByJackHe commented May 20, 2026

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.

@mtfriesen
Copy link
Copy Markdown
Contributor

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.

Comment thread src/core/settings.c Outdated
Comment thread src/inc/quic_datapath.h Outdated
Comment thread src/platform/datapath_raw_dummy.c Outdated
Comment thread src/platform/datapath_raw_xdp_win.c Outdated
Comment thread src/platform/datapath_raw_xdp_win.c
Comment thread src/platform/datapath_winuser.c Outdated
Comment thread src/platform/datapath_xplat.c Outdated
Comment thread src/platform/platform_internal.h Outdated
Comment thread src/platform/datapath_xplat.c Outdated
Comment thread src/platform/datapath_xplat.c Outdated
Comment thread src/platform/datapath_xplat.c Outdated
@ProjectsByJackHe
Copy link
Copy Markdown
Contributor Author

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.

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.

@ProjectsByJackHe
Copy link
Copy Markdown
Contributor Author

ProjectsByJackHe commented May 28, 2026

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
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Un-comment this when we figure out how to ingest the latest XDP version properly.

Comment thread src/test/lib/precomp.h
inline
bool
QUIC_API
ListenerAcceptConnectionBasic(
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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; }
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extend the class with the helpers you need rather than exposing the handle

//
// Server port rules.
//
if (Params.UseCibir) {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread src/core/settings.c
// 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 &&
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Style, would likely fit on a line.

Comment thread scripts/test.ps1
if ($DuoNic) {
$TestArguments += " -DuoNic"
}
if ($XdpMapMode) {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Follow the pattern $useXdp already established above for enabling duonic and xdp
(assuming we do need a map mode here)

Comment on lines +5018 to +5020
}
}
}
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no need for these 3 extra contexts.

_In_ bool UseQtip
)
{
UNREFERENCED_PARAMETER(UseQtip); // QTIP is configured globally by the fixture
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it isn't used, it doesn't need to be a parameter.

Comment thread src/test/lib/DataTest.cpp
//
// Open a bidirectional stream and send a small ping payload.
//
auto Stream =
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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");
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't the registration used by the test do that anyway?

}
#endif
#if defined(_WIN32)
if (UseXdpMapMode) {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The XDP datapath must use XDP maps instead of XDP programs when maps are provided

3 participants