Re: [PATCH net-next 2/2] net: phy: Add ability to debug RGMII connections

From: Vladimir Oltean <olteanv@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	netdev <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	open list <linux-kernel@vger.kernel.org>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	bcm-kernel-feedback-list@broadcom.com,
	Russell King <rmk+kernel@armlinux.org.uk>,
	cphealy@gmail.com, Jose Abreu <joabreu@synopsys.com>
Subject: Re: [PATCH net-next 2/2] net: phy: Add ability to debug RGMII connections
Date: Fri, 18 Oct 2019 16:09:30 +0300	[thread overview]
Message-ID: <CA+h21hoPrwcgz-q=UROAu0PC=6JbKtbdPhJtZg5ge32_2xJ3TQ@mail.gmail.com> (raw)
In-Reply-To: <20191018130121.GK4780@lunn.ch>

Hi Andrew,

On Fri, 18 Oct 2019 at 16:01, Andrew Lunn <andrew@lunn.ch> wrote:
>
> > Well, that's the tricky part. You're sending a frame out, with no
> > guarantee you'll get the same frame back in. So I'm not sure that any
> > identifiers put inside the frame will survive.
> > How do the tests pan out for you? Do you actually get to trigger this
> > check? As I mentioned, my NIC drops the frames with bad FCS.
>
> My experience is, the NIC drops the frame and increments some the
> counter about bad FCS. I do very occasionally see a frame delivered,
> but i guess that is 1/65536 where the FCS just happens to be good by
> accident. So i think some other algorithm should be used which is
> unlikely to be good when the FCS is accidentally good, or just check
> the contents of the packet, you know what is should contain.
>
> Are there any NICs which don't do hardware FCS? Is that something we
> realistically need to consider?
>
> > Yes, but remember, nobody guarantees that a frame with DMAC
> > ff:ff:ff:ff:ff:ff on egress will still have it on its way back. Again,
> > this all depends on how you plan to manage the rx-all ethtool feature.
>
> Humm. Never heard that before. Are you saying some NICs rewrite the
> DMAN?
>

I'm just trying to understand the circumstances under which this
kernel thread makes sense.
Checking for FCS validity means that the intention was to enable the
reception of frames with bad FCS.
Bad FCS after bad RGMII setup/hold times doesn't mean there's a small
guy in there who rewrites the checksum. It means that frame octets get
garbled. All octets are just as likely to get garbled, including the
SFD, preamble, DMAC, etc.
All I'm saying is that, if the intention of the patch is to actually
process the FCS of frames before and after, then it should actually
put the interface in promiscuous mode, so that frames with a
non-garbled SFD and preamble can still be received, even though their
DMAC was the one that got garbled.

>         Andrew

Thanks,
-Vladimir