Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <567f8eb33e3d2d2d7be7a922aa22566534f9a28a.camel@linux.ibm.com>
Subject: Re: [V3 PATCH 07/16] powerpc/vas: Define QoS credit flag to
 allocate window
From:   Haren Myneni <haren@linux.ibm.com>
To:     Nicholas Piggin <npiggin@gmail.com>, herbert@gondor.apana.org.au,
        linux-crypto@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
        mpe@ellerman.id.au
Cc:     haren@us.ibm.com, hbabu@us.ibm.com
Date:   Mon, 10 May 2021 19:12:11 -0700
In-Reply-To: <1620625758.4u2ddwmbaj.astroid@bobo.none>
References: <a910e5bd3f3398b4bd430b25a856500735b993c3.camel@linux.ibm.com>
         <90328d5aa92016434f3061ec7cadc812ea2c5dbc.camel@linux.ibm.com>
         <1620625758.4u2ddwmbaj.astroid@bobo.none>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.2 (3.36.2-1.fc32) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Mon, 2021-05-10 at 15:54 +1000, Nicholas Piggin wrote:
> 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.

DEF and QoS credits types are introduced by the hypervisor, not VAS
PAPR. We did not have these types on powerNV. 

> 
> > flag with VAS_TX_WIN_OPEN ioctl to open QoS type window.
> > 
> > Signed-off-by: Haren Myneni <haren@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.

Sure, will change.
> 
> >  	__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
> > 
> > 
> >