All of lore.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: 13+ 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-03-17 15:35           ` Petr Machata
2023-03-17 15:45             ` Vladimir Oltean
2023-03-20 10:20               ` Petr Machata
2023-03-20 13:49             ` 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 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.