From: Ansuel Smith <ansuelsmth@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Vivien Didelot <vivien.didelot@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [net-next RFC PATCH 0/6] Add support for qca8k mdio rw in Ethernet packet
Date: Tue, 7 Dec 2021 16:33:57 +0100 [thread overview]
Message-ID: <61af7ee7.1c69fb81.2b3ba.d48b@mx.google.com> (raw)
In-Reply-To: <Ya96pwC1KKZDO9et@lunn.ch>
On Tue, Dec 07, 2021 at 04:15:51PM +0100, Andrew Lunn wrote:
> On Tue, Dec 07, 2021 at 03:59:36PM +0100, Ansuel Smith wrote:
> > Hi, this is still WIP and currently has some problem but I would love if
> > someone can give this a superficial review and answer to some problem
> > with this.
> >
> > The main reason for this is that we notice some routing problem in the
> > switch and it seems assisted learning is needed. Considering mdio is
> > quite slow due to the indirect write using this Ethernet alternative way
> > seems to be quicker.
> >
> > The qca8k switch supports a special way to pass mdio read/write request
> > using specially crafted Ethernet packet.
>
> Oh! Cool! Marvell has this as well, and i suspect a few others. It is
> something i've wanted to work on for a long long time, but never had
> the opportunity.
>
Really? I tought this was very specific to qca8k.
> This also means that, even if you are focusing on qca8k, please try to
> think what could be generic, and what should specific to the
> qca8k. The idea of sending an Ethernet frame and sometime later
> receiving a reply should be generic and usable for other DSA
> drivers. The contents of those frames needs to be driver specific.
> How we hook this into MDIO might also be generic, maybe.
A generic implementation of this would be add an ops to the dsa generic
struct that driver can implement and find a clean way to use this
alternative way instead of normal mdio. (Implement something like
eth_mdio_read/write ops and the driver will decide when to use them?
The dsa then will correctly understand when the driver is ready to
accept packet and send the skb, in all the other case just send an error
and the driver will use normal mdio?)
I think the tagger require some modification anyway as it's the one that
receive packet and parse them. (I assume also other switch will use the
tagger to understand that the packet is used for mdio)
(A bool to declare that the tagger can correctly parse this kind of
stuff and complete the completion?)
>
> I will look at your questions later, but soon.
>
Thanks a lot for the quick response. I'm more than happy to generalize
this and find the a correct way.
> Andrew
--
Ansuel
next prev parent reply other threads:[~2021-12-07 15:34 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-07 14:59 [net-next RFC PATCH 0/6] Add support for qca8k mdio rw in Ethernet packet Ansuel Smith
2021-12-07 14:59 ` [net-next RFC PATCH 1/6] net: dsa: tag_qca: convert to FIELD macro Ansuel Smith
2021-12-07 14:59 ` [net-next RFC PATCH 2/6] net: dsa: tag_qca: move define to include linux/dsa Ansuel Smith
2021-12-07 14:59 ` [net-next RFC PATCH 3/6] net: dsa: tag_qca: add define for mdio read/write in ethernet packet Ansuel Smith
2021-12-07 14:59 ` [net-next RFC PATCH 4/6] net: dsa: qca8k: Add support for mdio read/write in Ethernet packet Ansuel Smith
2021-12-07 14:59 ` [net-next RFC PATCH 5/6] net: dsa: tag_qca: Add support for handling mdio read/write packet Ansuel Smith
2021-12-07 14:59 ` [net-next RFC PATCH 6/6] net: dsa: qca8k: cache lo and hi for mdio write Ansuel Smith
2021-12-07 15:15 ` [net-next RFC PATCH 0/6] Add support for qca8k mdio rw in Ethernet packet Andrew Lunn
2021-12-07 15:33 ` Ansuel Smith [this message]
2021-12-07 18:49 ` Florian Fainelli
2021-12-07 19:44 ` Ansuel Smith
2021-12-07 21:10 ` Vladimir Oltean
2021-12-07 22:01 ` Ansuel Smith
2021-12-07 22:37 ` Andrew Lunn
2021-12-07 18:41 ` Andrew Lunn
2021-12-07 18:53 ` Ansuel Smith
2021-12-07 19:15 ` Andrew Lunn
2021-12-07 19:21 ` Ansuel Smith
2021-12-07 20:52 ` Vladimir Oltean
2021-12-07 21:47 ` Ansuel Smith
2021-12-07 22:22 ` Andrew Lunn
2021-12-07 22:30 ` Ansuel Smith
2021-12-07 22:46 ` Andrew Lunn
2021-12-07 23:47 ` Vladimir Oltean
2021-12-08 0:04 ` Vladimir Oltean
2021-12-08 0:40 ` Vladimir Oltean
2021-12-08 0:42 ` Ansuel Smith
2021-12-08 1:09 ` Vladimir Oltean
2021-12-08 3:32 ` Ansuel Smith
2021-12-08 11:54 ` Vladimir Oltean
2021-12-08 1:15 ` Andrew Lunn
2021-12-07 22:45 ` Vladimir Oltean
2021-12-07 22:54 ` Andrew Lunn
2021-12-07 23:14 ` Vladimir Oltean
2021-12-08 1:35 ` Andrew Lunn
2021-12-08 3:39 ` Ansuel Smith
2021-12-08 11:51 ` Vladimir Oltean
2021-12-07 23:05 ` Ansuel Smith
2021-12-07 23:20 ` Vladimir Oltean
2021-12-07 23:24 ` Ansuel Smith
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=61af7ee7.1c69fb81.2b3ba.d48b@mx.google.com \
--to=ansuelsmth@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=vivien.didelot@gmail.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).