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

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

-----Original Message-----
> Date: Tue, 2 Oct 2018 23:56:23 +0000
> From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> CC: "Joseph, Anoob" <Anoob.Joseph@caviumnetworks.com>, "dev@dpdk.org"
>  <dev@dpdk.org>, "Awal, Mohammad Abdul" <mohammad.abdul.awal@intel.com>,
>  "Doherty, Declan" <declan.doherty@intel.com>, Narayana Prasad
>  <narayanaprasad.athreya@caviumnetworks.com>, "akhil.goyal@nxp.com"
>  <akhil.goyal@nxp.com>, "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
>  "shreyansh.jain@nxp.com" <shreyansh.jain@nxp.com>
> Subject: RE: [dpdk-dev] [RFC] ipsec: new library for IPsec data-path
>  processing
> 
> External Email
> 
> Hi Jerin,

Hi Konstantin,

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

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.



> Konstantin
> 
> >
> > In short,
> >
> > 1) Have separate small inline functions in library
> > 2) If something can be grouped, it can be exposed a specific function
> > to address a specific usecases
> > 3) Let remaining code, can go in application as different worker() to
> > address all the usecases.
> >
> > >