xsk-tx-metadata.rst 3.4 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485
  1. .. SPDX-License-Identifier: GPL-2.0
  2. ==================
  3. AF_XDP TX Metadata
  4. ==================
  5. This document describes how to enable offloads when transmitting packets
  6. via :doc:`af_xdp`. Refer to :doc:`xdp-rx-metadata` on how to access similar
  7. metadata on the receive side.
  8. General Design
  9. ==============
  10. The headroom for the metadata is reserved via ``tx_metadata_len`` and
  11. ``XDP_UMEM_TX_METADATA_LEN`` flag in ``struct xdp_umem_reg``. The metadata
  12. length is therefore the same for every socket that shares the same umem.
  13. The metadata layout is a fixed UAPI, refer to ``union xsk_tx_metadata`` in
  14. ``include/uapi/linux/if_xdp.h``. Thus, generally, the ``tx_metadata_len``
  15. field above should contain ``sizeof(union xsk_tx_metadata)``.
  16. Note that in the original implementation the ``XDP_UMEM_TX_METADATA_LEN``
  17. flag was not required. Applications might attempt to create a umem
  18. with a flag first and if it fails, do another attempt without a flag.
  19. The headroom and the metadata itself should be located right before
  20. ``xdp_desc->addr`` in the umem frame. Within a frame, the metadata
  21. layout is as follows::
  22. tx_metadata_len
  23. / \
  24. +-----------------+---------+----------------------------+
  25. | xsk_tx_metadata | padding | payload |
  26. +-----------------+---------+----------------------------+
  27. ^
  28. |
  29. xdp_desc->addr
  30. An AF_XDP application can request headrooms larger than ``sizeof(struct
  31. xsk_tx_metadata)``. The kernel will ignore the padding (and will still
  32. use ``xdp_desc->addr - tx_metadata_len`` to locate
  33. the ``xsk_tx_metadata``). For the frames that shouldn't carry
  34. any metadata (i.e., the ones that don't have ``XDP_TX_METADATA`` option),
  35. the metadata area is ignored by the kernel as well.
  36. The flags field enables the particular offload:
  37. - ``XDP_TXMD_FLAGS_TIMESTAMP``: requests the device to put transmission
  38. timestamp into ``tx_timestamp`` field of ``union xsk_tx_metadata``.
  39. - ``XDP_TXMD_FLAGS_CHECKSUM``: requests the device to calculate L4
  40. checksum. ``csum_start`` specifies byte offset of where the checksumming
  41. should start and ``csum_offset`` specifies byte offset where the
  42. device should store the computed checksum.
  43. Besides the flags above, in order to trigger the offloads, the first
  44. packet's ``struct xdp_desc`` descriptor should set ``XDP_TX_METADATA``
  45. bit in the ``options`` field. Also note that in a multi-buffer packet
  46. only the first chunk should carry the metadata.
  47. Software TX Checksum
  48. ====================
  49. For development and testing purposes its possible to pass
  50. ``XDP_UMEM_TX_SW_CSUM`` flag to ``XDP_UMEM_REG`` UMEM registration call.
  51. In this case, when running in ``XDK_COPY`` mode, the TX checksum
  52. is calculated on the CPU. Do not enable this option in production because
  53. it will negatively affect performance.
  54. Querying Device Capabilities
  55. ============================
  56. Every devices exports its offloads capabilities via netlink netdev family.
  57. Refer to ``xsk-flags`` features bitmask in
  58. ``Documentation/netlink/specs/netdev.yaml``.
  59. - ``tx-timestamp``: device supports ``XDP_TXMD_FLAGS_TIMESTAMP``
  60. - ``tx-checksum``: device supports ``XDP_TXMD_FLAGS_CHECKSUM``
  61. See ``tools/net/ynl/samples/netdev.c`` on how to query this information.
  62. Example
  63. =======
  64. See ``tools/testing/selftests/bpf/xdp_hw_metadata.c`` for an example
  65. program that handles TX metadata. Also see https://github.com/fomichev/xskgen
  66. for a more bare-bones example.