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 03:26:14PM CET, vladimir.oltean@nxp.com wrote:
>On Tue, Nov 22, 2022 at 12:51:53PM -0800, Steve Williams wrote:
>> 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.
>
>> Hanic tries to make the R-TAG handling transparent,
>
>> Generic filtering and/or dynamic stream identification methods just seemed
>> out of scope for this driver. Certainly out of scope for our needs.
>
>> Yes, hanic implements a practical subset of the standard, and I try to be
>> clear about that in the documentation.
>
>I'm back with a more intelligent question, after looking a bit at the
>code and at the problem it tries to solve.
>
>The question is: why don't you create a tap interface, and a user space
>program which is given the physical ports and tap interface as command
>line arguments, and does the following:
>
>- on reception from physical interfaces, handles 802.1CB traffic from
>  physical ports, eliminates the duplicates and pops the R-TAG, then
>  sends the packets to the tap interface
>- handles packets transmitted to the tap, splits them and pushes
>  whatever R-TAG is needed, then forwards them to the physical network
>  interfaces
>
>Then your Cruise 802.1CB endpoint solution becomes a user space handler
>for a tap interface. To users of your solution, it's the same thing,
>except they open their socket on a tap interface and not on a hanic
>interface.
>
>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...


>
>Thank you.