Re: [EXT] Re: [PATCH net-next] net/hanic: Add the hanic network interface for high availability links

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Wed, Nov 23, 2022 at 03:52:17PM +0100, Jiri Pirko wrote:
> >Reworded, why must the hanic functionality to be in the kernel?
> 
> I guess for the same reason other soft netdevice driver are in the
> kernel. You can do bridge, bond, etc in a silimilar way you described
> here...

You have to consider the value added to the kernel in each case
(and also what were the best practices when those other drivers were
introduced; you can't just use bonding as a precedent for anything).

I believe hanic does not even attempt to solve a generic enough problem
to be the FRER endpoint driver for the Linux kernel. It assumes streams
will be {MAC SA, VID} on RX, and {MAC DA, VID} on TX. That's already
policy enforced by the kernel, when the kernel should just provide the
mechanisms for user space to enforce one. This type of stream
classification will not be the case for 802.1CB networks in general.
According to some of my own research, you can also solve some of the
problems Steve is addressing in other ways.

For example, in order to make {MAC DA, VLAN} streams identify both the
sender and the receiver, one can arrange that in a network, each sender
has its own VLAN ID which identifies it as a sender. I know of at least
one network where this is the case. But this would also be considered
policy, and I'm not suggesting that hanic should use this approach
rather than the other. 802.1CB simply does not recommend one mode of
arranging streams over another.

The fact that hanic needs 802.1Q uppers as termination points for
{MAC, VLAN} addresses seemst to simply not scale for IP-based streams,
or generic byte@offset pattern matching based streams.

Additionally, the hanic driver will probably need a rewrite when Steve
enables some options like CONFIG_PROVE_LOCKING or CONFIG_DEBUG_ATOMIC_SLEEP.
It currently creates sysfs files for streams from the NET_TX softirq.
It's not even clear to me that stream auto-discovery is something
desirable generally. I'd rather pre-program my termination streams if
I know what I'm doing, rather than let the kernel blindly trust possibly
maliciously crafted 802.1CB tags.

When I suggested a tap based solution, I was trying to take the Cruise
hanic driver, as presented, at face value and to propose something which
seems like a better fit for it. I wasn't necessarily trying to transform
the hanic driver into something useful in general for the kernel, since
I don't know if that's what Steve's goal is.