On Fri, 18 Oct 2019 at 16:23, Russell King - ARM Linux admin <[email protected]> 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 <[email protected]> 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. > Hence, if the DMAC got changed, it's irrelevent whether we received the > packet or not - since "no packet" || "changed packet" = fail. > > -- > 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
