Hi Jerin, > > > > > static inline rte_ipsec_add_tunnel_hdr(struct rte_mbuf *mbuf); > > > static inline rte_ipsec_update_sqn(struct rte_mbuf *mbuf, &seq_no); > > > ... > > > > > > For the regular use case, a fat > > > rte_ipsec_(inbound/outbound)_(prepare/process) can be provided. The > > > worker implemented for that case can directly call the function and > > > forget about the other modes. For other vendors with varying > > > capabilities, there can be multiple workers taking advantage of the hw > > > features. For such workers, the static inline functions can be used as > > > required. This gives vendors opportunity to pick and choose what they > > > want from the ipsec lib. The worker to be used for that case will be > > > determined based on the capabilities exposed by the PMDs. > > > > > > https://mails.dpdk.org/archives/dev/2018-June/103828.html > > > > > > The above email explains how multiple workers can be used with l2fwd. > > > > > > For this to work, the application & library code need to be modularised. > > > Like what is being done in the following series, > > > https://mails.dpdk.org/archives/dev/2018-June/103786.html > > > > > > This way one application can be made to run on multiple platforms, with > > > the app being optimized for the platform on which it would run. > > > > > > /* ST SA - RTE_SECURITY_ACTION_TYPE_NONE - CRYPTODEV - NO EVENTDEV*/ > > > worker1() > > > { > > > while(true) { > > > nb_pkts = rte_eth_rx_burst(); > > > > > > if (nb_pkts != 0) { > > > /* Do lookup */ > > > rte_ipsec_inbound_prepare(); > > > rte_cryptodev_enqueue_burst(); > > > /* Update in-flight */ > > > } > > > > > > if (in_flight) { > > > rte_cryptodev_dequeue_burst(); > > > rte_ipsec_outbound_process(); > > > } > > > /* route packet */ > > > } > > > > > > #include <rte_ipsec.h> /* For IPsec lib static inlines */ > > > > > > static inline rte_event_enqueue(struct rte_event *ev) > > > { > > > ... > > > } > > > > > > /* MT safe SA - RTE_SECURITY_ACTION_TYPE_NONE - CRYPTODEV - EVENTDEV) > > > worker2() > > > { > > > while(true) { > > > nb_pkts = rte_eth_rx_burst(); > > > > > > if (nb_pkts != 0) { > > > /* Do lookup */ > > > rte_ipsec_add tunnel(ev->mbuf); > > > rte_event_enqueue(ev) > > > rte_cryptodev_enqueue_burst(ev->mbuf); > > > /* Update in-flight */ > > > } > > > > > > if (in_flight) { > > > rte_cryptodev_dequeue_burst(); > > > rte_ipsec_outbound_process(); > > > } > > > /* route packet */ > > > } > > > > Hmm, not sure how these 2 cases really differs in terms of ipsec processing. > > I do understand the in second one we use events to propagate packets > > through the system, > > and that eventdev might be smart enough to preserve packet ordering, etc. > > But in terms of ipsec processing we have to do exactly the same for both > > cases. > > Let say for the example above (outbound, crytpodev): > > a) lookup an SA > > b) increment SA.SQN and check for overflow > > d) generate IV > > e) generate & fill ESP header/trailer, tunnel header > > f) perform actual encrypt, generate digest > > > > So crypto_prepare() - deals with b)-e). > > f) is handled by cryptodev. > > Yes, step b) might need to be atomic, or might not - > > depends on particular application design. > > But in both cases (polling/eventdev) we do need all these steps to be > > performed. > > The real question, Is the new library should be aware of eventdev or > application decides it?
My thought right now - it shouldn't. Looking at rte_event_crypto_adapter - right now it accepts crypto-ops as input for both new and forward modes. Which means that prepare() has to called by the app before doing enqueue (either straight to cryptodev or to eventdev). Anyway I just sumitted RFC v2 with process/prepare as function pointers inside ipsec_session, please have a look. Konstantin > > If it is former, in order to complete step (b), we need rte_event also passed > to > _process() API and process() API needs to be function pointer in order to > accommodate all combinations of different HW/SW capabilities. > >
