linux-kernel - Re: [Intel-wired-lan] [PATCH iwl-next v2 08/14] idpf: refactor idpf to use libie controlq and Xn APIs

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aAticBsDuaKTvUtd@soc-5CG4396X81.clients.intel.com>
Date: Fri, 25 Apr 2025 12:22:40 +0200
From: Larysa Zaremba <larysa.zaremba@...el.com>
To: "Keller, Jacob E" <jacob.e.keller@...el.com>
CC: Paul Menzel <pmenzel@...gen.mpg.de>, "intel-wired-lan@...ts.osuosl.org"
	<intel-wired-lan@...ts.osuosl.org>, "Nguyen, Anthony L"
	<anthony.l.nguyen@...el.com>, "David S. Miller" <davem@...emloft.net>,
	"Dumazet, Eric" <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, "Jonathan
 Corbet" <corbet@....net>, "Kitszel, Przemyslaw"
	<przemyslaw.kitszel@...el.com>, Jiri Pirko <jiri@...nulli.us>, "Nikolova,
 Tatyana E" <tatyana.e.nikolova@...el.com>, Andrew Lunn
	<andrew+netdev@...n.ch>, "Lobakin, Aleksander"
	<aleksander.lobakin@...el.com>, Michael Ellerman <mpe@...erman.id.au>,
	"Fijalkowski, Maciej" <maciej.fijalkowski@...el.com>, Lee Trager
	<lee@...ger.us>, Madhavan Srinivasan <maddy@...ux.ibm.com>, "Samudrala,
 Sridhar" <sridhar.samudrala@...el.com>, Michal Swiatkowski
	<michal.swiatkowski@...ux.intel.com>, "Polchlopek, Mateusz"
	<mateusz.polchlopek@...el.com>, "Zaki, Ahmed" <ahmed.zaki@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Karlsson,
 Magnus" <magnus.karlsson@...el.com>, "Tantilov, Emil S"
	<emil.s.tantilov@...el.com>, "Chittim, Madhu" <madhu.chittim@...el.com>,
	"Hay, Joshua A" <joshua.a.hay@...el.com>, "Olech, Milena"
	<milena.olech@...el.com>, "Linga, Pavan Kumar" <pavan.kumar.linga@...el.com>,
	"Singhai, Anjali" <anjali.singhai@...el.com>, "Kubiak, Michal"
	<michal.kubiak@...el.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v2 08/14] idpf: refactor idpf
 to use libie controlq and Xn APIs

On Thu, Apr 24, 2025 at 05:37:47PM +0200, Keller, Jacob E wrote:
> > Am 24.04.25 um 13:32 schrieb Larysa Zaremba:
> > > From: Pavan Kumar Linga <pavan.kumar.linga@...el.com>
> > >
> > > Support to initialize and configure controlq, Xn manager,
> > > MMIO and reset APIs 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 send buffers. 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.
> > 
> > (You could reflow the text above to have consistent line length.)
> > 
> 
> I do see a few spots that don't look consistent. Its hard to say if this is just due to the way longer words like the function names line up or not without popping it into vim to double check... 

It is quite funny how you answered this with a line that does not fit on my 
screen in mutt :D

I admit, newlines are all over the place, probably as a consequence of editing 
this so many times in nano. I can reformat this, if it hurts people's eyes that 
much, though I do not consider this a problem if it fits the limit.