netdev - Re: [PATCH net-next 0/9] mlxsw: Prepare SPAN API for upcoming changes

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] [day] [month] [year] [list]

Message-Id: <20200430.130253.176477054285435962.davem@davemloft.net>
Date:   Thu, 30 Apr 2020 13:02:53 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     idosch@...sch.org
Cc:     netdev@...r.kernel.org, jiri@...lanox.com, mlxsw@...lanox.com,
        idosch@...lanox.com
Subject: Re: [PATCH net-next 0/9] mlxsw: Prepare SPAN API for upcoming
 changes

From: Ido Schimmel <idosch@...sch.org>
Date: Thu, 30 Apr 2020 20:01:07 +0300

> Switched port analyzer (SPAN) is used for packet mirroring. Over mlxsw
> this is achieved by attaching tc-mirred action to either matchall or
> flower classifier.
> 
> The current API used to configure SPAN consists of two functions:
> mlxsw_sp_span_mirror_add() and mlxsw_sp_span_mirror_del().
> 
> These two functions pack a lot of different operations:
> 
> * SPAN agent configuration: Determining the egress port and optional
>   headers that need to encapsulate the mirrored packet (when mirroring
>   to a gretap, for example)
> 
> * Egress mirror buffer configuration: Allocating / freeing a buffer when
>   port is analyzed (inspected) at egress
> 
> * SPAN agent binding: Binding the SPAN agent to a trigger, if any. The
>   current triggers are incoming / outgoing packet and they are only used
>   for matchall-based mirroring
> 
> This non-modular design makes it difficult to extend the API for future
> changes, such as new mirror targets (CPU) and new global triggers (early
> dropped packets, for example).
> 
> Therefore, this patch set gradually adds APIs for above mentioned
> operations and then converts the two existing users to use it instead of
> the old API. No functional changes intended. Tested with existing
> mirroring selftests.
> 
> Patch set overview:
> 
> Patches #1-#5 gradually add the new API
> Patches #6-#8 convert existing users to use the new API
> Patch #9 removes the old API

Looks good, series applied, thanks!