From: Simon Horman <simon.horman@corigine.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Michal Kubecek <mkubecek@suse.cz>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
Petr Machata <petrm@nvidia.com>,
Danielle Ratson <danieller@nvidia.com>,
Pranavi Somisetty <pranavi.somisetty@amd.com>,
Harini Katakam <harini.katakam@amd.com>,
Vinicius Costa Gomes <vinicius.gomes@intel.com>,
Kurt Kanzenbach <kurt@linutronix.de>,
Gerhard Engleder <gerhard@engleder-embedded.com>,
Ferenc Fejes <ferenc.fejes@ericsson.com>,
Aaron Conole <aconole@redhat.com>,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 net-next 3/9] net: enetc: only commit preemptible TCs to hardware when MM TX is active
Date: Thu, 20 Apr 2023 16:42:52 +0200 [thread overview]
Message-ID: <ZEFPbNCNDWy0c8eK@corigine.com> (raw)
In-Reply-To: <20230418111459.811553-4-vladimir.oltean@nxp.com>
On Tue, Apr 18, 2023 at 02:14:53PM +0300, Vladimir Oltean wrote:
> This was left as TODO in commit 01e23b2b3bad ("net: enetc: add support
> for preemptible traffic classes") since it's relatively complicated.
>
> Where this makes a difference is with a configuration as follows:
>
> ethtool --set-mm eno0 pmac-enabled on tx-enabled on verify-enabled on
>
> Preemptible packets should only be sent when the MAC Merge TX direction
> becomes active (i.o.w. when the verification process succeeds, aka when
> the link partner confirms it can process preemptible traffic). But the
> tc qdisc with the preemptible traffic classes is offloaded completely
> asynchronously w.r.t. the MM becoming active.
>
> The ENETC manual does suggest that this should be handled in the driver:
> "On startup, software should wait for the verification process to
> complete (MMCSR[VSTS]=011) before initiating traffic".
>
> Adding the necessary logic allows future selftests to uphold the claim
> that an inactive or disabled MAC Merge layer should never send data
> packets through the pMAC.
>
> This change moves enetc_set_ptcfpr() from enetc.c to enetc_ethtool.c,
> where its only caller is now - enetc_mm_commit_preemptible_tcs().
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
> int enetc_qos_query_caps(struct net_device *ndev, void *type_data);
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
> index deb674752851..838a92131963 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
> @@ -991,6 +991,64 @@ static int enetc_get_mm(struct net_device *ndev, struct ethtool_mm_state *state)
> return 0;
> }
>
> +static int enetc_mm_wait_tx_active(struct enetc_hw *hw, int verify_time)
> +{
> + int timeout = verify_time * USEC_PER_MSEC * ENETC_MM_VERIFY_RETRIES;
> + u32 val;
> +
> + /* This will time out after the standard value of 3 verification
> + * attempts. To not sleep forever, it relies on a non-zero verify_time,
> + * guarantee which is provided by the ethtool nlattr policy.
> + */
> + return read_poll_timeout(enetc_port_rd, val,
> + ENETC_MMCSR_GET_VSTS(val) == 3,
nit: 3 is doing a lot of work here.
As a follow-up, perhaps it could become part of an enum?
> + ENETC_MM_VERIFY_SLEEP_US, timeout,
> + true, hw, ENETC_MMCSR);
> +}
...
next prev parent reply other threads:[~2023-04-20 14:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 11:14 [PATCH v2 net-next 0/9] ethtool mm API consolidation Vladimir Oltean
2023-04-18 11:14 ` [PATCH v2 net-next 1/9] net: enetc: fix MAC Merge layer remaining enabled until a link down event Vladimir Oltean
2023-04-20 14:22 ` Simon Horman
2023-04-20 17:03 ` Vladimir Oltean
2023-04-21 9:01 ` Simon Horman
2023-04-18 11:14 ` [PATCH v2 net-next 2/9] net: enetc: report mm tx-active based on tx-enabled and verify-status Vladimir Oltean
2023-04-20 14:40 ` Simon Horman
2023-04-18 11:14 ` [PATCH v2 net-next 3/9] net: enetc: only commit preemptible TCs to hardware when MM TX is active Vladimir Oltean
2023-04-20 14:42 ` Simon Horman [this message]
2023-04-20 16:34 ` Vladimir Oltean
2023-04-20 16:49 ` Simon Horman
2023-04-18 11:14 ` [PATCH v2 net-next 4/9] net: enetc: include MAC Merge / FP registers in register dump Vladimir Oltean
2023-04-20 14:38 ` Simon Horman
2023-04-20 16:58 ` Vladimir Oltean
2023-04-21 9:03 ` Simon Horman
2023-04-18 11:14 ` [PATCH v2 net-next 5/9] net: ethtool: mm: sanitize some UAPI configurations Vladimir Oltean
2023-04-20 14:43 ` Simon Horman
2023-04-18 11:14 ` [PATCH v2 net-next 6/9] selftests: forwarding: sch_tbf_*: Add a pre-run hook Vladimir Oltean
2023-04-18 11:14 ` [PATCH v2 net-next 7/9] selftests: forwarding: generalize bail_on_lldpad from mlxsw Vladimir Oltean
2023-04-18 11:14 ` [PATCH v2 net-next 8/9] selftests: forwarding: introduce helper for standard ethtool counters Vladimir Oltean
2023-04-18 11:14 ` [PATCH v2 net-next 9/9] selftests: forwarding: add a test for MAC Merge layer Vladimir Oltean
2023-04-21 3:10 ` [PATCH v2 net-next 0/9] ethtool mm API consolidation patchwork-bot+netdevbpf
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=ZEFPbNCNDWy0c8eK@corigine.com \
--to=simon.horman@corigine.com \
--cc=aconole@redhat.com \
--cc=claudiu.manoil@nxp.com \
--cc=danieller@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=ferenc.fejes@ericsson.com \
--cc=gerhard@engleder-embedded.com \
--cc=harini.katakam@amd.com \
--cc=kuba@kernel.org \
--cc=kurt@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=pranavi.somisetty@amd.com \
--cc=vinicius.gomes@intel.com \
--cc=vladimir.oltean@nxp.com \
--cc=xiaoliang.yang_1@nxp.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.