[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20141015.165421.2180002967619380071.davem@davemloft.net>
Date: Wed, 15 Oct 2014 16:54:21 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: claudiu.manoil@...escale.com
Cc: netdev@...r.kernel.org, kotnes@...co.com
Subject: Re: [net] gianfar: Add FCS to rx buffer size (fix)
From: Claudiu Manoil <claudiu.manoil@...escale.com>
Date: Wed, 15 Oct 2014 19:11:46 +0300
> For each Rx frame the eTSEC writes its FCS (Frame Check Sequence)
> to the Rx buffer.
>
> The eTSEC h/w manual states in the "Receive Buffer Descriptor Field
> Descriptions" table:
> "Data length is the number of octets written by the eTSEC into this BD's
> data buffer if L is cleared (the value is equal to MRBLR), or, if L is
> set, the length of the frame including *CRC*, FCB (if RCTRL[PRSDEP > 00),
> preamble (if MACCFG2[PreAmRxEn]=1), time stamp (if RCTRL[TS] = 1) and
> any padding (RCTRL[PAL])."
>
> Though the FCS bytes are removed by the driver before passing the skb
> to the net stack, the Rx buffer size computation does not currently
> take into account the FCS bytes (4 bytes).
> Because the Rx buffer size is multiple of 512 bytes, leaving out the
> FCS is not a problem for the default MTU of 1500, as the Rx buffer size
> is 1536 in this case. However, for custom MTUs, where the difference
> between the MTU size and the Rx buffer size is less, this can be a
> problem as the computed Rx buffer size won't be enough to accomodate
> the FCS for a received frame that is big enough (close to MTU size).
> In such case the received frame is considered to be incomplete (L flag
> not set in the RxBD status) and silently dropped.
>
> Note that the driver does not currently support S/G on Rx, so it has to
> compute its Rx buffer size based on the MTU of the device.
>
> Reported-by: Kristian Otnes <kotnes@...co.com>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@...escale.com>
Applied, thanks!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists