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:   Tue, 29 Nov 2022 14:38:23 -0800
From:   Steve Williams <steve.williams@...cruise.com>
To:     unlisted-recipients:; (no To-header on input)
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [EXT] Re: [PATCH net-next] net/hanic: Add the hanic network
 interface for high availability links

On Wed, Nov 23, 2022 at 8:36 AM Jiri Pirko <jiri@...nulli.us> wrote:
>
> >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@...set pattern matching based streams.
>
> Vlan implementation could be easily done internally in hanic driver if
> needed, similar to bridge and openvswitch vlan implementations.

Hanic matches streams based on mac and vlan (with absence of vlan a
valid case) with the stream mapping somewhat localized. I see no
reason to not allow for in the future other stream matching methods, I
just didn't see the need for it at this point. If adding a specific
stream matching method is required to get this through design review,
then that is something I can look into. But this method is one of the
few (only?) stream matching methods that doesn't rely on sideband
data. But again, the stream matching code is localized, and it should
suffer expansion well, if that is the desire.

As for Vlan implementation, the hanic driver is aware of vlan tags (or
their absence) in order to do stream matching, but the actual
tagging/untagging is handled by the existing linux vlan support. I'm
not understanding why one might want hanic to do the actual vlan
tagging. Well, actually, if one wants hanic to bridge traffic between
enlisted ports then maybe that's a case where it might need to edit
vlan tags, but this is not something that hanic does at this point. I
don't see why it couldn't gain that functionality if it were
considered desirable.

-- 

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.