DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <akhil.goyal@nxp.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>, dpdk-dev <dev@dpdk.org>
Cc: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] DPDK Release Status Meeting 16/01/2020
Date: Thu, 16 Jan 2020 13:17:38 +0000	[thread overview]
Message-ID: <VE1PR04MB66397879FB5B89F276015D52E6360@VE1PR04MB6639.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <SN6PR11MB25581F1C6986AA92B483A7629A360@SN6PR11MB2558.namprd11.prod.outlook.com>

Hi Konstantin,

> Hi everyone,
> 
> >
> > * next-net-crypto
> >   * Pull request sent
> >   * There is a performance concern on some ipsec-gw patches,
> >     they can go in -rc2 if the issue is solved
> >   * CPU crypto from last release may be breaking ABI, need to confirm
> 
> AFAIK, there is no ABI breakage.

This is the output of validate-abi.sh.

	Change 							Effect
1 Field sym_cpu_process has been added to this type. 	              1) This field will not be initialized by old clients.
                                                                                                                   2) Size of the inclusive type has been changed.

								NOTE: this field should be accessed only from the new library functions, otherwise it may result in crash or incorrect behavior of applications.
2 Size of this type has been changed from 128 bytes to 136 bytes. 	The fields or parameters of such data type may be incorrectly initialized or accessed by old client applications.

Apart from that, IPSEC also has breakage, but that is experimental, so not an issue.

> 
> >     and discussed dummy variable is missing, may be postponed to next release
> 
> Not sure I understand last sentence, could the author explain
> what dummy variables we are talking about.

In one of the techboard meeting around 19.11 timeframe, during the discussion for approving methodology for CPU-crypto, it was proposed that in order to avoid delay, a dummy variable can be introduced in cryptodev API/ABI to avoid any ABI breakage in upcoming releases. But this was not done.


> 
> Konstantin
> 


  reply	other threads:[~2020-01-16 13:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 11:13 Ferruh Yigit
2020-01-16 12:48 ` Ananyev, Konstantin
2020-01-16 13:17   ` Akhil Goyal [this message]
2020-01-16 13:39     ` Ananyev, Konstantin
2020-01-16 16:42       ` Akhil Goyal
2020-01-16 17:47         ` Ferruh Yigit
2020-01-16 13:19 ` Akhil Goyal
2020-01-16 17:50   ` Ferruh Yigit
2020-01-17 16:00 ` Honnappa Nagarahalli
2020-01-17 11:39 Ananyev, Konstantin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VE1PR04MB66397879FB5B89F276015D52E6360@VE1PR04MB6639.eurprd04.prod.outlook.com \
    --to=akhil.goyal@nxp.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).