netdev - Re: [net-next 07/15] net/mlx5: Bridge, expose FDB state via debugfs

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

Message-ID: <87v8fjvnhq.fsf@nvidia.com>
Date: Mon, 19 Jun 2023 11:37:30 +0300
From: Vlad Buslov <vladbu@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: Saeed Mahameed <saeed@...nel.org>, "David S. Miller"
	<davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, Eric Dumazet
	<edumazet@...gle.com>, Saeed Mahameed <saeedm@...dia.com>,
	<netdev@...r.kernel.org>, Tariq Toukan <tariqt@...dia.com>, Gal Pressman
	<gal@...dia.com>
Subject: Re: [net-next 07/15] net/mlx5: Bridge, expose FDB state via debugfs

On Sat 17 Jun 2023 at 00:48, Jakub Kicinski <kuba@...nel.org> wrote:
> On Fri, 16 Jun 2023 13:11:05 -0700 Saeed Mahameed wrote:
>> $ cat mlx5/0000\:08\:00.0/esw/bridge/bridge1/fdb
>> DEV              MAC               VLAN              PACKETS                BYTES              LASTUSE FLAGS
>> enp8s0f0_1       e4:0a:05:08:00:06    2                    2                  204           4295567112   0x0
>> enp8s0f0_0       e4:0a:05:08:00:03    2                    3                  278           4295567112   0x0
>
> The flags here are the only thing that's mlx5 specific?

Not exactly. This debugfs exposes the state of our bridge offload layer.
For example, when VF representors from different eswitches are added to
the same bridge every FDB entry on such bridge will have multiple
underlying offloaded steering rules (one per eswitch instance connected
to the bridge). User will observe the entries in all connected 'fdb'
debugfs' (all except the 'main' entry will have flag
MLX5_ESW_BRIDGE_FLAG_PEER set) and their corresponding counters will
increment only on the eswitch instance that is actually processing the
packets, which depends on the mode (when bonding device is added to the
bridge in single FDB LAG mode all traffic appears on eswitch 0, without
it the the traffic is on the eswitch of parent uplink of the VF). I
understand that this is rather convoluted but this is exactly why we are
going with debugfs.

> Why not add an API for dumping this kind of stats that other drivers
> can reuse?

As explained in previous paragraph we would like to expose internal mlx5
bridge layer for debug purposes, not to design generic bridge FDB
counter interface. Also, the debugging needs of our implementation may
not correspond to other drivers because we don't have a 'hardware
switch' on our NIC, so we do things like learning and ageing in
software, and have to deal with multiple possible mode of operations
(single FDB vs merged eswitch from previous example, etc.).

>
> The rest of the patches LGTM