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

[Jiri Pirko <jiri@resnulli.us>]

Wed, Nov 23, 2022 at 04:25:43PM CET, vladimir.oltean@nxp.com wrote:
>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.

Vlan implementation could be easily done internally in hanic driver if
needed, similar to bridge and openvswitch vlan implementations.


>
>Additionally, the hanic driver will probably need a rewrite when Steve
>enables some options like CONFIG_PROVE_LOCKING or CONFIG_DEBUG_ATOMIC_SLEEP.

Well, there are lots of other issues in the driver as it is right now.
I don't think it is worth to discuss it now.


>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

tap is slow. That is I guess the reason for kernel implementation.


>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.

Or, you can always implement this as a BPF program :)