[dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function processing

[Coyle, David]

Hi Kevin,

> -----Original Message-----
> From: Kevin Traynor <ktraynor at redhat.com>
> Sent: Wednesday, April 22, 2020 3:02 PM
> 
> Hi David,
> 
> On 21/04/2020 18:23, Coyle, David wrote:
> > Thank you Thomas for your input.
> >
> > We would like to request that the Tech-Board (CC'ed) also review the
> proposal to help us reach a consensus.
> >
> 
> The discussion on the mailing list still looks active and I think that's where it
> should continue until there is no reasonable hope of consensus.
> I'm not sure discussing over irc at TB will find a better technical solution.

[DC] Yes, there has been some further proposals and discussions today, mainly around the use
of rte_security. Although there are a few challenges to work around here, it is an approach we
had already considered and it would seem like a good compromise to the rawdev approach. 

With that in mind, we are happy to let this play out further on the mailing list for now.

If we can reach consensus on using rte_security, then we are happy to go with that and investigate
and develop it further.

> 
> > If the current proposal is not acceptable, we would welcome feedback
> > from the board on how to rework our proposal to something that would be
> acceptable.
> >
> > For the benefit of the Tech-Board here is the back-ground to our
> > proposal for Rawdev-based multi-function
> > processing:
> > - The primary objective is to support the AESNI MB combined Crypto-CRC
> processing capability in DPDK and
> >    in future to add support for combined Crypto-CRC support in QAT.
> > - The cryptodev API was considered unsuitable because CRC is not a
> cryptographic operation, and this would
> >    also preclude other non-crypto operations in the future such as
> compression.
> > - The rte_security API was also not considered suitable for chaining of non-
> crypto operations such as CRC,
> >    as Declan pointed out below.
> > - A new Accelerator API was proposed as an RFC but was not pursued due
> to community feedback that a
> >    new API would not be welcome for a single use-case.
> > - Using Rawdev for multi-function processing was then proposed and,
> initially, as there was no opposition
> >    we implemented a patch-set for this approach.
> >
> > It was considered that a Rawdev-based multi-function approach would be
> suitable for the following reasons:
> > 1) Multi-function processing for Crypto-CRC cases is not a good fit for any of
> the existing DPDK classes.
> > 2) Rawdev was intended for such specialized acceleration processing that
> are not a good fit for existing DPDK
> >      classes.
> > 3) Rawdev was also intended as somewhere that new use-cases like this
> could be prototyped and developed,
> >      such as Declan mentions below
> > 4) The Rawdev-based multi-function proposal is extensible and we would
> hope that it can evolve to support
> >      new use-cases and target new devices in the future with the
> communities involvement.
> >
> 
> This is a useful summary and explaining your approach but it doesn't mention
> the counter arguments, so it doesn't seem balanced. Of course people can
> read that in the ML thread.

[DC] That is a fair point, and something we will keep in mind for the future if
we need to come back to the tech-board.

> 
> Kevin.
>