[PATCH V3 6/6] crypto/nx: Add P9 NX support for 842 compression engine

[Michael Neuling]

> > > +static int nx842_powernv_crypto_init_vas(struct crypto_tfm *tfm)
> > > +{
> > > +       struct nx842_crypto_ctx *ctx = crypto_tfm_ctx(tfm);
> > > +       struct nx842_workmem *wmem;
> > > +       struct nx842_coproc *coproc;
> > > +       int ret;
> > > +
> > > +       ret = nx842_crypto_init(tfm, &nx842_powernv_driver);
> > > +
> > > +       if (ret)
> > > +               return ret;
> > > +
> > > +       wmem = PTR_ALIGN((struct nx842_workmem *)ctx->wmem,
> > > WORKMEM_ALIGN);
> > > +       coproc = per_cpu(coproc_inst, smp_processor_id());
> > 
> > this is wrong.  the crypto transform init function is not guaranteed
> > to be called by the same processor that later uses it.  Just because
> > that happens to be how zswap operates doesn't guarantee other crypto
> > users will do the same.
> 
> Dan, Sorry missed this comment. 
> 
> Right, The actual crypto request can be executed on other processor than the
> CPU when the init is executed. The main goal is open send window on the NX
> engine which is on the same chip for the corresponding CPU. So we are OK if
> the request is scheduled on other CPU as long as it belongs to same chip.
> Otherwise in the worst case we will end up using remote NX.  

You want the NX to be close to the requester CPU, but probably more importantly
you want the NX close to the memory it's going to be operating on. 

Preferably they would all be on the same node.

Mikey