From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [RFC v2 5/9] ipsec: add SA data-path API Date: Mon, 29 Oct 2018 10:19:24 +0000 Message-ID: <20181029101905.GB4738@jerin> References: <1535129598-27301-1-git-send-email-konstantin.ananyev@intel.com> <1539109420-13412-6-git-send-email-konstantin.ananyev@intel.com> <20181018173745.GA14157@jerin> <2601191342CEEE43887BDE71AB9772580102FEA53E@IRSMSX106.ger.corp.intel.com> <20181024120346.GA15208@jerin> <2601191342CEEE43887BDE71AB9772580103064BF1@irsmsx105.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "Awal, Mohammad Abdul" , "Joseph, Anoob" , "Athreya, Narayana Prasad" To: "Ananyev, Konstantin" Return-path: Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710071.outbound.protection.outlook.com [40.107.71.71]) by dpdk.org (Postfix) with ESMTP id C70DDDED for ; Mon, 29 Oct 2018 11:19:26 +0100 (CET) In-Reply-To: <2601191342CEEE43887BDE71AB9772580103064BF1@irsmsx105.ger.corp.intel.com> Content-Language: en-US Content-ID: <30FF27348B86694BB64B69E414D8B452@namprd07.prod.outlook.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" -----Original Message----- > Date: Sun, 28 Oct 2018 20:37:23 +0000 > From: "Ananyev, Konstantin" > To: Jerin Jacob > CC: "dev@dpdk.org" , "Awal, Mohammad Abdul" > , "Joseph, Anoob" > , "Athreya, Narayana Prasad" > > Subject: RE: [dpdk-dev] [RFC v2 5/9] ipsec: add SA data-path API >=20 >=20 > Hi Jerin, Hi Konstantin, >=20 > > > > > + > > > > > +/** > > > > > + * Checks that inside given rte_ipsec_session crypto/security fi= elds > > > > > + * are filled correctly and setups function pointers based on th= ese values. > > > > > + * @param ss > > > > > + * Pointer to the *rte_ipsec_session* object > > > > > + * @return > > > > > + * - Zero if operation completed successfully. > > > > > + * - -EINVAL if the parameters are invalid. > > > > > + */ > > > > > +int __rte_experimental > > > > > +rte_ipsec_session_prepare(struct rte_ipsec_session *ss); > > > > > + > > > > > +/** > > > > > + * For input mbufs and given IPsec session prepare crypto ops th= at can be > > > > > + * enqueued into the cryptodev associated with given session. > > > > > + * expects that for each input packet: > > > > > + * - l2_len, l3_len are setup correctly > > > > > + * Note that erroneous mbufs are not freed by the function, > > > > > + * but are placed beyond last valid mbuf in the *mb* array. > > > > > + * It is a user responsibility to handle them further. > > > > > + * @param ss > > > > > + * Pointer to the *rte_ipsec_session* object the packets belon= g to. > > > > > + * @param mb > > > > > + * The address of an array of *num* pointers to *rte_mbuf* str= uctures > > > > > + * which contain the input packets. > > > > > + * @param cop > > > > > + * The address of an array of *num* pointers to the output *rt= e_crypto_op* > > > > > + * structures. > > > > > + * @param num > > > > > + * The maximum number of packets to process. > > > > > + * @return > > > > > + * Number of successfully processed packets, with error code s= et in rte_errno. > > > > > + */ > > > > > +static inline uint16_t __rte_experimental > > > > > +rte_ipsec_crypto_prepare(const struct rte_ipsec_session *ss, > > > > > + struct rte_mbuf *mb[], struct rte_crypto_op *cop[], uint1= 6_t num) > > > > > +{ > > > > > + return ss->func.prepare(ss, mb, cop, num); > > > > > +} > > > > > + > > > > static inline uint16_t __rte_experimental > > > > rte_ipsec_event_process(const struct rte_ipsec_session *ss, struct = rte_event *ev[], uint16_t num) > > > > { > > > > return ss->func.event_process(ss, ev, num); > > > > } > > > > > > To fulfill that, we can either have 2 separate function pointers: > > > uint16_t (*pkt_process)( const struct rte_ipsec_session *ss, struct r= te_mbuf *mb[],uint16_t num); > > > uint16_t (*event_process)( const struct rte_ipsec_session *ss, struct= rte_event *ev[],uint16_t num); > > > > > > Or we can keep one function pointer, but change it to accept just arr= ay of pointers: > > > uint16_t (*process)( const struct rte_ipsec_session *ss, void *in[],u= int16_t num); > > > and then make session_prepare() to choose a proper function based on = input. > > > > > > I am ok with both schemes, but second one seems a bit nicer to me. > > > > How about best of both worlds, i.e save space and enable compile check > > by anonymous union of both functions > > > > RTE_STD_C11 > > union { > > uint16_t (*pkt_process)( const struct rte_ipsec_session *ss,struc= t rte_mbuf *mb[],uint16_t num); > > uint16_t (*event_process)( const struct rte_ipsec_session *ss, st= ruct rte_event *ev[],uint16_t num); > > }; > > >=20 > Yes, it is definitely possible, but then we still need 2 API functions, > Depending on input type, i.e: >=20 > static inline uint16_t __rte_experimental > rte_ipsec_event_process(const struct rte_ipsec_session *ss, struct rte_ev= ent *ev[], uint16_t num) > { > return ss->func.event_process(ss, ev, num); > } >=20 > static inline uint16_t __rte_experimental > rte_ipsec_pkt_process(const struct rte_ipsec_session *ss, struct rte_mbuf= *mb[], uint16_t num) > { > return ss->func.pkt_process(ss, mb, num); > } >=20 > While if we'll have void *[], we can have just one function for both case= s: >=20 > static inline uint16_t __rte_experimental > rte_ipsec_process(const struct rte_ipsec_session *ss, void *in[], uint16_= t num) > { > return ss->func.process(ss, in, num); > } Since it will be called from different application code path. I would prefer to have separate functions to allow strict compiler check. >=20 > Konstantin