Date:   Wed, 27 May 2020 02:19:05 +0300
From:   Ido Schimmel <idosch@...sch.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, jiri@...lanox.com,
        mlxsw@...lanox.com, Ido Schimmel <idosch@...lanox.com>
Subject: Re: [PATCH net-next 00/14] mlxsw: Various trap changes - part 2

On Tue, May 26, 2020 at 03:14:37PM -0700, Jakub Kicinski wrote:
> On Tue, 26 May 2020 02:05:42 +0300 Ido Schimmel wrote:
> > From: Ido Schimmel <idosch@...lanox.com>
> > 
> > This patch set contains another set of small changes in mlxsw trap
> > configuration. It is the last set before exposing control traps (e.g.,
> > IGMP query, ARP request) via devlink-trap.
> 
> When traps were introduced my understanding was that they are for
> reporting frames which hit an expectation on the datapath. IOW the
> primary use for them was troubleshooting.
> 
> Now, if I'm following things correctly we have explicit DHCP, IGMP,
> ARP, ND, BFD etc. traps. Are we still in the troubleshooting realm?

First of all, we always had them. This patch set mainly performs some
cleanups in mlxsw.

Second, I don't understand how you got the impression that the primary
use of devlink-trap is troubleshooting. I was very clear and transparent
about the scope of the work from the very beginning and I don't wish to
be portrayed as if I wasn't.

The first two paragraphs from the kernel documentation [1] explicitly
mention the ability to trap control packets to the CPU:

"Devices capable of offloading the kernel’s datapath and perform
functions such as bridging and routing must also be able to send
specific packets to the kernel (i.e., the CPU) for processing.

For example, a device acting as a multicast-aware bridge must be able to
send IGMP membership reports to the kernel for processing by the bridge
module. Without processing such packets, the bridge module could never
populate its MDB."

In my reply to you from almost a year ago I outlined the entire plan for
devlink-trap [2]:

"Switch ASICs have dedicated traps for specific packets. Usually, these
packets are control packets (e.g., ARP, BGP) which are required for the
correct functioning of the control plane. You can see this in the SAI
interface, which is an abstraction layer over vendors' SDKs:

https://github.com/opencomputeproject/SAI/blob/master/inc/saihostif.h#L157

We need to be able to configure the hardware policers of these traps and
read their statistics to understand how many packets they dropped. We
currently do not have a way to do any of that and we rely on hardcoded
defaults in the driver which do not fit every use case (from
experience):

https://elixir.bootlin.com/linux/v5.2/source/drivers/net/ethernet/mellanox/mlxsw/spectrum.c#L4103

We plan to extend devlink-trap mechanism to cover all these use cases. I
hope you agree that this functionality belongs in devlink given it is a
device-specific configuration and not a netdev-specific one.

That being said, in its current form, this mechanism is focused on traps
that correlate to packets the device decided to drop as this is very
useful for debugging."

In the last cycle, when I added the ability to configure trap policers
[3] I again mentioned under "Future plans" that I plan to "Add more
packet traps.  For example, for control packets (e.g., IGMP)".

If you worry that packets received via control traps will be somehow
tunneled to user space via drop_monitor, then I can assure you this is
not the case. You can refer to this commit [4] from the next submission.

Thanks

[1] https://www.kernel.org/doc/html/latest/networking/devlink/devlink-trap.html
[2] https://lore.kernel.org/netdev/20190709123844.GA27309@splinter/
[3] https://lwn.net/Articles/815948/
[4] https://github.com/jpirko/linux_mlxsw/commit/4a5f0a8034f0f10301680fe68559e3debacf534d 

Powered by blists - more mailing lists