lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ