af_xdp: Fix wakeup channel mismatch causing performance degradation#305
Open
akiyano wants to merge 1 commit intoXilinx-CNS:masterfrom
Open
af_xdp: Fix wakeup channel mismatch causing performance degradation#305akiyano wants to merge 1 commit intoXilinx-CNS:masterfrom
akiyano wants to merge 1 commit intoXilinx-CNS:masterfrom
Conversation
When AF_XDP sockets are bound to non-zero hardware queues, applications experience severe throughput degradation (e.g., 9 Gbps drops to 20 Mbps). Problem: The efrm_vi_get_channel() function calculates wakeup channels using RSS modulo arithmetic: `instance % rss_channel_count`. For AF_XDP devices, rss_channel_count is hardcoded to 1, causing all VI instances to map to wakeup channel 0, regardless of their actual hardware queue binding. This creates a mismatch where: - AF_XDP socket correctly binds to hardware queue N - Packets arrive at hardware queue N - But application wakeup notifications are sent to event queue 0 - Application relies on periodic polling (90ms timeout) instead of immediate event-driven wakeups Root Cause: AF_XDP uses direct queue selection via ntuple rules rather than RSS distribution, making the RSS-based wakeup channel calculation incorrect. Solution: Add AF_XDP-specific logic to use direct 1:1 mapping where the wakeup channel equals the VI instance number, ensuring proper alignment between packet arrival queue and application wakeup channel. Testing: - Before: Queue 4 traffic = 20 Mbps (450x degradation) - After: Queue 4 traffic = 9 Gbps (full performance restored) - Queue 0 performance unaffected (was already working correctly)
akiyano
force-pushed
the
fix_wakeup_channel_mismatch
branch
from
70f985a to
2acaf1d
Compare
akiyano
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When trying to use onload with AF_XDP, performance degrades significantly if the flow steering choses queue != 0 (from 9Gbps to 20 Mbps)
This also means that If we want to use more than 1 queue to push more traffic we can't (only queue 0 is usable)
The attached commit fixes these issues.