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

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]

Date:   Wed, 23 Nov 2022 15:52:17 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     Steve Williams <steve.williams@...cruise.com>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        vinicius.gomes@...el.com, xiaoliang.yang_1@....com,
        Andrew Lunn <andrew@...n.ch>
Subject: Re: [EXT] Re: [PATCH net-next] net/hanic: Add the hanic network
 interface for high availability links

Wed, Nov 23, 2022 at 03:26:14PM CET, vladimir.oltean@....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.