Re: Port mirroring, v2 (RFC)

On Tue, 18 Jan 2022 11:37:05 -0600 Alex Elder wrote:

I'm basically ready to go on this, either way (using a
misc device, or--preferably--using a netdev).

I'm just trying to avoid getting that fully working,
then learning when I submit patches that someone thinks
it's the wrong way to go about it.

If a netdev is acceptable, my remaining issues are:
- Whether/how to avoid having the device be treated
   as if it needed support from the network stack
   (i.e., as a "real" network interface, serving to
   send and receive packets).
- Similar, whether there are special configuration
   options that should be used, given the device's
   purpose.
- What to call this functionality.  I'll avoid "mirror"
   and will try to come up with something reasonable,
   but suggestions are welcome.

I can't claim that my opinions on this sort of stuff are very stable
but I like Andrew's suggestion and I'd even say maybe just debugfs...

We try hard to prevent any abuse of netdevs for carrying what is not
real networking traffic and keep the semantics clear. netdevs are not
meant as an abstraction, they are more of an exception to the
"everything is a file" Unix rule.

Another thing that could possibly work is devlink traps and
DEVLINK_TRAP_ACTION_MIRROR, but again, not sure if we want to bend that
interface which has pretty nice and clear semantics to support a vendor
use case which is an aberration from our forwarding model in the
first place...

So I'd do something simple in debugfs and if anyone really cares about
the forwarding details put the real effort into modeling/controlling 
the forwarding with Linux.