Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev and ethdev

[Thomas Monjalon <thomas@monjalon.net>]

08/08/2017 07:03, Shahaf Shuler:
> Monday, August 7, 2017 9:07 PM, Boris Pismenny:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > 04/08/2017 07:26, Hemant Agrawal:
> > > > On 8/3/2017 9:02 PM, Akhil Goyal wrote:
> > > > > Support for security operations is planned to be added in ethdev
> > > > > and cryptodev for the 17.11 release.
> > > > >
> > > > > For this following changes are required.
> > > > > - rte_cryptodev and rte_eth_dev structures need to be added new
> > > > > parameter rte_security_ops which extend support for security ops
> > > > > to the corresponding driver.
> > > > > - rte_cryptodev_info and rte_ethd_dev_info need to be added with
> > > > > rte_security_capabilities to identify the capabilities of the
> > > > > corresponding driver.
> > >
> > > It is not explained what is the fundamental difference between
> > > rte_security and rte_crypto?
> > > It looks to be just a technical workaround.
> > 
> > rte_security is a layer between crypto and NIC.
> > 
> > Today crypto sessions are created exclusively against crypto devices, but
> > they don't use network related fields, while the network namespace doesn't
> > use crypto related fields. We expect this API to represent crypto sessions
> > that combine network fields and allow to add/delete them for all devices.
> > 
> > For NICs we will use rte_flow with rte_security for inline/full crypto protocol
> > offload such as ESP.
> > 
> > >
> > > Why the ABI would be changed by rte_security additions?
> > >
> > > > > Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > >
> > > > Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> > >
> > > No more opinions outside of NXP?
> > > It seems there is not yet a consensus on how to manage IPsec offloading.
> > > I heard there were some phone calls about these stuff but nothing
> > > clear appears publicly on the mailing list.
> > > Looks to be a community failure.
> > 
> > We agreed to go ahead with this approach on one such phone call. I hope we
> > could use the dpdk github for development.
> > 
> > Acked-by: Boris Pismenny <borisp@mellanox.com>
> 
> Acked-by: Shahaf Shuler <shahafs@mellanox.com>

Applied
It means you have a chance to do this change in 17.11.
It does not mean you can be sure that the patches will be accepted.

This is introducing a new complexity.
It must be discussed with the technical board before approving
the final design in 17.11.