[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8e7c3649-c0e5-4660-9068-336518cd07a8@intel.com>
Date: Tue, 20 Feb 2024 08:23:13 -0800
From: Alan Brady <alan.brady@...el.com>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
CC: <intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
<willemdebruijn.kernel@...il.com>, <przemyslaw.kitszel@...el.com>,
<igor.bagnucki@...el.com>, Joshua Hay <joshua.a.hay@...el.com>
Subject: Re: [PATCH v4 01/10 iwl-next] idpf: implement virtchnl transaction
manager
On 2/20/2024 6:30 AM, Alexander Lobakin wrote:
> From: Alan Brady <alan.brady@...el.com>
> Date: Mon, 5 Feb 2024 19:37:55 -0800
>
>> This starts refactoring how virtchnl messages are handled by adding a
>> transaction manager (idpf_vc_xn_manager).
>
> [...]
>
>> +/**
>> + * idpf_vc_xn_exec - Perform a send/recv virtchnl transaction
>> + * @adapter: driver specific private structure with vcxn_mngr
>> + * @params: parameters for this particular transaction including
>> + * -vc_op: virtchannel operation to send
>> + * -send_buf: kvec iov for send buf and len
>> + * -recv_buf: kvec iov for recv buf and len (ignored if NULL)
>> + * -timeout_ms: timeout waiting for a reply (milliseconds)
>> + * -async: don't wait for message reply, will lose caller context
>> + * -async_handler: callback to handle async replies
>> + *
>> + * @returns >= 0 for success, the size of the initial reply (may or may not be
>> + * >= @recv_buf.iov_len, but we never overflow @@recv_buf_iov_base). < 0 for
>> + * error.
>> + */
>> +static ssize_t idpf_vc_xn_exec(struct idpf_adapter *adapter,
>> + struct idpf_vc_xn_params params)
>
> Why do you pass @params by value, i.e. whole 56 bytes per each function
> call instead of passing it by pointer -> 8 bytes per call?
>
Not for any particularly good reason. I will fix thanks.
Powered by blists - more mailing lists