Check out my first novel, midnight's simulacra!
Io uring and xdp enter 2024: Difference between revisions
(Created page with "Last year (2023), I spent significant time writing code using XDP and io_uring. The latter was delightful, the former less so. My summary of io_uring through liburing 2.3 hit #1 on HackerNews (twice!) and the great [https://lwn.net LWN], which pleased me. Work on these technologies has progressed, and it seems time for an update. ==XDP== One of the big problems I had with <tt>AF_XDP</tt> sockets was the lack of support for large packets. One could typically only...") |
No edit summary |
||
| Line 3: | Line 3: | ||
==XDP== | ==XDP== | ||
One of the big problems I had with <tt>AF_XDP</tt> sockets was the lack of support for large packets. One could typically only use an MTU of 3KB and some change, putting XDP at a disadvantage relative to systems which happily process 8KB frames. One must supply <tt>XDP_USE_SG</tt>, and supply <tt>xdp.frags</tt> as the program's section name. A single RXring frame might not hold the entire packet, in which case it will be written across several ring frames (with attendant multiple RXring descriptors). The <tt>XDP_PKT_CONTD</tt> flag is set in the <tt>options</tt> field if there are more frames. They will always be written in order, and if there are insufficient frames to write all data, none will be written. | One of the big problems I had with <tt>AF_XDP</tt> sockets was the lack of support for large packets. One could typically only use an MTU of 3KB and some change, putting XDP at a disadvantage relative to systems which happily process 8KB frames. One must supply <tt>XDP_USE_SG</tt>, and supply <tt>xdp.frags</tt> as the program's section name. A single RXring frame might not hold the entire packet, in which case it will be written across several ring frames (with attendant multiple RXring descriptors). The <tt>XDP_PKT_CONTD</tt> flag is set in the <tt>options</tt> field if there are more frames. They will always be written in order, and if there are insufficient frames to write all data, none will be written. | ||
==io_uring== | |||
Easily the most exciting development is integration of futexes (Jens Axboe 2023-07-20 [https://lwn.net/Articles/938800/ "Add io_uring futex/futexv support"]). | |||
==See also== | ==See also== | ||
* [https://elixir.bootlin.com/linux/latest/source/Documentation/networking/af_xdp.rst AF_XDP] kernel documentation | * [https://elixir.bootlin.com/linux/latest/source/Documentation/networking/af_xdp.rst AF_XDP] kernel documentation | ||
Revision as of 02:43, 14 February 2024
Last year (2023), I spent significant time writing code using XDP and io_uring. The latter was delightful, the former less so. My summary of io_uring through liburing 2.3 hit #1 on HackerNews (twice!) and the great LWN, which pleased me. Work on these technologies has progressed, and it seems time for an update.
XDP
One of the big problems I had with AF_XDP sockets was the lack of support for large packets. One could typically only use an MTU of 3KB and some change, putting XDP at a disadvantage relative to systems which happily process 8KB frames. One must supply XDP_USE_SG, and supply xdp.frags as the program's section name. A single RXring frame might not hold the entire packet, in which case it will be written across several ring frames (with attendant multiple RXring descriptors). The XDP_PKT_CONTD flag is set in the options field if there are more frames. They will always be written in order, and if there are insufficient frames to write all data, none will be written.
io_uring
Easily the most exciting development is integration of futexes (Jens Axboe 2023-07-20 "Add io_uring futex/futexv support").
See also
- AF_XDP kernel documentation
