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]

Message-ID: <20191121112335.7c2916d8@cakuba.netronome.com>
Date:   Thu, 21 Nov 2019 11:23:35 -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 Fri, 22 Nov 2019 00:43:14 +0530, Sunil Kovvuri wrote:
> On Fri, Nov 22, 2019 at 12:13 AM Jakub Kicinski 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 ?

Based on the fact that you only have a DPDK SDK for it?

> 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

Are you saying someone will use a Octeon as just an ARM
server? Seriously someone will buy an NPU and use it for
something else than network processing? 

> 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.

Well you didn't bother to upstream it until now. You're just pushing
admin parts of your DPDK solution. Can you honestly be surprised the
upstream netdev community doesn't like that?