Message-ID: <CALHoRjcw8Du+4Px__x=vfDfjKnHVRnMmAhBBEznQ2CfHPZ9S0A@mail.gmail.com>
Date:   Tue, 22 Nov 2022 12:51:53 -0800
From:   Steve Williams <steve.williams@...cruise.com>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        vinicius.gomes@...el.com, xiaoliang.yang_1@....com
Subject: Re: [EXT] Re: [PATCH net-next] net/hanic: Add the hanic network
 interface for high availability links

On Tue, Nov 22, 2022 at 3:34 AM Vladimir Oltean <vladimir.oltean@....com> wrote:
>
>
> I have some problems getting it to compile with W=1 C=1 (possibly not only
> with those flags).
>

Looks like something I get to address.

>
> It will take me a while until I come with more intelligent feedback, but
> as a first set of questions (based solely on the documentation and not
> the code, I'm wondering a few things):
>
> 1. You seem to create a usage model which is heavily optimized for ping
>    (the termination plane), but not at all optimized for the forwarding
>    plane. What I mean is that the documentation says "Inbound traffic
>    that does not have an R-TAG is assumed to not be redundant, and is
>    simply passed up the network stack." That's a pretty big limitation,
>    isn't that so? If you want to build a RED box (intermediary device
>    which connects a non-redundant device into a redundant network) out
>    of a Linux device with hanic, how would you do that? Inbound traffic
>    which comes from the FRER-unaware device must match on a TSN stream
>    which says where it should go and how it should be tagged. And the
>    set of destination ports for inbound traffic may well be a subset of
>    the other enlisted ports, not the hanic device or one of its VLAN
>    uppers.

This is indeed intended to cover the talker/listener cases, so doesn't implement
bridging. Besides, there are software bridges for that. This driver provides a
way for outbound traffic to be tagged and duplicated out multiple ports, and
inbound R-TAG'ed packets to be deduplicated. This is probably most like bonding,
and I did look at the bonding driver. But the bulk of the hanic driver is the
R-TAG protocol handling. The ethernet packet editing seemed more than
the bonding driver would handle well, and I also wanted this implementation
to be as lightweight as possible.

Hanic tries to make the R-TAG handling transparent, so a "hanic" device can
be connected to software bridges if one wants to implement a converter box,
but in our experience that's more commonly handled by specialized hardware.

> 2. What about stream identification rules which aren't based on MAC DA/VLAN?
>    How about MAC SA/VLAN, or SIP, DIP, or active identification rules,
>    or generic byte@...set pattern matching?

Generic filtering and/or dynamic stream identification methods just seemed
out of scope for this driver. Certainly out of scope for our needs. Although as
you noted, there are some controls on this matching, mostly for outbound
traffic, in order to allow some streams to be high-availability, and some to
be not.

> 3. Shouldn't TSN streams be input by NETCONF/YANG in a useful industrial
>    production network, rather than be auto-discovered based on incoming
>    and outgoing traffic?

In theory yes, but the self-configuring has proven helpful. In our practical
systems, there are switches that are routing tagged traffic around, and they
do indeed forward based on fixed routing rules. This driver makes for a clean
way to act as an endpoint in that network. "It just works."

> I mean, I can truly, genuinely understand why you made some of the
> choices you've made in the design of this driver, but the more I look at
> Xiaoliang's tc filter/action based take, the more I get the feeling that
> his approach is the way to fully exploit what can be accomplished with
> the 802.1CB standard. What you're presenting is more like your take on a
> subset that's useful to you (I mean, it *is* called "Cruise High
> Availability NIC driver", so at least it's truthful to that).

Yes, hanic implements a practical subset of the standard, and I try to be
clear about that in the documentation.

-- 

Stephen Williams

Senior Software Engineer

Cruise

-- 


*Confidentiality Note:* We care about protecting our proprietary 
information, confidential material, and trade secrets. This message may 
contain some or all of those things. Cruise will suffer material harm if 
anyone other than the intended recipient disseminates or takes any action 
based on this message. If you have received this message (including any 
attachments) in error, please delete it immediately and notify the sender 
promptly.

Powered by blists - more mailing lists