netdev - RE: [EXT] Re: [PATCH net-next v2 6/8] octeon_ep_vf: add Tx/Rx processing and interrupt support

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: 
 <PH0PR18MB473450986CAA852218F225F0C7662@PH0PR18MB4734.namprd18.prod.outlook.com>
Date: Fri, 5 Jan 2024 07:26:14 +0000
From: Shinas Rasheed <srasheed@...vell.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: "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>,
        "horms@...nel.org" <horms@...nel.org>,
        "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

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?