public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: netdev@kapio-technology.com
Cc: Ido Schimmel <idosch@idosch.org>,
	davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
	Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 net-next 0/2] mv88e6xxx: Add MAB offload support
Date: Wed, 16 Nov 2022 12:24:06 +0200	[thread overview]
Message-ID: <20221116102406.gg6h7gvkx55f2ojj@skbuf> (raw)
In-Reply-To: <e05f69915a2522fc1e9854194afcc87b@kapio-technology.com>

On Tue, Nov 15, 2022 at 07:40:02PM +0100, netdev@kapio-technology.com wrote:
> So, I will not present you with a graph as it is a tedious process (probably
> it is some descending gaussian curve wrt timeout occurring).
> 
> But 100ms fails, 125 I had 1 port fail, at 140, 150  and 180 I saw timeouts
> resulting in fdb add fails, like (and occasional port fail):
> 
> mv88e6085 1002b000.ethernet-1:04: Timeout while waiting for switch
> mv88e6085 1002b000.ethernet-1:04: port 0 failed to add be:7c:96:06:9f:09 vid
> 1 to fdb: -110
> 
> At around 200 ms it looks like it is getting stable (like 5 runs, no
> problems).
> 
> So with the gaussian curve tail whipping ones behind (risque of failure) it
> might need to be like 300 ms in my case... :-)

Pick a value that is high enough to be reliable and submit a patch to
"net" where you present the evidence for it (top-level MDIO controller,
SoC, switch, kernel). I don't believe there's much to read into. A large
timeout shouldn't have a negative effect on the MDIO performance,
because it just determines how long it takes until the kernel declares
it dead, rather than how long it takes for transactions to actually take
place.

  reply	other threads:[~2022-11-16 10:28 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-12 20:37 [PATCH v8 net-next 0/2] mv88e6xxx: Add MAB offload support Hans J. Schultz
2022-11-12 20:37 ` [PATCH v8 net-next 1/2] net: dsa: mv88e6xxx: allow reading FID when handling ATU violations Hans J. Schultz
2022-11-12 20:37 ` [PATCH v8 net-next 2/2] net: dsa: mv88e6xxx: mac-auth/MAB implementation Hans J. Schultz
2022-11-15  9:58   ` Ido Schimmel
2022-11-15 10:36     ` netdev
2022-11-15 15:12       ` Ido Schimmel
2022-11-15 15:24         ` netdev
2022-11-15 22:23   ` Vladimir Oltean
2022-11-20  9:33     ` netdev
2022-11-20  9:54     ` netdev
2022-11-20 10:21     ` netdev
2022-11-20 15:00       ` Vladimir Oltean
2022-12-02 11:06         ` netdev
2022-12-04 15:08         ` netdev
2022-12-04 13:26     ` netdev
2022-11-15  2:57 ` [PATCH v8 net-next 0/2] mv88e6xxx: Add MAB offload support Jakub Kicinski
2022-11-15  5:18   ` Jakub Kicinski
2022-11-15  9:30 ` Ido Schimmel
2022-11-15 10:26   ` netdev
2022-11-15 10:28     ` Vladimir Oltean
2022-11-15 10:52       ` netdev
2022-11-15 11:10         ` Vladimir Oltean
2022-11-15 11:31           ` netdev
2022-11-15 12:22             ` Vladimir Oltean
2022-11-15 12:40               ` netdev
2022-11-15 13:25               ` netdev
2022-11-15 14:56                 ` Vladimir Oltean
2022-11-15 15:14                   ` netdev
2022-11-15 16:15                     ` Vladimir Oltean
2022-11-15 17:11                       ` netdev
2022-11-15 17:15                         ` Vladimir Oltean
2022-11-15 16:03                   ` netdev
2022-11-15 16:18                     ` Vladimir Oltean
2022-11-15 18:40                       ` netdev
2022-11-16 10:24                         ` Vladimir Oltean [this message]
2022-11-16 13:37                           ` Andrew Lunn
2022-11-18 13:37                           ` netdev
2022-11-18 13:51                             ` Andrew Lunn
2022-11-15 13:21             ` Andrew Lunn
2022-11-15 14:18               ` netdev

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=20221116102406.gg6h7gvkx55f2ojj@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@idosch.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@kapio-technology.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox