Re: [dpdk-dev] [EXT] [PATCH v2] cryptodev: support multiple cipher data-units

[Thomas Monjalon <thomas@monjalon.net>]

13/04/2021 14:02, Akhil Goyal:
> > All the new fields do not change the size of their structures.
> 
> Please check that the CI is failing. I see that ignore exception is present in 
> devtools/libabigail.abignore For rte_cryptodev. But not sure why this is still
> failing. Can you check?

There are 2 new fields:
	- rte_cryptodev_symmetric_capability.cipher.dataunit_set
	- rte_crypto_cipher_xform.dataunit_len

This is how the struct sizes are affected (before / after):

       struct       \      arch    |  32-bit |  64-bit |
-----------------------------------|---------|---------|
rte_cryptodev_symmetric_capability | 36 / 36 | 36 / 36 |
rte_crypto_cipher_xform            | 20 / 24 | 32 / 32 |

There is no change in rte_cryptodev_symmetric_capability because
the field is added in a light branch of the union.

The 64-bit size of rte_crypto_cipher_xform is unchanged (32)
because there were 4 padding bytes at the end (28 + 4).
But the 32-bit version has not such padding at the end,
so there is a breakage.

The only hole in 32-bit rte_crypto_cipher_xform is
2 bytes between key and iv.
Can we define dataunit_len as uint16_t?

The other side to check when playing with the ABI
is the default value of the holes for the new field.
The driver must work properly in case the application
did not explicitly set the new fields.
In general it means the compatible API should have memset(0).
In this case, it seems the new fields will be used only
in a new mlx5 driver, so it should be OK for now.
But usage of the new fields in an existing driver must
be checked carefully during the compatibility period.