netdev - Re: [PATCH v3 16/16] Documentation: net: octeontx2: Add RVU HW and drivers overview.

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]

Date:   Thu, 21 Nov 2019 10:43:16 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Sunil Kovvuri <sunil.kovvuri@...il.com>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Sunil Goutham <sgoutham@...vell.com>
Subject: Re: [PATCH v3 16/16] Documentation: net: octeontx2: Add RVU HW and
 drivers overview.

On Thu, 21 Nov 2019 08:19:29 +0530, Sunil Kovvuri wrote:
> > Thanks for the description, I was hoping you'd also provide more info
> > on how the software componets of the system fit together. Today we only
> > have an AF driver upstream. Without the PF or VF drivers the card is
> > pretty much unusable with only the upstream drivers, right?
> 
> I will start submitting netdev drivers (PF and VF) right after this patchset.
> And just FYI this is not a NIC card, this HW is found only on the ARM64
> based OcteonTX2 SOC.

Right, that's kind of my point, it's not a simple NIC, so we want
to know what are all the software components. How does a real life
application make use of this HW.

Seems like your DPDK documentation lays that out pretty nicely:

https://doc.dpdk.org/guides/platform/octeontx2.html

It appears the data path components are supposed to be controlled by
DPDK.

After reading that DPDK documentation I feel like you'd need to do some
convincing to prove it makes sense to go forward with this AF driver at
all. For all practical purposes nobody will make use of this HW other
than through the DPDK-based SDK, so perhaps just keep your drivers in
the SDK and everyone will be happy?