Re: [dpdk-dev] [PATCH] doc: announce security API changes for Inline IPsec

[Nithin Dabilpuram <nithind1988@gmail.com>]

On Sat, Jul 31, 2021 at 12:16:12AM +0200, Thomas Monjalon wrote:
> 27/07/2021 19:36, Nithin Dabilpuram:
> > Announce changes to make rte_security_set_pkt_metadata() and
> > rte_security_get_userdata() inline instead of C functions and
> > also addition of another field in structure rte_security_ctx for
> > holding flags.
> 
> I guess there is a performance reason but the motivation
> is not explained. Also it is going in the opposite direction
> of what is discussed in the Technical Board meetings:
> we should avoid and reduce the number of inline functions
> to reduce the ABI surface.

Yes, it is a performance improvement. It is discussed in detail in
https://inbox.dpdk.org/dev/20210624102848.3878788-1-gakhil@marvell.com/T/#mc4ba3500c024f9911b7af7e5a6e95e23f6197fdd

To summarize, initially the two per-pkt fast path API's rte_security_set_pkt_metadata()
and rte_security_get_userdata() where added with anticipation that PMD's would
have lot of processing to be done on per-pkt basis for security offload packets
unlike other ethdev Rx/Tx offloads. 

Now that we have few PMD's that implemented inline ipsec support, it looks more
benefitial to have PMD specific logic in tx_burst()/rx_burst() for
performance instead of doing a per-pkt function ptr jump to do the same in
rte_security_set_pkt_metadata() or rte_security_get_userdata(). 
In our PMD rte_security_set_pkt_metadata() is currently just to copy private SA ptr 
from rte_security_session to security mbuf dynamic field and rte_security_get_userdata()
is to copy userdata ptr from mbuf dynamic field.

Hence the above proposal provides an alternative to PMD's which want to avoid 
function ptr jump, by doing a simple metadata get/set to mbuf security dynamic
field apart from existing function ptr jump. 

Also, in future when there will be no PMD's that need the function ptr support
for the same operations, this new method can be made the only method and rest
of the function pointer jump logic can be removed probably without breaking ABI.

> 
>