Re: [dpdk-dev] [RFC] ipsec: new library for IPsec data-path processing

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

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.
> 
>