All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ramón Nordin Rodriguez" <ramon.nordin.rodriguez@ferroamp.se>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] net: microchip_t1s: additional phy support and collision detect handling
Date: Mon, 27 Nov 2023 16:30:33 +0100	[thread overview]
Message-ID: <ZWS2GYBGGZg2MS0d@debian> (raw)
In-Reply-To: <d79803b5-60ec-425b-8c5c-3e96ff351e09@lunn.ch>

On Mon, Nov 27, 2023 at 02:58:32PM +0100, Andrew Lunn wrote:
> > Collision detection
> > This has been tested on a setup where one ARM system with a LAN8650
> > mac-phy is daisy-chained to 8 mcus using lan8670 phys. Without the patch we
> > were limited to really short cables, about 1m per node, but we were
> > still getting a lot of connection drops.
> > With the patch we could increase the total cable length to at least 40M.
> 
> Did you do any testing of collision detection enabled, PLCA disabled?
> 

In our dev system we've only tested with PLCA enabled, bit too tricky
changing internals on the microcontrollers.
But I have a lot of usb eval dongles that I can test with.

> You say you think this is noise related. But the noise should be the
> same with or without PLCA. I'm just thinking maybe collision detection
> is just plain broken and should always be disabled?
> 

I don't have access to the equipment to measure noise or reflections,
I've looked at the link with an oscilloscope and it looked fine to me.
The reason I'm mentioning noise is just me parroting the datasheet, for
context I'll quote the footnote here

"No physical collisions will occur when all nodes in a mixing segment are properly
configured for PLCA operation. As a result, for improved performance in high noise
environments where false collisions may be detected leading to dropped packets, it is
recommended that the user write this bit to a ‘0’ to disable collision detection when PLCA
is enabled. When collision detection is disabled, the PLCA reconciliation sublayer will still
assert logical collisions to the MAC as part of normal operation."
LAN8650 datasheet 11.5.51

> I've not read much about T1S, but if we assume it is doing good old
> fashioned CSMA/CD, with short cables the CS bit works well and the CD
> is less important. CD was needed when you have 1000m cable, and you
> can fit 64 bytes on the 1000m cable. So always turning of CD might be
> appropriate.
> 
> 	Andrew

As you assume when PLCA is disabled the phy runs in CSMA/CD mode.

I'll do some tests with both PLCA and CD off/disabled. My thinking is that a
adequate test bench would look like

* 3-4 nodes (depending on how many usb ports and dongles I have)
* run iperf with long cables and CSMA/CD
* run iperf with long cables and CMSA/No CD

I'll report back the results. Anything you'd like to add/focus on with
evaluation?

Ramón

  reply	other threads:[~2023-11-27 15:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-27 10:40 [PATCH 0/3] net: microchip_t1s: additional phy support and collision detect handling Ramón N.Rodriguez
2023-11-27 10:40 ` [PATCH 1/3] net: microchip_t1s: refactor reset functionality Ramón N.Rodriguez
2023-11-27 13:27   ` Andrew Lunn
2023-11-27 10:40 ` [PATCH 2/3] net: microchip_t1s: add support for LAN867x Rev.C1 Ramón N.Rodriguez
2023-11-27 13:37   ` Andrew Lunn
2023-11-27 14:02     ` Ramón Nordin Rodriguez
2023-12-05 10:20     ` Félix Piédallu
2023-12-06 20:58       ` Ramón Nordin Rodriguez
2023-11-27 10:40 ` [PATCH 3/3] net: microchip_t1s: conditional collision detection Ramón N.Rodriguez
2023-11-27 16:00   ` Parthiban.Veerasooran
2023-11-27 16:32     ` Ramón Nordin Rodriguez
2023-11-28  6:52       ` Parthiban.Veerasooran
2023-11-28  9:18         ` Ramón Nordin Rodriguez
2023-11-27 13:58 ` [PATCH 0/3] net: microchip_t1s: additional phy support and collision detect handling Andrew Lunn
2023-11-27 15:30   ` Ramón Nordin Rodriguez [this message]
2023-11-27 16:03     ` Andrew Lunn
2023-11-28  8:57       ` Ramón Nordin Rodriguez
2023-12-10 12:10       ` Ramón Nordin Rodriguez
2023-12-11 13:54         ` Andrew Lunn

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=ZWS2GYBGGZg2MS0d@debian \
    --to=ramon.nordin.rodriguez@ferroamp.se \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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.