Subject: Re: [PATCH v4 iwl-net 3/3] ice: stop storing XDP verdict within ice_rx_buf

From: Maciej Fijalkowski <[email-masked]>
Date: Thu, 23 Jan 2025 11:51:06 +0100

On Thu, Jan 23, 2025 at 10:45:36AM +0000, Simon Horman wrote:
> On Wed, Jan 22, 2025 at 04:10:46PM +0100, Maciej Fijalkowski wrote:
> > Idea behind having ice_rx_buf::act was to simplify and speed up the Rx
> > data path by walking through buffers that were representing cleaned HW
> > Rx descriptors. Since it caused us a major headache recently and we
> > rolled back to old approach that 'puts' Rx buffers right after running
> > XDP prog/creating skb, this is useless now and should be removed.
> > 
> > Get rid of ice_rx_buf::act and related logic. We still need to take care
> > of a corner case where XDP program releases a particular fragment.
> > 
> > Make ice_run_xdp() to return its result and use it within
> > ice_put_rx_mbuf().
> > 
> > Fixes: 2fba7dc5157b ("ice: Add support for XDP multi-buffer on Rx side")
> > Reviewed-by: Przemek Kitszel <[email-masked]>
> > Signed-off-by: Maciej Fijalkowski <[email-masked]>
> > ---
> >  drivers/net/ethernet/intel/ice/ice_txrx.c     | 61 +++++++++++--------
> >  drivers/net/ethernet/intel/ice/ice_txrx.h     |  1 -
> >  drivers/net/ethernet/intel/ice/ice_txrx_lib.h | 43 -------------
> >  3 files changed, 35 insertions(+), 70 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c
> 
> ...
> 
> > @@ -1139,23 +1136,27 @@ ice_put_rx_buf(struct ice_rx_ring *rx_ring, struct ice_rx_buf *rx_buf)
> >   * returned by XDP program;
> >   */
> >  static void ice_put_rx_mbuf(struct ice_rx_ring *rx_ring, struct xdp_buff *xdp,
> > -			    u32 *xdp_xmit, u32 ntc)
> > +			    u32 *xdp_xmit, u32 ntc, u32 verdict)
> 
> Hi Marciej,
> 
> Sorry, there is one more Kernel doc nit. As reported by the Kernel Test
> Robot, verdict should be added to the Kernel doc for this function.

Yeah that is embarrassing. I have now included

./scripts/kernel-doc -none $FILE

to my pre-upstreaming checks so that it won't be happening again...
(or is there a way to run the kernel-doc against patch itself?)

> 
> With that addressed feel free to add:
> 
> Reviewed-by: Simon Horman <[email-masked]>

Thanks! Will include them in v5.

> ...