RE: [RFC PATCH 1/2] security: add fallback security processing and Rx inject

[Akhil Goyal <gakhil@marvell.com>]

> +/**
> + * Perform security processing of packets and do Rx inject after processing.
> + *
> + * Rx inject would behave similarly to ethdev loopback but with the additional
> + * security processing. In case of ethdev loopback, application would be
> + * submitting packets to ethdev Tx queues and would be received as is from
> + * ethdev Rx queues. With Rx inject, packets would be received after security
> + * processing from ethdev Rx queues.
> + *
> + * With inline protocol offload capable ethdevs, Rx injection can be used to
> + * handle packets which failed the regular security Rx path. This can be due to
> + * cases such as outer fragmentation, in which case applications can
> reassemble
> + * the fragments and then subsequently submit for inbound processing and Rx
> + * injection, so that packets are received as regular security processed
> + * packets.
> + *
> + * With lookaside protocol offload capable cryptodevs, Rx injection can be
> used
> + * to perform packet parsing after security processing. This would allow for
> + * re-classification after security protocol processing is done. The ethdev port
> + * on which the packet would be received would be based on rte_flow rules
> + * matching the packet after security processing. Also, since the packet would
> + * be identical to an inline protocol processed packet, eth devices should have
> + * security enabled (`RTE_ETHDEV_RX_SECURITY_F`).
> + *
> + * Since the packet would be received back from ethdev Rx queues, it is
> expected
> + * that application retains/adds L2 header with the mbuf field 'l2_len'
> + * reflecting the size of L2 header in the packet.
> + *
> + * If `hash.fdir.h` field is set in mbuf, it would be treated as the value for
> + * `MARK` pattern for the subsequent rte_flow parsing.
> + *
> + * @param	ctx		Security ctx
> + * @param	pkts		The address of an array of *nb_pkts* pointers
> to
> + *				*rte_mbuf* structures which contain the
> packets.
> + * @param	sess		The address of an array of *nb_pkts* pointers
> to
> + *				*rte_security_session* structures
> corresponding
> + *				to each packet.
> + * @param	nb_pkts		The maximum number of packets to process.
> + *
> + * @return
> + *   The number of packets successfully injected to ethdev Rx. The return
> + *   value can be less than the value of the *nb_pkts* parameter when the
> + *   PMD internal queues have been filled up.
> + */
> +__rte_experimental
> +static inline uint16_t
> +rte_security_inb_pkt_rx_inject(struct rte_security_ctx *ctx,
> +			       struct rte_mbuf **pkts,
> +			       struct rte_security_session **sess,
> +			       uint16_t nb_pkts)

rte_security_session is internal to library and not exposed.
Also security_ctx is planned to be made internal.
Can we make this as non-inline function and add as part of rte_security_op?
I believe this is a fallback flow, which means not very performance intensive.

> +{
> +#ifdef RTE_DEBUG
> +	RTE_PTR_OR_ERR_RET(ctx, 0);
> +	RTE_PTR_OR_ERR_RET(ctx->ops, 0);
> +	RTE_FUNC_PTR_OR_ERR_RET(ctx->inb_pkt_rx_inject, 0);
> +#endif
> +	return ctx->inb_pkt_rx_inject(ctx->device, pkts, sess, nb_pkts);
> +}
> +
> +
>  struct rte_security_macsec_secy_stats {
>  	uint64_t ctl_pkt_bcast_cnt;
>  	uint64_t ctl_pkt_mcast_cnt;
> diff --git a/lib/security/version.map b/lib/security/version.map
> index b2097a969d..99d43dbeef 100644
> --- a/lib/security/version.map
> +++ b/lib/security/version.map
> @@ -15,6 +15,7 @@ EXPERIMENTAL {
> 
>  	__rte_security_set_pkt_metadata;
>  	rte_security_dynfield_offset;
> +	rte_security_inb_pkt_rx_inject;
>  	rte_security_macsec_sa_create;
>  	rte_security_macsec_sa_destroy;
>  	rte_security_macsec_sa_stats_get;
> --
> 2.25.1