From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5716C433DF for ; Thu, 21 May 2020 20:52:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AB3942078B for ; Thu, 21 May 2020 20:52:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="MDiKGq2y" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729981AbgEUUwR (ORCPT ); Thu, 21 May 2020 16:52:17 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:43027 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728778AbgEUUwR (ORCPT ); Thu, 21 May 2020 16:52:17 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6D9035C00C4; Thu, 21 May 2020 16:52:16 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 21 May 2020 16:52:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=FDjHLS 98QpqdtvIr6hFPDME1kvXU6ZRy0mCau8zXmxE=; b=MDiKGq2yJPjRCQsjEnAI5K 1F5iNankDc3Tc132RiuZIjc+GAKYQbBxctsta4t23CrZ8bvbTfocKji1CRIsp4dp FRrIZkfXC/5/2ROXtXnsxeUdo5RnapTXLafOIQ9C3gw+P/59y217o1c8xT3XD+SM MDuN0yAOR/jd7EQsa92N1LpnS0y/AKcY4oCv+eMXCbsQL3hpZ4sytVVSchhrIdex 58tVUzbmvfV/bXfMOjNXnDXcsF8cAepYChYiaYYk4glo/A0Ood838wi4py3oALig ndGk8bVR0W3tRbHkaYOdlPY8yptImv/4MJQj5sSWtBPXQR0O3jwcr3oryov6XzFQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudduuddgudeghecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepkfguohcu ufgthhhimhhmvghluceoihguohhstghhsehiughoshgthhdrohhrgheqnecuggftrfgrth htvghrnhepgfevgfevueduueffieffheeifffgjeelvedtteeuteeuffekvefggfdtudfg keevnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucfkphepjeelrddujeeirddvge druddtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehiughoshgthhesihguohhstghhrdhorhhg X-ME-Proxy: Received: from localhost (bzq-79-176-24-107.red.bezeqint.net [79.176.24.107]) by mail.messagingengine.com (Postfix) with ESMTPA id A8F4A306649A; Thu, 21 May 2020 16:52:15 -0400 (EDT) Date: Thu, 21 May 2020 23:52:13 +0300 From: Ido Schimmel To: Jacob Keller Cc: Jakub Kicinski , Jiri Pirko , "netdev@vger.kernel.org" , petrm@mellanox.com, amitc@mellanox.com Subject: Re: devlink interface for asynchronous event/messages from firmware? Message-ID: <20200521205213.GA1093714@splinter> References: <20200520171655.08412ba5@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, May 21, 2020 at 01:22:34PM -0700, Jacob Keller wrote: > On 5/20/2020 5:16 PM, Jakub Kicinski wrote: > > On Wed, 20 May 2020 17:03:02 -0700 Jacob Keller wrote: > >> Hi Jiri, Jakub, > >> > >> I've been asked to investigate using devlink as a mechanism for > >> reporting asynchronous events/messages from firmware including > >> diagnostic messages, etc. > >> > >> Essentially, the ice firmware can report various status or diagnostic > >> messages which are useful for debugging internal behavior. We want to be > >> able to get these messages (and relevant data associated with them) in a > >> format beyond just "dump it to the dmesg buffer and recover it later". > >> > >> It seems like this would be an appropriate use of devlink. I thought > >> maybe this would work with devlink health: > >> > >> i.e. we create a devlink health reporter, and then when firmware sends a > >> message, we use devlink_health_report. > >> > >> But when I dug into this, it doesn't seem like a natural fit. The health > >> reporters expect to see an "error" state, and don't seem to really fit > >> the notion of "log a message from firmware" notion. > >> > >> One of the issues is that the health reporter only keeps one dump, when > >> what we really want is a way to have a monitoring application get the > >> dump and then store its contents. > >> > >> Thoughts on what might make sense for this? It feels like a stretch of > >> the health interface... > >> > >> I mean basically what I am thinking of having is using the devlink_fmsg > >> interface to just send a netlink message that then gets sent over the > >> devlink monitor socket and gets dumped immediately. > > > > Why does user space need a raw firmware interface in the first place? > > > > Examples? > > > > So the ice firmware can optionally send diagnostic debug messages via > its control queue. The current solutions we've used internally > essentially hex-dump the binary contents to the kernel log, and then > these get scraped and converted into a useful format for human consumption. > > I'm not 100% of the format, but I know it's based on a decoding file > that is specific to a given firmware image, and thus attempting to tie > this into the driver is problematic. You explained how it works, but not why it's needed :) > There is also a plan to provide a simpler interface for some of the > diagnostic messages where a simple bijection between one code to one > message for a handful of events, like if the link engine can detect a > known reason why it wasn't able to get link. I suppose these could be > translated and immediately printed by the driver without a special > interface. Petr worked on something similar last year: https://lore.kernel.org/netdev/cover.1552672441.git.petrm@mellanox.com/ Amit is currently working on a new version based on ethtool (netlink).