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 08:19:29 +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 Thu, Nov 21, 2019 at 6:11 AM Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:
>
>
> Please double check this renders the way you expect. You may want to
> add empty lines before lists.

Okay, will recheck.

> > +
> > +=============================================
> > +Marvell OcteonTx2 RVU Kernel Drivers
> > +=============================================
>
> Shouldn't these lines be the length of the text?

Haven't done this documentation before, will other files and fix if necessary,

> > +
> > +Resource provisioning examples
> > + - A PF/VF with NIX-LF & NPA-LF resources works as a pure network device
> > + - A PF/VF with CPT-LF resource works as a pure cyrpto offload device.
>
> s/cyrpto/crypto/

Thanks, will fix.

> > +
> > +.. kernel-figure::  resource_virtualization_unit.svg
> > +   :alt:     RVU
> > +   :align:   center
> > +   :figwidth:        60em
> > +
> > +   RVU HW block connectivity
>
> The diagram isn't really bringing much value if you ask me. The text in
> the last section is quite a bit better. Perhaps show packet flow?

If someone doesn't want read the text fully, then i thought the
diagram would help
in getting an idea about the RVU HW block connectivity.

> > +Firmware setups following stuff before kernel boots
> > + - Enables required number of RVU PFs based on number of physical links.
> > + - Number of VFs per PF are either static or configurable at compile time.
>
> compile time of the firmware?

Yes, firmware.

>
> > +   Based on config, firmware assigns VFs to each of the PFs.
> > + - Also assigns MSIX vectors to each of PF and VFs.
> > + - These are not changed after kernel boot.
>
> Can they be changed without FW rebuild?

No, they cannot be.

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

> There is a bunch of cgx_* exports in the AF module, which seem to have
> no uses upstream, too (they are only called from rvu_cgx.c which is
> compiled into the same module).

In the very first patchset submitted CGX and AF drivers were separate modules.
Based on suggestions we merged both of them into a single module.
The export symbols are not needed, i will submit a separate patch to
clean them up.