You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, each Rx/Tx ring in XDP allow for only a single buffer. This value is not configurable, and some code in Rx/TxRing relies on the assumption that only one buffer is allocated. This prevents more than one packet from being sent or received concurrently.
Proposed Solution
Rx/Tx fill and completion ring sizes should be configurable. Additionally, the Rx/Tx ring size and the number of user memory buffers should be decoupled, able to be configured separately. Ideally, user memory buffers would be over-allocated for high throughput systems (at least the sum of the size of the completion and fill rings for each end of the socket).
Alternative Solutions
Potentially one could create additional sockets with one buffer, but the overhead per socket likely outweighs the overhead of more buffers per socket.
The text was updated successfully, but these errors were encountered:
kyleholohan
changed the title
[Catpowder] Support more than one concurrent packet per ring in XDP
[Catpowder] Windows: Support more than one concurrent packet per ring in XDP
Oct 10, 2024
Context
Currently, each Rx/Tx ring in XDP allow for only a single buffer. This value is not configurable, and some code in Rx/TxRing relies on the assumption that only one buffer is allocated. This prevents more than one packet from being sent or received concurrently.
Proposed Solution
Rx/Tx fill and completion ring sizes should be configurable. Additionally, the Rx/Tx ring size and the number of user memory buffers should be decoupled, able to be configured separately. Ideally, user memory buffers would be over-allocated for high throughput systems (at least the sum of the size of the completion and fill rings for each end of the socket).
Alternative Solutions
Potentially one could create additional sockets with one buffer, but the overhead per socket likely outweighs the overhead of more buffers per socket.
The text was updated successfully, but these errors were encountered: