From: Furong Xu <0x1207@gmail.com>
To: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Simon Horman <horms@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Russell King <rmk+kernel@armlinux.org.uk>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Serge Semin <fancer.lancer@gmail.com>,
Xiaolei Wang <xiaolei.wang@windriver.com>,
Suraj Jaiswal <quic_jsuraj@quicinc.com>,
Kory Maincent <kory.maincent@bootlin.com>,
Gal Pressman <gal@nvidia.com>,
Jesper Nilsson <jesper.nilsson@axis.com>,
Andrew Halaney <ahalaney@redhat.com>,
Choong Yong Liang <yong.liang.choong@linux.intel.com>,
Kunihiko Hayashi <hayashi.kunihiko@socionext.com>,
Vinicius Costa Gomes <vinicius.gomes@intel.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org
Subject: Re: [PATCH iwl-next v5 1/9] net: ethtool: mm: extract stmmac verification logic into common library
Date: Fri, 21 Feb 2025 17:42:49 +0800 [thread overview]
Message-ID: <20250221174249.000000cc@gmail.com> (raw)
In-Reply-To: <20250220025349.3007793-2-faizal.abdul.rahim@linux.intel.com>
On Wed, 19 Feb 2025 21:53:41 -0500, Faizal Rahim <faizal.abdul.rahim@linux.intel.com> wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> It appears that stmmac is not the only hardware which requires a
> software-driven verification state machine for the MAC Merge layer.
>
> While on the one hand it's good to encourage hardware implementations,
> on the other hand it's quite difficult to tolerate multiple drivers
> implementing independently fairly non-trivial logic.
>
> Extract the hardware-independent logic from stmmac into library code and
> put it in ethtool. Name the state structure "mmsv" for MAC Merge
> Software Verification. Let this expose an operations structure for
> executing the hardware stuff: sync hardware with the tx_active boolean
> (result of verification process), enable/disable the pMAC, send mPackets,
> notify library of external events (reception of mPackets), as well as
> link state changes.
>
> Note that it is assumed that the external events are received in hardirq
> context. If they are not, it is probably a good idea to disable hardirqs
> when calling ethtool_mmsv_event_handle(), because the library does not
> do so.
>
> Also, the MM software verification process has no business with the
> tx_min_frag_size, that is all the driver's to handle.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Co-developed-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
> Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
> Co-developed-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
> Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 16 +-
> .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 41 +---
> .../net/ethernet/stmicro/stmmac/stmmac_fpe.c | 174 +++-----------
> .../net/ethernet/stmicro/stmmac/stmmac_fpe.h | 5 -
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 8 +-
> include/linux/ethtool.h | 131 ++++++++++
> net/ethtool/mm.c | 225 +++++++++++++++++-
> 7 files changed, 399 insertions(+), 201 deletions(-)
>
[...]
> +void ethtool_mmsv_link_state_handle(struct ethtool_mmsv *mmsv, bool up)
> +{
> + unsigned long flags;
> +
> + ethtool_mmsv_stop(mmsv);
> +
> + spin_lock_irqsave(&mmsv->lock, flags);
> +
> + if (up && mmsv->pmac_enabled) {
> + /* VERIFY process requires pMAC enabled when NIC comes up */
> + ethtool_mmsv_configure_pmac(mmsv, true);
> +
> + /* New link => maybe new partner => new verification process */
> + ethtool_mmsv_apply(mmsv);
> + } else {
> + mmsv->status = ETHTOOL_MM_VERIFY_STATUS_INITIAL;
Tested this patch on my side, everything works well, but the verify-status
is a little weird:
# kernel booted, check initial states:
ethtool --include-statistics --json --show-mm eth1
[ {
"ifname": "eth1",
"pmac-enabled": false,
"tx-enabled": false,
"tx-active": false,
"tx-min-frag-size": 60,
"rx-min-frag-size": 60,
"verify-enabled": false,
"verify-time": 128,
"max-verify-time": 128,
"verify-status": "INITIAL",
"statistics": {
"MACMergeFrameAssErrorCount": 0,
"MACMergeFrameSmdErrorCount": 0,
"MACMergeFrameAssOkCount": 0,
"MACMergeFragCountRx": 0,
"MACMergeFragCountTx": 0,
"MACMergeHoldCount": 0
}
} ]
# Enable pMAC by: ethtool --set-mm eth1 pmac-enabled on
ethtool --include-statistics --json --show-mm eth1
[ {
"ifname": "eth1",
"pmac-enabled": true,
"tx-enabled": false,
"tx-active": false,
"tx-min-frag-size": 60,
"rx-min-frag-size": 60,
"verify-enabled": false,
"verify-time": 128,
"max-verify-time": 128,
"verify-status": "DISABLED",
"statistics": {
"MACMergeFrameAssErrorCount": 0,
"MACMergeFrameSmdErrorCount": 0,
"MACMergeFrameAssOkCount": 0,
"MACMergeFragCountRx": 0,
"MACMergeFragCountTx": 0,
"MACMergeHoldCount": 0
}
} ]
# Disable pMAC by: ethtool --set-mm eth1 pmac-enabled off
ethtool --include-statistics --json --show-mm eth1
[ {
"ifname": "eth1",
"pmac-enabled": true,
"tx-enabled": false,
"tx-active": false,
"tx-min-frag-size": 60,
"rx-min-frag-size": 60,
"verify-enabled": false,
"verify-time": 128,
"max-verify-time": 128,
"verify-status": "DISABLED",
"statistics": {
"MACMergeFrameAssErrorCount": 0,
"MACMergeFrameSmdErrorCount": 0,
"MACMergeFrameAssOkCount": 0,
"MACMergeFragCountRx": 0,
"MACMergeFragCountTx": 0,
"MACMergeHoldCount": 0
}
} ]
verify-status always normal on other cases.
@Vladimir, maybe we shouldn't update mmsv->status in ethtool_mmsv_link_state_handle()?
Or, update mmsv->status like below:
mmsv->status = mmsv->pmac_enabled ?
ETHTOOL_MM_VERIFY_STATUS_INITIAL :
ETHTOOL_MM_VERIFY_STATUS_DISABLED;
Anyway, this is too minor, so:
Tested-by: Furong Xu <0x1207@gmail.com>
> + mmsv->verify_retries = ETHTOOL_MM_MAX_VERIFY_RETRIES;
> +
> + /* No link or pMAC not enabled */
> + ethtool_mmsv_configure_pmac(mmsv, false);
> + ethtool_mmsv_configure_tx(mmsv, false);
> + }
> +
> + spin_unlock_irqrestore(&mmsv->lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(ethtool_mmsv_link_state_handle);
WARNING: multiple messages have this Message-ID (diff)
From: Furong Xu <0x1207@gmail.com>
To: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Simon Horman <horms@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Russell King <rmk+kernel@armlinux.org.uk>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Serge Semin <fancer.lancer@gmail.com>,
Xiaolei Wang <xiaolei.wang@windriver.com>,
Suraj Jaiswal <quic_jsuraj@quicinc.com>,
Kory Maincent <kory.maincent@bootlin.com>,
Gal Pressman <gal@nvidia.com>,
Jesper Nilsson <jesper.nilsson@axis.com>,
Andrew Halaney <ahalaney@redhat.com>,
Choong Yong Liang <yong.liang.choong@linux.intel.com>,
Kunihiko Hayashi <hayashi.kunihiko@socionext.com>,
Vinicius Costa Gomes <vinicius.gomes@intel.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v5 1/9] net: ethtool: mm: extract stmmac verification logic into common library
Date: Fri, 21 Feb 2025 17:42:49 +0800 [thread overview]
Message-ID: <20250221174249.000000cc@gmail.com> (raw)
In-Reply-To: <20250220025349.3007793-2-faizal.abdul.rahim@linux.intel.com>
On Wed, 19 Feb 2025 21:53:41 -0500, Faizal Rahim <faizal.abdul.rahim@linux.intel.com> wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> It appears that stmmac is not the only hardware which requires a
> software-driven verification state machine for the MAC Merge layer.
>
> While on the one hand it's good to encourage hardware implementations,
> on the other hand it's quite difficult to tolerate multiple drivers
> implementing independently fairly non-trivial logic.
>
> Extract the hardware-independent logic from stmmac into library code and
> put it in ethtool. Name the state structure "mmsv" for MAC Merge
> Software Verification. Let this expose an operations structure for
> executing the hardware stuff: sync hardware with the tx_active boolean
> (result of verification process), enable/disable the pMAC, send mPackets,
> notify library of external events (reception of mPackets), as well as
> link state changes.
>
> Note that it is assumed that the external events are received in hardirq
> context. If they are not, it is probably a good idea to disable hardirqs
> when calling ethtool_mmsv_event_handle(), because the library does not
> do so.
>
> Also, the MM software verification process has no business with the
> tx_min_frag_size, that is all the driver's to handle.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Co-developed-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
> Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
> Co-developed-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
> Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 16 +-
> .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 41 +---
> .../net/ethernet/stmicro/stmmac/stmmac_fpe.c | 174 +++-----------
> .../net/ethernet/stmicro/stmmac/stmmac_fpe.h | 5 -
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 8 +-
> include/linux/ethtool.h | 131 ++++++++++
> net/ethtool/mm.c | 225 +++++++++++++++++-
> 7 files changed, 399 insertions(+), 201 deletions(-)
>
[...]
> +void ethtool_mmsv_link_state_handle(struct ethtool_mmsv *mmsv, bool up)
> +{
> + unsigned long flags;
> +
> + ethtool_mmsv_stop(mmsv);
> +
> + spin_lock_irqsave(&mmsv->lock, flags);
> +
> + if (up && mmsv->pmac_enabled) {
> + /* VERIFY process requires pMAC enabled when NIC comes up */
> + ethtool_mmsv_configure_pmac(mmsv, true);
> +
> + /* New link => maybe new partner => new verification process */
> + ethtool_mmsv_apply(mmsv);
> + } else {
> + mmsv->status = ETHTOOL_MM_VERIFY_STATUS_INITIAL;
Tested this patch on my side, everything works well, but the verify-status
is a little weird:
# kernel booted, check initial states:
ethtool --include-statistics --json --show-mm eth1
[ {
"ifname": "eth1",
"pmac-enabled": false,
"tx-enabled": false,
"tx-active": false,
"tx-min-frag-size": 60,
"rx-min-frag-size": 60,
"verify-enabled": false,
"verify-time": 128,
"max-verify-time": 128,
"verify-status": "INITIAL",
"statistics": {
"MACMergeFrameAssErrorCount": 0,
"MACMergeFrameSmdErrorCount": 0,
"MACMergeFrameAssOkCount": 0,
"MACMergeFragCountRx": 0,
"MACMergeFragCountTx": 0,
"MACMergeHoldCount": 0
}
} ]
# Enable pMAC by: ethtool --set-mm eth1 pmac-enabled on
ethtool --include-statistics --json --show-mm eth1
[ {
"ifname": "eth1",
"pmac-enabled": true,
"tx-enabled": false,
"tx-active": false,
"tx-min-frag-size": 60,
"rx-min-frag-size": 60,
"verify-enabled": false,
"verify-time": 128,
"max-verify-time": 128,
"verify-status": "DISABLED",
"statistics": {
"MACMergeFrameAssErrorCount": 0,
"MACMergeFrameSmdErrorCount": 0,
"MACMergeFrameAssOkCount": 0,
"MACMergeFragCountRx": 0,
"MACMergeFragCountTx": 0,
"MACMergeHoldCount": 0
}
} ]
# Disable pMAC by: ethtool --set-mm eth1 pmac-enabled off
ethtool --include-statistics --json --show-mm eth1
[ {
"ifname": "eth1",
"pmac-enabled": true,
"tx-enabled": false,
"tx-active": false,
"tx-min-frag-size": 60,
"rx-min-frag-size": 60,
"verify-enabled": false,
"verify-time": 128,
"max-verify-time": 128,
"verify-status": "DISABLED",
"statistics": {
"MACMergeFrameAssErrorCount": 0,
"MACMergeFrameSmdErrorCount": 0,
"MACMergeFrameAssOkCount": 0,
"MACMergeFragCountRx": 0,
"MACMergeFragCountTx": 0,
"MACMergeHoldCount": 0
}
} ]
verify-status always normal on other cases.
@Vladimir, maybe we shouldn't update mmsv->status in ethtool_mmsv_link_state_handle()?
Or, update mmsv->status like below:
mmsv->status = mmsv->pmac_enabled ?
ETHTOOL_MM_VERIFY_STATUS_INITIAL :
ETHTOOL_MM_VERIFY_STATUS_DISABLED;
Anyway, this is too minor, so:
Tested-by: Furong Xu <0x1207@gmail.com>
> + mmsv->verify_retries = ETHTOOL_MM_MAX_VERIFY_RETRIES;
> +
> + /* No link or pMAC not enabled */
> + ethtool_mmsv_configure_pmac(mmsv, false);
> + ethtool_mmsv_configure_tx(mmsv, false);
> + }
> +
> + spin_unlock_irqrestore(&mmsv->lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(ethtool_mmsv_link_state_handle);
next prev parent reply other threads:[~2025-02-21 9:43 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-20 2:53 [PATCH iwl-next v5 0/9] igc: Add support for Frame Preemption feature in IGC Faizal Rahim
2025-02-20 2:53 ` [Intel-wired-lan] " Faizal Rahim
2025-02-20 2:53 ` [PATCH iwl-next v5 1/9] net: ethtool: mm: extract stmmac verification logic into common library Faizal Rahim
2025-02-20 2:53 ` [Intel-wired-lan] " Faizal Rahim
2025-02-20 11:38 ` Vladimir Oltean
2025-02-20 11:38 ` [Intel-wired-lan] " Vladimir Oltean
2025-02-21 9:42 ` Furong Xu [this message]
2025-02-21 9:42 ` Furong Xu
2025-02-21 9:56 ` Vladimir Oltean
2025-02-21 9:56 ` [Intel-wired-lan] " Vladimir Oltean
2025-02-21 10:24 ` Furong Xu
2025-02-21 10:24 ` [Intel-wired-lan] " Furong Xu
2025-02-21 10:43 ` Vladimir Oltean
2025-02-21 10:43 ` [Intel-wired-lan] " Vladimir Oltean
2025-02-21 13:30 ` Abdul Rahim, Faizal
2025-02-21 13:30 ` [Intel-wired-lan] " Abdul Rahim, Faizal
2025-02-21 14:44 ` Vladimir Oltean
2025-02-21 14:44 ` [Intel-wired-lan] " Vladimir Oltean
2025-02-22 0:26 ` Abdul Rahim, Faizal
2025-02-22 0:26 ` [Intel-wired-lan] " Abdul Rahim, Faizal
2025-02-23 5:39 ` Furong Xu
2025-02-23 5:39 ` [Intel-wired-lan] " Furong Xu
2025-02-20 2:53 ` [PATCH iwl-next v5 2/9] igc: Rename xdp_get_tx_ring() for non-xdp usage Faizal Rahim
2025-02-20 2:53 ` [Intel-wired-lan] " Faizal Rahim
2025-02-20 2:53 ` [PATCH iwl-next v5 3/9] igc: Optimize the TX packet buffer utilization Faizal Rahim
2025-02-20 2:53 ` [Intel-wired-lan] " Faizal Rahim
2025-02-20 2:53 ` [PATCH iwl-next v5 4/9] igc: Set the RX packet buffer size for TSN mode Faizal Rahim
2025-02-20 2:53 ` [Intel-wired-lan] " Faizal Rahim
2025-02-20 2:53 ` [PATCH iwl-next v5 5/9] igc: Add support for frame preemption verification Faizal Rahim
2025-02-20 2:53 ` [Intel-wired-lan] " Faizal Rahim
2025-02-20 11:18 ` Vladimir Oltean
2025-02-20 11:18 ` [Intel-wired-lan] " Vladimir Oltean
2025-02-20 2:53 ` [PATCH iwl-next v5 6/9] igc: Add support to set tx-min-frag-size Faizal Rahim
2025-02-20 2:53 ` [Intel-wired-lan] " Faizal Rahim
2025-02-20 2:53 ` [PATCH iwl-next v5 7/9] igc: Add support to get MAC Merge data via ethtool Faizal Rahim
2025-02-20 2:53 ` [Intel-wired-lan] " Faizal Rahim
2025-02-20 2:53 ` [PATCH iwl-next v5 8/9] igc: Add support to get frame preemption statistics " Faizal Rahim
2025-02-20 2:53 ` [Intel-wired-lan] " Faizal Rahim
2025-02-20 2:53 ` [PATCH iwl-next v5 9/9] igc: Block setting preemptible traffic class in taprio Faizal Rahim
2025-02-20 2:53 ` [Intel-wired-lan] " Faizal Rahim
2025-02-20 11:28 ` Vladimir Oltean
2025-02-20 11:28 ` [Intel-wired-lan] " Vladimir Oltean
2025-02-20 11:46 ` [PATCH iwl-next v5 0/9] igc: Add support for Frame Preemption feature in IGC Vladimir Oltean
2025-02-20 11:46 ` [Intel-wired-lan] " 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=20250221174249.000000cc@gmail.com \
--to=0x1207@gmail.com \
--cc=ahalaney@redhat.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=faizal.abdul.rahim@linux.intel.com \
--cc=fancer.lancer@gmail.com \
--cc=gal@nvidia.com \
--cc=hawk@kernel.org \
--cc=hayashi.kunihiko@socionext.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesper.nilsson@axis.com \
--cc=john.fastabend@gmail.com \
--cc=kory.maincent@bootlin.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux@armlinux.org.uk \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=quic_jsuraj@quicinc.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=vinicius.gomes@intel.com \
--cc=vladimir.oltean@nxp.com \
--cc=xiaolei.wang@windriver.com \
--cc=yong.liang.choong@linux.intel.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.