summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorPavan Kumar Linga <pavan.kumar.linga@intel.com>2026-06-25 18:02:03 +0200
committerTony Nguyen <anthony.l.nguyen@intel.com>2026-08-12 13:56:51 -0700
commitdeaada4f18072181faf2bc1665fed0db9569b923 (patch)
tree5bc993dce1a414298dec5ecdaacfc9f9406a8f87 /tools/perf/scripts/python
parent6b284aa2ddf36bd1e728a25de1c8c0793003c528 (diff)
idpf: refactor idpf to use libie control queues
Support to initialize and configure controlqs, and manage their transactions was introduced in libie. As part of it, most of the existing controlq structures are renamed and modified. Use those APIs in idpf and make all the necessary changes. Previously for the send and receive virtchnl messages, there used to be a memcpy involved in controlq code to copy the buffer info passed by the send function into the controlq specific buffers. There was no restriction to use automatic memory in that case. The new implementation in libie removed copying of the send buffer info and introduced DMA mapping of the send buffer itself. To accommodate it, use dynamic memory for the larger send buffers. For smaller ones (<= 128 bytes) libie still can copy them into the pre-allocated message memory. Those changes result in a pretty big diff, but the changes are fairly trivial and localized. In case of receive, idpf receives a page pool buffer allocated by the libie and care should be taken to release it after use in the idpf. idpf_idc_rdma_vc_send_sync() no longer truncates oversized responses or zeroes *recv_len on error, but this was confirmed to have no practical impact for any existing callers. This refactoring introduces roughly additional 40KB of module storage used for systems that only run idpf, so idpf + libie_cp + libie_pci takes about 7% more storage than just idpf before refactoring. We now pre-allocate small TX buffers, so that does increase the memory usage, but reduces the need to allocate. This results in additional 256 * 128B of memory permanently used, increasing the worst-case memory usage by 32KB but our ctlq RX buffers need to be of size 4096B anyway (not changed by the patchset), so this is hardly noticeable. As for the timings, the fact that we are mostly limited by the HW response time which is far from instant, is not changed by this refactor. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions