public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Michal Kubecek <mkubecek@suse.cz>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Vinicius Costa Gomes <vinicius.gomes@intel.com>,
	Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
	Kurt Kanzenbach <kurt@linutronix.de>,
	Rui Sousa <rui.sousa@nxp.com>,
	Ferenc Fejes <ferenc.fejes@ericsson.com>
Subject: Re: [RFC PATCH net-next 2/7] net: ethtool: add support for Frame Preemption and MAC Merge layer
Date: Wed, 17 Aug 2022 11:41:01 +0000	[thread overview]
Message-ID: <20220817114100.7pu6y4lpnedyc3fg@skbuf> (raw)
In-Reply-To: <20220816202209.1d9ae749@kernel.org>

On Tue, Aug 16, 2022 at 08:22:09PM -0700, Jakub Kicinski wrote:
> On Wed, 17 Aug 2022 01:29:15 +0300 Vladimir Oltean wrote:
> > +/**
> > + * struct ethtool_mm_state - 802.3 MAC merge layer state
> > + */
> > +struct ethtool_mm_state {
> > +	u32 verify_time;
> > +	enum ethtool_mm_verify_status verify_status;
> > +	bool supported;
> > +	bool enabled;
> > +	bool active;
> 
> The enabled vs active piqued my interest. Is there some handshake /
> aneg or such?

This is where writing the kdocs, as mentioned in the cover letter, would
have helped. Yes, the handshake is described in 802.3 clause "99.4.3
Verifying preemption operation". It says:

| Verification (see Figure 99–3) checks that the link can support the
| preemption capability.
|
| If verification is enabled, the preemption capability shall be active
| only after verification has completed
| successfully.
|
| If the preemption capability is enabled but has not been verified yet,
| the MAC Merge sublayer initiates verification. Verification relies on
| the transmission of a verify mPacket and receipt of a respond mPacket to
| confirm that the remote station supports the preemption capability.

In fact, the verify_time and verify_status fields right above
enabled/active are related exactly to this handshake process.

> > +	nest_table = nla_nest_start(skb, ETHTOOL_A_FP_PARAM_TABLE);
> > +	if (!nest_table)
> > +		return -EMSGSIZE;
> 
> Don't warp tables in nests, let the elements repeat in the parent.

Ok, can do. I did this because 802.1Q actually specifies in the
IEEE8021-Preemption-MIB that there is a ieee8021PreemptionParameterTable
structure containing pairs of ieee8021PreemptionPriority and
ieee8021FramePreemptionAdminStatus.

Do you have actual issues with the structuring of the FP parameters
though? They look like this currently:

ethtool --json --show-fp eno0
[ {
        "ifname": "eno0",
        "parameter-table": [ {
                "prio": 0,
                "admin-status": "preemptable"
            },{
                "prio": 1,
                "admin-status": "preemptable"
            },{
                "prio": 2,
                "admin-status": "preemptable"
            },{
                "prio": 3,
                "admin-status": "preemptable"
            },{
                "prio": 4,
                "admin-status": "preemptable"
            },{
                "prio": 5,
                "admin-status": "preemptable"
            },{
                "prio": 6,
                "admin-status": "preemptable"
            },{
                "prio": 7,
                "admin-status": "preemptable"
            } ],
        "hold-advance": 0,
        "release-advance": 0
    } ]

  reply	other threads:[~2022-08-17 11:41 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-16 22:29 [RFC PATCH net-next 0/7] 802.1Q Frame Preemption and 802.3 MAC Merge support via ethtool Vladimir Oltean
2022-08-16 22:29 ` [RFC PATCH net-next 1/7] net: ethtool: netlink: introduce ethnl_update_bool() Vladimir Oltean
2022-08-17 11:27   ` Michal Kubecek
2022-08-17 11:52     ` Vladimir Oltean
2022-08-17 12:00       ` Vladimir Oltean
2022-08-17 12:05         ` Michal Kubecek
2022-08-16 22:29 ` [RFC PATCH net-next 2/7] net: ethtool: add support for Frame Preemption and MAC Merge layer Vladimir Oltean
2022-08-17  3:22   ` Jakub Kicinski
2022-08-17 11:41     ` Vladimir Oltean [this message]
2022-08-17 18:35       ` Jakub Kicinski
2022-08-17 23:15   ` Vinicius Costa Gomes
2022-08-19 16:12     ` Vladimir Oltean
2022-08-24  0:35       ` Vinicius Costa Gomes
2022-09-07 20:57         ` Vladimir Oltean
2022-09-10  0:19           ` Vinicius Costa Gomes
2022-09-10 16:36             ` Vladimir Oltean
2022-09-14  2:59               ` Vinicius Costa Gomes
2022-09-15 14:14                 ` Vladimir Oltean
2022-11-10 10:33                   ` 回复: " Xiaoliang Yang
2022-11-14 15:42                     ` Vladimir Oltean
2022-11-15  3:01                       ` 回复: " Xiaoliang Yang
2022-11-16 12:36                         ` Vladimir Oltean
2022-08-16 22:29 ` [RFC PATCH net-next 3/7] net: ethtool: stats: make stats_put_stats() take input from multiple sources Vladimir Oltean
2022-08-16 22:29 ` [RFC PATCH net-next 4/7] net: ethtool: stats: replicate standardized counters for the pMAC Vladimir Oltean
2022-08-16 22:29 ` [RFC PATCH net-next 5/7] net: enetc: parameterize port MAC stats to also cover " Vladimir Oltean
2022-08-16 22:29 ` [RFC PATCH net-next 6/7] net: enetc: expose some standardized ethtool counters Vladimir Oltean
2022-08-16 22:29 ` [RFC PATCH net-next 7/7] net: enetc: add support for Frame Preemption and MAC Merge layer Vladimir Oltean
2022-08-17  3:34 ` [RFC PATCH net-next 0/7] 802.1Q Frame Preemption and 802.3 MAC Merge support via ethtool Jakub Kicinski
2022-08-17 11:50   ` Vladimir Oltean
2022-08-17 18:46     ` Jakub Kicinski
2022-10-01 15:53       ` Vladimir Oltean
2022-10-03 14:36         ` Jakub Kicinski
2022-10-03 14:51           ` Vladimir Oltean
2022-08-17 22:47 ` Vinicius Costa Gomes
2022-08-19  8:16 ` Kurt Kanzenbach
2022-08-19 16:59   ` Vladimir Oltean
2022-08-23 10:50     ` Kurt Kanzenbach

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=20220817114100.7pu6y4lpnedyc3fg@skbuf \
    --to=vladimir.oltean@nxp.com \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=ferenc.fejes@ericsson.com \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rui.sousa@nxp.com \
    --cc=vinicius.gomes@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox