> +/**
> + * 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
