[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+sq2CdbXgdsGjG-+34mNztxJ-eQkySB6k2SumkXMUkp7bKtwQ@mail.gmail.com>
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.
Powered by blists - more mailing lists