From: Vladimir Oltean <olteanv@gmail.com>
To: Lukasz Majewski <lukma@denx.de>
Cc: Eric Dumazet <edumazet@google.com>, Andrew Lunn <andrew@lunn.ch>,
davem@davemloft.net, Paolo Abeni <pabeni@redhat.com>,
Woojung Huh <woojung.huh@microchip.com>,
Tristram.Ha@microchip.com,
Florian Fainelli <f.fainelli@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
UNGLinuxDriver@microchip.com,
George McCollister <george.mccollister@gmail.com>,
Oleksij Rempel <o.rempel@pengutronix.de>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 RFC 4/4] net: dsa: hsr: Provide generic HSR ksz_hsr_{join|leave} functions
Date: Tue, 5 Sep 2023 16:57:19 +0300 [thread overview]
Message-ID: <20230905135719.yycwfgonlt244gvx@skbuf> (raw)
In-Reply-To: <20230905154744.648c1a8b@wsk>
On Tue, Sep 05, 2023 at 03:47:44PM +0200, Lukasz Majewski wrote:
> > > Moreover, for me it seems more natural, that we only allow full HSR
> > > support for 2 ports or none. Please be aware, that HSR supposed to
> > > support only 2 ports, and having only one working is not
> > > recommended by vendor.
> >
> > And where is it enforced that full HSR offload is only applied to 2
> > ports or none?
>
> In the ksz_jsr_join() at ksz_common.c -> we exit from this function
> when !partner.
And what about 4 or 6 ports being placed as members of 2 or 3 HSR devices?
How does the !partner condition help there?
> > Results:
> > With KSZ9477 offloading support added: RX: 100 Mbps TX: 98 Mbps
> > With no offloading RX: 63 Mbps TX: 63 Mbps
> >
> > What was the setup for the "no offloading" case?
> >
>
> I used two boards. I've used the same kernel with and without HSR
> offloading patches.
>
> Cables were connected to port1 and port2 on each board. Non HSR network
> was connected to port3.
>
> > (a) kernel did not contain the offloading patch set
> >
>
> Yes.
Ok, then it would be good to check that your patch set does not break
something that used to work (software HSR - easiest to check with a
second pair of ports, but if not possible, it can also be emulated by
returning -EOPNOTSUPP in .port_hsr_join on an artificial other condition).
> > (b) the testing was on hsr1, in the situation below:
> >
> > ip link add name hsr0 type hsr slave1 lan1 slave2 lan2 supervision 45
> > version 1 # offloaded ip link add name hsr1 type hsr slave1 lan3
> > slave2 lan4 supervision 45 version 1 # unoffloaded
>
> I did not setup two hsr devices on the same board. I've used two boards
> with hsr0 setup on each.
Ok, but can you?
> > (d) in some other way (please detail)
> >
> > I was specifically asking about situation (b).
>
> I did not tested the hsr0, hsr1 as my (real) use case is with KSZ9477
> having only 3 ports available for connection (port 1,2,3).
ksz_chip_data :: port_cnt is set to 7 for KSZ9477. I guess that the
limitation of having only 3 user ports for testing is specific to your
board, and not to the entire switch as may be seen on other boards,
correct?
It doesn't mean that the "single HSR device" restriction shouldn't be
enforced.
next prev parent reply other threads:[~2023-09-05 13:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-04 12:02 [PATCH v3 RFC 0/4] net: dsa: hsr: Enable HSR HW offloading for KSZ9477 Lukasz Majewski
2023-09-04 12:02 ` [PATCH v3 RFC 1/4] net: dsa: Extend the ksz_device structure to hold info about HSR ports Lukasz Majewski
2023-09-04 12:02 ` [PATCH v3 RFC 2/4] net: dsa: Extend ksz9477 TAG setup to support HSR frames duplication Lukasz Majewski
2023-09-05 10:22 ` Vladimir Oltean
2023-09-05 10:44 ` Lukasz Majewski
2023-09-05 11:00 ` Vladimir Oltean
2023-09-05 11:33 ` Lukasz Majewski
2023-09-04 12:02 ` [PATCH v3 RFC 3/4] net: dsa: hsr: Enable in KSZ9477 switch HW HSR offloading Lukasz Majewski
2023-09-05 10:37 ` Vladimir Oltean
2023-09-05 11:11 ` Lukasz Majewski
2023-09-05 13:03 ` Vladimir Oltean
2023-09-05 13:48 ` Vladimir Oltean
2023-09-05 15:20 ` Lukasz Majewski
2023-09-05 15:20 ` Lukasz Majewski
2023-09-04 12:02 ` [PATCH v3 RFC 4/4] net: dsa: hsr: Provide generic HSR ksz_hsr_{join|leave} functions Lukasz Majewski
2023-09-04 20:53 ` Vladimir Oltean
2023-09-05 9:12 ` Lukasz Majewski
2023-09-05 10:47 ` Vladimir Oltean
2023-09-05 11:23 ` Lukasz Majewski
2023-09-05 12:05 ` Vladimir Oltean
2023-09-05 12:23 ` Andrew Lunn
2023-09-05 13:47 ` Lukasz Majewski
2023-09-05 13:57 ` Vladimir Oltean [this message]
2023-09-05 14:04 ` Vladimir Oltean
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=20230905135719.yycwfgonlt244gvx@skbuf \
--to=olteanv@gmail.com \
--cc=Tristram.Ha@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=george.mccollister@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukma@denx.de \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=woojung.huh@microchip.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;
as well as URLs for NNTP newsgroup(s).