> -----Original Message-----
> From: Intel-wired-lan <[email protected]> On Behalf Of
> Larysa Zaremba
> Sent: Friday, May 16, 2025 7:58 AM
> To: [email protected]; Nguyen, Anthony L
> <[email protected]>
> Cc: David S. Miller <[email protected]>; Eric Dumazet
> <[email protected]>; Jakub Kicinski <[email protected]>; Paolo Abeni
> <[email protected]>; Simon Horman <[email protected]>; Jonathan
> Corbet <[email protected]>; Kitszel, Przemyslaw
> <[email protected]>; Jiri Pirko <[email protected]>; Nikolova,
> Tatyana
> E <[email protected]>; Andrew Lunn <[email protected]>;
> Lobakin, Aleksander <[email protected]>; Michael Ellerman
> <[email protected]>; Fijalkowski, Maciej <[email protected]>;
> Lee Trager <[email protected]>; Madhavan Srinivasan <[email protected]>;
> Zaremba, Larysa <[email protected]>; Samudrala, Sridhar
> <[email protected]>; Keller, Jacob E <[email protected]>;
> Michal Swiatkowski <[email protected]>; Polchlopek,
> Mateusz <[email protected]>; Zaki, Ahmed
> <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]; Karlsson, Magnus
> <[email protected]>; Tantilov, Emil S <[email protected]>;
> Chittim, Madhu <[email protected]>; Hay, Joshua A
> <[email protected]>; Olech, Milena <[email protected]>; Linga,
> Pavan Kumar <[email protected]>; Singhai, Anjali
> <[email protected]>; Kubiak, Michal <[email protected]>
> Subject: [Intel-wired-lan] [PATCH iwl-next v4 09/15] idpf: refactor idpf to
> use
> libie control queues
>
> From: Pavan Kumar Linga <[email protected]>
>
> 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.
>
> 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.
>
> The changes are fairly trivial and localized, with a notable exception
> being the consolidation of idpf_vc_xn_shutdown and idpf_deinit_dflt_mbx
> under the latter name. This has some additional consequences that are
> addressed in the following patches.
>
> 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: Michal Kubiak <[email protected]>
> Signed-off-by: Pavan Kumar Linga <[email protected]>
> Co-developed-by: Larysa Zaremba <[email protected]>
> Signed-off-by: Larysa Zaremba <[email protected]>
> ---
> 2.47.0
Tested-by: Samuel Salin <[email protected]>
