netdev - Re: [RFC PATCH net-next] docs: net: add an explanation of VF (and other) Representors

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

Message-ID: <20220811091720.1e82eb46@kernel.org>
Date:   Thu, 11 Aug 2022 09:17:20 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     Edward Cree <ecree.xilinx@...il.com>, ecree@...inx.com,
        netdev@...r.kernel.org, davem@...emloft.net, pabeni@...hat.com,
        edumazet@...gle.com, corbet@....net, linux-doc@...r.kernel.org,
        linux-net-drivers@....com, Jacob Keller <jacob.e.keller@...el.com>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        Saeed Mahameed <saeed@...nel.org>,
        Jiri Pirko <jiri@...nulli.us>,
        Shannon Nelson <snelson@...sando.io>,
        Simon Horman <simon.horman@...igine.com>
Subject: Re: [RFC PATCH net-next] docs: net: add an explanation of VF (and
 other) Representors

On Wed, 10 Aug 2022 15:58:54 -0700 Alexander Duyck wrote:
> > Sure, but as an application of that, people talk about e.g. "host"
> >  and "device" ends of a bus, DMA transfer, etc.  As a result of which
> >  "host" has come to mean "computer; server; the big rack-mounted box
> >  you plug cards into".
> > A connotation which is unfortunate once a single device can live on
> >  two separate PCIe hierarchies, connected to two computers each with
> >  its own hostname, and the one which owns the device is the cluster
> >  of embedded CPUs inside the card, rather than the big metal box.  
> 
> I agree that "host" isn't going to work as a multi-host capable device
> might end up having only one "host" that can actually handle the
> configuration of the switch for the entire device. So then you have
> different types of "host" interfaces.

Thank $deity I haven't had to think about multi-host NPU/DPU/IPUs
for a couple of years now, but I think trying to elect a leader in
charge across the hosts is not a good idea there. Much easier to proxy
all configuration thru FW, as much as I hate that (since FW is usually
closed).

That said choosing the term is about intuition not proofs so "host"
won't fly.