[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALHoRjeQij510y223baX3QATVaivyozPzJSb71Aq_noz5gFYTg@mail.gmail.com>
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.
Powered by blists - more mailing lists