Re: [PATCH net-next] net: mscc: allow extracting the FCS into the skb

[Antoine Tenart]

Hi FLorian,

On Mon, Oct 01, 2018 at 09:35:45AM -0700, Florian Fainelli wrote:
> On 10/01/2018 02:57 AM, Antoine Tenart wrote:
> >  
> >  	memcpy(dev->dev_addr, ocelot->base_mac, ETH_ALEN);
> > diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c
> > index 3cdf63e35b53..245452a0f244 100644
> > --- a/drivers/net/ethernet/mscc/ocelot_board.c
> > +++ b/drivers/net/ethernet/mscc/ocelot_board.c
> > @@ -126,11 +126,16 @@ static irqreturn_t ocelot_xtr_irq_handler(int irq, void *arg)
> >  			len += sz;
> >  		} while (len < buf_len);
> >  
> > -		/* Read the FCS and discard it */
> > +		/* Read the FCS */
> >  		sz = ocelot_rx_frame_word(ocelot, grp, false, &val);
> >  		/* Update the statistics if part of the FCS was read before */
> >  		len -= ETH_FCS_LEN - sz;
> >  
> Don't this needs to be len -= sz;

No, part of the FCS could be read in the loop before. This subtraction
removes those bytes from the stats.

> > +		if (unlikely(dev->features & NETIF_F_RXFCS)) {
> > +			buf = (u32 *)skb_put(skb, ETH_FCS_LEN);
> > +			*buf = val;
> 
> and here len -= ETH_FCS_LEN

len doesn't contain the FCS len at this point, no need to remove it
again. The extraction logic is already designed to drop the FCS and to
not count it in the stats, this patch makes use of it depending on
NETIF_F_RXFCS.

> since "len" is later used for accounting how many bytes have been
> received by the network device?

The question could be "do we need len += ETH_FCS_LEN" to account for the
FCS when NETIF_F_RXFCS is used", but I looked at other drivers and it
seemed to me the FCS is not accounted in the stats. Should it be?

> I am bit confused by the use of "buf", but presumably if NETIF_F_RXCFS
> is turned on, the FCS needs to be part of the buffer passed to the
> network stack, so adjusting len accordingly is required anyway.

This is the way we extract the data to the skb, I'm following the same
logic (I could use buf++ as well, as it's done in the loop before).

Thanks!
Antoine

-- 
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com