[PATCH 5/7] sfc: Work around XMAC bug causing packet loss with some peers

[PATCH 5/7] sfc: Work around XMAC bug causing packet loss with some peers

[Ben Hutchings]

Received frames must be re-clocked by the local XGXS to the 156.25 MHz
(DDR) clock of the XGMII.  If the remote clock is slightly faster this
can reduce a minimum IPG of 64 bit-times (1 cycle) to 32 bit-times
(half a cycle).  If the XMAC detects that a frame has reached the
maximum RX frame length in the same cycle that it receives one of
these reduced IPGs, it may miss the IPG, causing two valid frames to
be treated as a single invalid frame (over-length with bad CRC).

We work around this by increasing the maximum RX frame length so that
peers with matched MTU will not provoke this bug.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
 drivers/net/sfc/net_driver.h |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/drivers/net/sfc/net_driver.h b/drivers/net/sfc/net_driver.h
index 5eabede..298566d 100644
--- a/drivers/net/sfc/net_driver.h
+++ b/drivers/net/sfc/net_driver.h
@@ -984,9 +984,14 @@ static inline void clear_bit_le(unsigned nr, unsigned char *addr)
  *
  * The 10G MAC used in Falcon requires 8-byte alignment on the frame
  * length, so we round up to the nearest 8.
+ *
+ * Re-clocking by the XGXS on RX can reduce an IPG to 32 bits (half an
+ * XGMII cycle).  If the frame length reaches the maximum value in the
+ * same cycle, the XMAC can miss the IPG altogether.  We work around
+ * this by adding a further 16 bytes.
  */
 #define EFX_MAX_FRAME_LEN(mtu) \
-	((((mtu) + ETH_HLEN + VLAN_HLEN + 4/* FCS */) + 7) & ~7)
+	((((mtu) + ETH_HLEN + VLAN_HLEN + 4/* FCS */ + 7) & ~7) + 16)
 

 #endif /* EFX_NET_DRIVER_H */

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [PATCH 5/7] sfc: Work around XMAC bug causing packet loss with some peers

[David Miller]

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 26 Aug 2009 19:17:59 +0100

> Received frames must be re-clocked by the local XGXS to the 156.25 MHz
> (DDR) clock of the XGMII.  If the remote clock is slightly faster this
> can reduce a minimum IPG of 64 bit-times (1 cycle) to 32 bit-times
> (half a cycle).  If the XMAC detects that a frame has reached the
> maximum RX frame length in the same cycle that it receives one of
> these reduced IPGs, it may miss the IPG, causing two valid frames to
> be treated as a single invalid frame (over-length with bad CRC).
> 
> We work around this by increasing the maximum RX frame length so that
> peers with matched MTU will not provoke this bug.
> 
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>

Applied.