-----Original Message----- > Date: Tue, 2 Oct 2018 23:56:23 +0000 > From: "Ananyev, Konstantin" <konstantin.anan...@intel.com> > To: Jerin Jacob <jerin.ja...@caviumnetworks.com> > CC: "Joseph, Anoob" <anoob.jos...@caviumnetworks.com>, "dev@dpdk.org" > <dev@dpdk.org>, "Awal, Mohammad Abdul" <mohammad.abdul.a...@intel.com>, > "Doherty, Declan" <declan.dohe...@intel.com>, Narayana Prasad > <narayanaprasad.athr...@caviumnetworks.com>, "akhil.go...@nxp.com" > <akhil.go...@nxp.com>, "hemant.agra...@nxp.com" <hemant.agra...@nxp.com>, > "shreyansh.j...@nxp.com" <shreyansh.j...@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. > > > > >
