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