Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191015224953.24199-1-f.fainelli@gmail.com> <20191015224953.24199-3-f.fainelli@gmail.com>
 <4feb3979-1d59-4ad3-b2f1-90d82cfbdf54@gmail.com> <c4244c9a-28cb-7e37-684d-64e6cdc89b67@gmail.com>
 <CA+h21hrLHe2n0OxJyCKTU0r7mSB1zK9ggP1-1TCednFN_0rXfg@mail.gmail.com>
 <20191018130121.GK4780@lunn.ch> <CA+h21hoPrwcgz-q=UROAu0PC=6JbKtbdPhJtZg5ge32_2xJ3TQ@mail.gmail.com>
 <20191018132316.GI25745@shell.armlinux.org.uk> <CA+h21hqVZ=LF3bQGtqFh4uMu6AhNFcrwQuUcEH-Fc1VrWku-eg@mail.gmail.com>
 <20191018135411.GJ25745@shell.armlinux.org.uk>
In-Reply-To: <20191018135411.GJ25745@shell.armlinux.org.uk>
From:   Vladimir Oltean <olteanv@gmail.com>
Date:   Fri, 18 Oct 2019 17:12:25 +0300
Message-ID: <CA+h21hrqRtxWp1c-8F-9qPPsYxA_w_B_131DRayLBd8xjpOzPg@mail.gmail.com>
Subject: Re: [PATCH net-next 2/2] net: phy: Add ability to debug RGMII connections
To:     Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        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, cphealy@gmail.com,
        Jose Abreu <joabreu@synopsys.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, 18 Oct 2019 at 16:54, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Fri, Oct 18, 2019 at 04:37:55PM +0300, Vladimir Oltean wrote:
> > On Fri, 18 Oct 2019 at 16:23, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Fri, Oct 18, 2019 at 04:09:30PM +0300, Vladimir Oltean wrote:
> > > > 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.
> > >
> > > Isn't the point of this to see which RGMII setting results in a working
> > > setup?
> > >
> > > So, is it not true that what we're after is receiving a _correct_ frame
> > > that corresponds to the frame that was sent out?
> > >
> >
> > Only true if the MAC does not drop bad frames by itself. Then the FCS
> > check in the kernel thread is superfluous.
>
> If a MAC driver doesn't drop bad frames, then surely it's buggy, since
> there isn't (afaik) a way of marking a received skb with a FCS error.
> Therefore, forwarding frames with bad FCS into the Linux networking
> stack will allow the reception of bad frames as if they were good.
>
> All the network drivers I've looked at (and written), when encountering
> a packet with an error, update the statistic counters and drop the
> errored packet.
>
> Do you know of any that don't?
>

I don't think you are following the big picture of what I am saying. I
was trying to follow Florian's intention (first make sure I understand
it) and suggest that the FCS checking code in the patch he submitted
is not doing what it was intended to. I am getting apparent FCS
mismatches reported by the program, when I know full well that the MAC
I am testing on would have dropped those frames were they really
invalid.
We aren't saying anything in contradiction.

> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up

Thanks,
-Vladimir