[Skiboot] [RFC 0/3] phb4/capp: Provide user tunable for STQ/DMA engine allocation

[Frederic Barrat]

Le 09/09/2018 à 13:41, Vaibhav Jain a écrit :
> When CAPP is initialized on request of CXL, opal reserves certain number
> of PEC STQ/DMA engines needed for communication with the PSL/XSL on the card.
> Since this allocation comes from the shared pool of PEC resources, it will have
> an impact on the performance of a CAPI or PCI throughput.
> 
> Presently this allocation is statically defined in skiboot with CAPP init code
> only taking into account the link width. However since different cards will
> have will different workload properties hence it might be prudent to let user
> tune these values to get an optimal performance for their CAPI workload.
> 
> Hence this patchset proposes a new scheme called 'capp attribute overrides'
> that lets user set a nvram config to override the the number of DMA/STQ engines
> opal reserves for CAPP. The nvram config is defined following a certain
> convention to address multiple CAPPs present in the system.
> 
> The first patch "capp: Add ability to fetch CAPP attribute override values"
> implements infrastructure in skiboot to search for an attribute override for
> given CAPP in nvram. The subsequent two patches use this infrastructure to
> implement override for number of STQ/DMA engines allocates to CAPP.
> 

I think the value is mostly for debug/lab experiments. We've been asked 
quite a few times to update those settings, and each time, it requires 
an updated skiboot, install, etc... On top of that, we always seem to 
get it wrong, so having a centralized point where we decide the dma 
engine and storage queue counts, then derive the capp setup and PEC 
setup seems better to me (instead of having 2 disconnected flows as it 
currently is).

As already mentioned, driving it from linux would require at least an 
new opal call. But the problem is that the driver doesn't really know 
what the optimum settings are for the AFU and it needs to be done early, 
leaving little time for customisation. I believe that to address it 
correctly, we'd need some PSL extension so that the AFU could report 
what it needs and that the driver could query. But since that's capi2, I 
wouldn't hold my breath.

   Fred

> Vaibhav Jain (3):
>    capp: Add ability to fetch CAPP attribute override values from nvram
>    phb4/capp: Introduce 'stq-buffers' capp attribute override
>    phb4/capp: Introduce 'dma-engines' capp attribute override
> 
>   hw/capp.c      |  50 +++++++++++++++++++++
>   hw/phb4.c      | 118 ++++++++++++++++++++++++-------------------------
>   include/capp.h |   2 +
>   3 files changed, 110 insertions(+), 60 deletions(-)
>