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: <20240105110508.GU31813@kernel.org>
Date: Fri, 5 Jan 2024 11:05:08 +0000
From: Simon Horman <horms@...nel.org>
To: Shinas Rasheed <srasheed@...vell.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Haseeb Gani <hgani@...vell.com>,
	Vimlesh Kumar <vimleshk@...vell.com>,
	Sathesh B Edara <sedara@...vell.com>,
	"egallen@...hat.com" <egallen@...hat.com>,
	"mschmidt@...hat.com" <mschmidt@...hat.com>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"wizhao@...hat.com" <wizhao@...hat.com>,
	"kheib@...hat.com" <kheib@...hat.com>,
	"konguyen@...hat.com" <konguyen@...hat.com>,
	Veerasenareddy Burru <vburru@...vell.com>,
	Satananda Burla <sburla@...vell.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>
Subject: Re: [EXT] Re: [PATCH net-next v2 6/8] octeon_ep_vf: add Tx/Rx
 processing and interrupt support

On Fri, Jan 05, 2024 at 07:26:14AM +0000, Shinas Rasheed wrote:
> Hi Jakub,
> 
> Thanks for the review!
> 
> > > +	rx_done = octep_vf_oq_process_rx(ioq_vector->oq, budget);
> > 
> > You should not call Rx processing if budget is 0 at all, please see
> > NAPI docs. Looks like the function may try to refill Rx buffers with
> > budget of 0.
> > 
> If budget is zero, octep_vf_oq_process_rx just wouldn't try to query hw for packets. Also since by then, the refill count should have been less than refill threshold, if not it only flushes free buffers back to the ring, (and tell hw that there are more free buffers available which have been processed from maybe previous calls - but this seems unlikely and should have been flushed at that time). 
> 
> > > @@ -114,8 +158,8 @@ static int octep_vf_setup_oq(struct octep_vf_device
> > *oct, int q_no)
> > >  		goto desc_dma_alloc_err;
> > >  	}
> > >
> > > -	oq->buff_info = (struct octep_vf_rx_buffer *)
> > > -			vzalloc(oq->max_count *
> > OCTEP_VF_OQ_RECVBUF_SIZE);
> > > +	oq->buff_info = vzalloc(oq->max_count *
> > OCTEP_VF_OQ_RECVBUF_SIZE);
> > > +
> > 
> > bad fixup squash?
> > 
> Sorry, I didn't understand. Can you explain?

I think he means that this change seems to make a minor update
to code introduced in a previous patch of this series, and thus should
be squashed into that previous patch.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ