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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 22 Nov 2019 00:43:14 +0530
From:   Sunil Kovvuri <sunil.kovvuri@...il.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.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 Fri, Nov 22, 2019 at 12:13 AM Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:
>
> 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?

Based on what you concluded that nobody would use the HW otherthan with DPDK ?

Just because it's not a NIC, it doesn't mean it cannot be used with
applications otherthan DPDK.
Imagine a server (on the lines of Intel xeon) with on-chip NIC instead
of a external PCIe NIC.
A server machine is used for lots of workload applications which are
not DPDK based.
Marvell's ThunderX machine is one such example,
- It is an SoC with an on-chip NIC.
- Both kernel and DPDK network drivers are upstreamed.
  kernel: drivers/net/ethernet/cavium/thunder
  DPDK: https://doc.dpdk.org/guides/nics/thunderx.html

Even for a DPDK only application, there is still a management ethernet
needed to which user can do ssh etc
when there is no console available. And there is no need to supply
whole SDK to customer, just supply
firmware, get latest kernel and DPDK from mainline and use it.

Sorry, i don't understand why a driver for on-chip ethernet cannot be
upstreamed.

Thanks,
Sunil.