All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Tim Harvey <tharvey@gateworks.com>, David Miller <davem@davemloft.net>
Cc: netdev <netdev@vger.kernel.org>,
	Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Fugang Duan <fugang.duan@nxp.com>,
	Ilia Mirkin <imirkin@alum.mit.edu>
Subject: Re: DSA mv88e6xxx RX frame errors and TCP/IP RX failure
Date: Thu, 31 Aug 2017 19:41:41 +0200	[thread overview]
Message-ID: <20170831174141.GP22289@lunn.ch> (raw)
In-Reply-To: <CAJ+vNU0dq-ULUj3PbQH_biGviJURj2z5McCXx_vYxcB0k94WkA@mail.gmail.com>

> > I did fix an issue recently with that. See
> >
> > commit fbbeefdd21049fcf9437c809da3828b210577f36
> > Author: Andrew Lunn <andrew@lunn.ch>
> > Date:   Sun Jul 30 19:36:05 2017 +0200
> >
> >     net: fec: Allow reception of frames bigger than 1522 bytes
> >
> >     The FEC Receive Control Register has a 14 bit field indicating the
> >     longest frame that may be received. It is being set to 1522. Frames
> >     longer than this are discarded, but counted as being in error.
> >
> >     When using DSA, frames from the switch has an additional header,
> >     either 4 or 8 bytes if a Marvell switch is used. Thus a full MTU frame
> >     of 1522 bytes received by the switch on a port becomes 1530 bytes when
> >     passed to the host via the FEC interface.
> >
> >     Change the maximum receive size to 2048 - 64, where 64 is the maximum
> >     rx_alignment applied on the receive buffer for AVB capable FEC
> >     cores. Use this value also for the maximum receive buffer size. The
> >     driver is already allocating a receive SKB of 2048 bytes, so this
> >     change should not have any significant effects.
> >
> >     Tested on imx51, imx6, vf610.
> >
> >     Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> >     Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> >
> > However, this is was of an all/nothing problem. All frames with the
> > full MTU were getting dropped, where as i think you are only seeing a
> > few dropped?
> >
> 
> Andrew,
> 
> Indeed this does resolve the issue. I see a burst of FIFO overruns
> initially when receiving an iperf bandwidth test but that would be
> caused by the IMX6 errata and should be mitigated via pause frames.
> After that short burst I see no other errors and iperf works fine.
> 
> Should we get this patch in the linux-stable tree for the 4.9 kernel?

Hi David

Please could you add

fbbeefdd2104 ("net: fec: Allow reception of frames bigger than 1522 bytes")

to stable.

Thanks
	Andrew

  reply	other threads:[~2017-08-31 17:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-30 19:53 DSA mv88e6xxx RX frame errors and TCP/IP RX failure Tim Harvey
2017-08-30 22:06 ` Andrew Lunn
2017-08-31  0:22   ` Tim Harvey
2017-08-31  0:38     ` Ilia Mirkin
2017-08-31  1:46     ` Andrew Lunn
2017-08-31  9:20       ` Maxim Uvarov
2017-08-31 15:37       ` Tim Harvey
2017-08-31 17:41         ` Andrew Lunn [this message]
2017-08-31 17:44           ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170831174141.GP22289@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=fugang.duan@nxp.com \
    --cc=imirkin@alum.mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tharvey@gateworks.com \
    --cc=vivien.didelot@savoirfairelinux.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.