Excerpts from Haren Myneni's message of April 18, 2021 7:06 am:
> 
> pHyp introduces two different type of credits: Default and Quality
> of service (QoS).
> 
> The total number of default credits available on each LPAR depends
> on CPU resources configured. But these credits can be shared or
> over-committed across LPARs in shared mode which can result in
> paste command failure (RMA_busy). To avoid NX HW contention, phyp
> introduces QoS credit type which makes sure guaranteed access to NX
> resources. The system admins can assign QoS credits for each LPAR
> via HMC.
> 
> Default credit type is used to allocate a VAS window by default as
> on powerVM implementation. But the process can pass VAS_WIN_QOS_CREDITS


There's some interchanging of pHyp and PowerVM in the series.

PowerVM is probably the better term to use, with uppercase P.
Unless you mean PAPR or pseries etc.

I think you can say the PAPR VAS spec has two different types of 
credits, rather than say a specific hypervisor is introducing them.

> flag with VAS_TX_WIN_OPEN ioctl to open QoS type window.
> 
> Signed-off-by: Haren Myneni <ha...@linux.ibm.com>
> ---
>  arch/powerpc/include/uapi/asm/vas-api.h | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/include/uapi/asm/vas-api.h 
> b/arch/powerpc/include/uapi/asm/vas-api.h
> index ebd4b2424785..eb7c8694174f 100644
> --- a/arch/powerpc/include/uapi/asm/vas-api.h
> +++ b/arch/powerpc/include/uapi/asm/vas-api.h
> @@ -13,11 +13,15 @@
>  #define VAS_MAGIC    'v'
>  #define VAS_TX_WIN_OPEN      _IOW(VAS_MAGIC, 0x20, struct 
> vas_tx_win_open_attr)
>  
> +/* Flags to VAS TX open window ioctl */
> +/* To allocate a window with QoS credit, otherwise default credit is used */
> +#define      VAS_WIN_QOS_CREDITS     0x0000000000000001
> +
>  struct vas_tx_win_open_attr {

Some consistency of naming might help, VAS_TX_WIN_FLAG_QOS_CREDIT.

>       __u32   version;
>       __s16   vas_id; /* specific instance of vas or -1 for default */
>       __u16   reserved1;
> -     __u64   flags;  /* Future use */
> +     __u64   flags;
>       __u64   reserved2[6];
>  };
>  
> -- 
> 2.18.2
> 
> 
> 

Reply via email to