public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kurt Kanzenbach <kurt@linutronix.de>
To: Vladimir Oltean <vladimir.oltean@nxp.com>, netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Michal Kubecek <mkubecek@suse.cz>,
	Vinicius Costa Gomes <vinicius.gomes@intel.com>,
	Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
	Rui Sousa <rui.sousa@nxp.com>,
	Ferenc Fejes <ferenc.fejes@ericsson.com>,
	Pranavi Somisetty <pranavi.somisetty@amd.com>,
	Harini Katakam <harini.katakam@amd.com>,
	UNGLinuxDriver@microchip.com, Petr Machata <petrm@nvidia.com>,
	Ido Schimmel <idosch@nvidia.com>,
	Aaron Conole <aconole@redhat.com>
Subject: Re: [RFC PATCH net-next] selftests: forwarding: add a test for MAC Merge layer
Date: Mon, 13 Feb 2023 12:42:04 +0100	[thread overview]
Message-ID: <871qmtvlkj.fsf@kurt> (raw)
In-Reply-To: <20230210221243.228932-1-vladimir.oltean@nxp.com>

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]

On Sat Feb 11 2023, Vladimir Oltean wrote:
> The MAC Merge layer (IEEE 802.3-2018 clause 99) does all the heavy
> lifting for Frame Preemption (IEEE 802.1Q-2018 clause 6.7.2), a TSN
> feature for minimizing latency.
>
> Preemptible traffic is different on the wire from normal traffic in
> incompatible ways. If we send a preemptible packet and the link partner
> doesn't support preemption, it will drop it as an error frame and we
> will never know. The MAC Merge layer has a control plane of its own,
> which can be manipulated (using ethtool) in order to negotiate this
> capability with the link partner (through LLDP).
>
> Actually the TLV format for LLDP solves this problem only partly,
> because both partners only advertise:
> - if they support preemption (RX and TX)
> - if they have enabled preemption (TX)
> so we cannot tell the link partner what to do - we cannot force it to
> enable reception of our preemptible packets.
>
> That is fully solved by the verification feature, where the local device
> generates some small probe frames which look like preemptible frames
> with no useful content, and the link partner is obliged to respond to
> them if it supports the standard. If the verification times out, we know
> that preemption isn't active in our TX direction on the link.
>
> Having clarified the definition, this selftest exercises the manual
> (ethtool) configuration path of 2 link partners (with and without
> verification), and the LLDP code path, using the openlldp project.
>
> This is not really a "forwarding" selftest, but I put it near the other
> "ethtool" selftests.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---

Looks good to me. Is there any way to test this? I see mm support
implemented for enetc and Felix. However, I only have access to Intel
i225 NIC(s) which support frame preemption.

Thanks,
Kurt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

  parent reply	other threads:[~2023-02-13 11:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-10 22:12 [RFC PATCH net-next] selftests: forwarding: add a test for MAC Merge layer Vladimir Oltean
2023-02-13 10:51 ` Petr Machata
2023-02-13 11:39   ` Vladimir Oltean
2023-02-14 11:53     ` Petr Machata
2023-03-15 15:52       ` Vladimir Oltean
2023-03-16 11:10       ` Petr Machata
2023-03-16 13:43         ` Petr Machata
2023-02-13 11:42 ` Kurt Kanzenbach [this message]
2023-02-13 12:02   ` 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=871qmtvlkj.fsf@kurt \
    --to=kurt@linutronix.de \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=aconole@redhat.com \
    --cc=ferenc.fejes@ericsson.com \
    --cc=harini.katakam@amd.com \
    --cc=idosch@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    --cc=petrm@nvidia.com \
    --cc=pranavi.somisetty@amd.com \
    --cc=rui.sousa@nxp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox