[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221123142558.akqff2gtvzrqtite@skbuf>
Date: Wed, 23 Nov 2022 16:26:14 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Steve Williams <steve.williams@...cruise.com>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
vinicius.gomes@...el.com, xiaoliang.yang_1@....com,
Jiri Pirko <jiri@...nulli.us>, Andrew Lunn <andrew@...n.ch>
Subject: Re: [EXT] Re: [PATCH net-next] net/hanic: Add the hanic network
interface for high availability links
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?
Thank you.
Powered by blists - more mailing lists