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 on send and receive in Catpowder for Windows, DemiBuffer content is copied to/from the allocated XDP umem region. This creates an additional unnecessary copy on the data path.
Proposed Solution
Leverage the XDP umem "headroom" configuration to allocate a pool of DemiBuffers on initialization of the LibOS. On sgaalooc/sgafree, allocate and free buffers directly from the umem pool. On send/receive path, avoid the additional copy by putting/pulling the DemiBuffer packet content directly into/from the Tx/Rx queues.
Alternative Solutions
The solution could be left as is to reduce coupling between components at the cost of the additional copy. Alternatively, DemiBuffer metadata could point to the umem pool, and the metadata/data association could be reformed through some pointer-based lookup on receive.
The text was updated successfully, but these errors were encountered:
Context
Currently on send and receive in Catpowder for Windows, DemiBuffer content is copied to/from the allocated XDP umem region. This creates an additional unnecessary copy on the data path.
Proposed Solution
Leverage the XDP umem "headroom" configuration to allocate a pool of DemiBuffers on initialization of the LibOS. On sgaalooc/sgafree, allocate and free buffers directly from the umem pool. On send/receive path, avoid the additional copy by putting/pulling the DemiBuffer packet content directly into/from the Tx/Rx queues.
Alternative Solutions
The solution could be left as is to reduce coupling between components at the cost of the additional copy. Alternatively, DemiBuffer metadata could point to the umem pool, and the metadata/data association could be reformed through some pointer-based lookup on receive.
The text was updated successfully, but these errors were encountered: