netdev - RE: [net-next 04/14] i40e: dump VF information in 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: <BL2PR07MB23064B547F325DD002E513FC8D1B0@BL2PR07MB2306.namprd07.prod.outlook.com>
Date:   Thu, 20 Apr 2017 20:12:59 +0000
From:   "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To:     David Miller <davem@...emloft.net>
CC:     "jiri@...nulli.us" <jiri@...nulli.us>,
        "gerlitz.or@...il.com" <gerlitz.or@...il.com>,
        "jeffrey.t.kirsher@...el.com" <jeffrey.t.kirsher@...el.com>,
        "mitch.a.williams@...el.com" <mitch.a.williams@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "jogreene@...hat.com" <jogreene@...hat.com>,
        "Dupuis, Chad" <Chad.Dupuis@...ium.com>,
        "Rangankar, Manish" <Manish.Rangankar@...ium.com>
Subject: RE: [net-next 04/14] i40e: dump VF information in debugfs

> > the HW pipeline itself can't be abstracted in this case.
> 
> I've heard that argument before, and I'm glad Jiri didn't drink the koolaide
> and instead wrote dpipe.

Perhaps "can't" was the wrong term to use, but I still believe there's an
inherent problem with applying the dpipe approach here.
dpipe abstraction is meant [And I admit that I'm not that familiar with its
fine-grain details, so feel free to correct me] to give an abstract
representation of functional things, I.e., bits in the HW pipeline the user
might care about and can gain something from sharing information
about it - decision-based statistics [such as in Jiri's initial submission] being
an immediate candidate for benefiting from such.

For the case of debugging you *could* do the same, but at a huge
implementation and code-bloat costs -
Let's assume user doesn't use 'magic values' for debug gathering,
Instead having some HW abstraction it can manipulate intelligibly.
What it means is that level of configurability is limited by the complexity
of the abstraction, and you have to recall the vast majority of the
abstraction would be in-depth about HW-specific bridges and signals
the user cares nothing about [with the exception of debug-data collection].

I surely wouldn't want to write a million lines of code just to provide such
a detailed abstraction.

.