netdev - Re: [patch net-next 0/9] mlxsw: implement port mirroring offload

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <83af7d8a-5f9c-aa3e-53cd-641cb175f66d@mojatatu.com>
Date:	Thu, 21 Jul 2016 05:00:33 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org
Cc:	davem@...emloft.net, yotamg@...lanox.com, eladr@...lanox.com,
	idosch@...lanox.com, nogahf@...lanox.com, ogerlitz@...lanox.com
Subject: Re: [patch net-next 0/9] mlxsw: implement port mirroring offload

On 16-07-21 04:19 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@...lanox.com>
>
> This patchset introduces tc matchall classifier and its offload
> to Spectrum hardware. In combination with mirred action, defined port mirroring
> setup is offloaded by mlxsw/spectrum driver.
>
> The commands used for creating mirror ports:
>
> # ingress mirroring using matchall
> tc qdisc  add dev eth25 handle ffff: ingress
> tc filter add dev eth25 parent ffff:            \
>         matchall skip_sw                        \
>         action mirred egress mirror             \
>         dev eth27
>
> # egress mirroring using matchall
> tc qdisc add dev eth25 handle 1: root prio
> tc filter add dev eth25 parent 1:               \
>         matchall skip_sw                        \
>         action mirred egress mirror             \
>         dev eth27
>

Kudos to Mellanox for all this nice work!

I am assuming the chip is capable as well of doing
mirroring via the ACL infrastructure and you are adding
this classifier because you are going via the SPAN
infrastructure. If answer is yes, thencould we have used
a classifier like u32 here?
i.e something like:
tc filter add dev eth25 xxxx protocol all \
u32 match u32 0 0 \
action mirred ...

BTW: I am not a big styling lawyer on netdev (I am normally the
victim) but would be useful to look at some of these patches with
that coding style in in mind (I think some of the chip specific
patches had some style issue in function definition).

again - kudos

cheers,
jamal