netdev - Re: 回复: [RFC PATCH net-next 2/7] net: ethtool: add support for Frame Preemption and MAC Merge layer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20221114154248.57v3gq4g7jwsgfom@skbuf>
Date:   Mon, 14 Nov 2022 15:42:49 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Xiaoliang Yang <xiaoliang.yang_1@....com>
CC:     Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Michal Kubecek <mkubecek@...e.cz>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Rui Sousa <rui.sousa@....com>,
        Ferenc Fejes <ferenc.fejes@...csson.com>,
        Richie Pearn <richard.pearn@....com>
Subject: Re: 回复: [RFC PATCH net-next 2/7] net: ethtool: add support for Frame Preemption and MAC Merge layer

Hi Xiaoliang,

On Thu, Nov 10, 2022 at 10:33:50AM +0000, Xiaoliang Yang wrote:
> On Sep 15, 2022, Vladimir wrote:
> > > That's a good point (your understanding of the flow is similar to mine).
> > > This seems a good idea. But we may have to wait for a bit until we
> > > have a LLDP implementation that supports this.
> > 
> > This is circular; we have a downstream patch to openlldp that adds support for
> > this TLV, but it can't go anywhere until there is mainline kernel support.
> > 
> > What about splitting out MAC merge support from FP support, and me
> > concentrating on the MAC merge layer for now? They're independent up to a
> > pretty high level. The MAC merge layer is supposed to be controlled by the
> > LLDP daemon and be pretty much plug-and-play, while the FP adminStatus is
> > supposed to be set by some high level administrator, like a NETCONF client.
> 
> I agree that splitting out MAC merge support from FP support, they are defined
> by different spec. I'm trying to add LLDP exchange verification support. The
> procedure is like following:
>  1. enable preemption on local port by using "ethtool", do not active preemption.

"Enable" and "activate" are different things only if verification is used.
Otherwise, they mean the same thing.

In turn, LLDP does not control whether verification is used or not. So,
from the perspective of the LLDP daemon, you can't "enable" but "not activate"
preemption.

And I wouldn't expect the LLDP flow to require use of ethtool.

And I think that enabling preemption at step 1 is too early. Why enable
it, if we don't know if the link partner supports it?

>  2. Decode the LLDP TLV of remote port and ensure the remote port supports
> and enables preemption.
>  3. Run SMD-v/r verify process on local port or active the preemption directly.

Verification as defined by 802.3 is, as mentioned, independent of the
Additional Ethernet Capabilities TLV.
Which seems to be a good thing, considering that 2 link partners A and B
don't need to have coordinated settings for verification (verify_disable
doesn't need to be in sync). Any device with the MAC Merge layer turned on is
required to send SMD-R (response) frames in response to SMD-V (verification),
regardless of whether it sends SMD-V frames of its own.

So those who enable verification should get a response from those who
don't enable it, and those who don't enable verification don't cause the
link partners who do enable it to fail their own verification.

The only thing to agree on is this: if the link partner supports
preemption, and you support preemption, then how does the LLDP daemon
decide whether to actually *enable* preemption? My assumption is that
it's fine to unconditionally enable it as long as it's supported.
No configuration or user override is needed.

FWIW, I have my own patch on the openlldp project (yes, not lldpd) which
adds support for the MAC Merge layer. I hope I can wrap everything up
some time next week and resend everything in a state that reflects what
I've been cooking in the meantime. I don't have a solution for the
adminStatus yet, but I guess I'll try to add it via the netlink interface
of tc-taprio and tc-mqprio.

>  4. Send updated LLDP TLV to remote port.
>  5. Disable preemption on local port and repeat step 1-4 when link down/up.
> 
> The struct "ethtool_mm_cfg" seems not fit this procedure. I update it:
> struct ethtool_mm_cfg {
> 	u32 verify_time;
> 	bool verify_disable;
> 	bool enabled;
> +	bool active; // Used to active or start verify preemption by LLDP daemon.

What sense does it make to "force" preemption as active? What would this
do in terms of driving the internal state machines of the hardware, i.e.
force FP active in which way? It's active when enabled and verification
is either disabled, or enabled and complete.

> 	u8 add_frag_size;
> };
> If we want to enable/disable the LLDP exchange verification, maybe we need
> to add more parameters like "bool lldp_verify_enable"

Control the LLDP exchange via kernel UAPI? But why? What difference does
it make to the kernel whether there is an LLDP daemon or not? LLDP frames
are normal packets sent via PF_PACKET sockets, no special driver involvement
needed. Not the same thing as SMD-V/SMD-R hardware verification.