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]

Message-ID: <CA+sq2CcCYUekJjxfM_crrQxiP5j1dHqixVvHWKO9YtcfaVVcFw@mail.gmail.com>
Date:   Fri, 22 Nov 2019 01:15:40 +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:53 AM Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:

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

Again how do you know there is only DPDK SDK available with us ?
Just by reading DPDK documentation, is it right to conclude that way.

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

If a Intel machine with external NIC can be used for something otherthan
pure network processing, then why can't this. I am not saying this is 'the'
intended application, just giving an example of the previous silicon
with on-chip NIC.

There are many other things, can use it for NFVs, containers, virtual machines
with PF (netdev) in kernel and VFs in userspace. There are many real
life applications.

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

Yes, I am very well aware of the fact that upstream netdev community
doesn't like DPDK.
I did attend couple of netdev conferences where it was loudly said
"DPDK is not kernel" :-)

And yes I agree there was a long gap in between, but this time i am
going to publish PF/VF netdev drivers.

Thanks,
Sunil.