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

Reply via email to