From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 55CE14CA7 for ; Tue, 30 Oct 2018 14:53:34 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 06:53:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,444,1534834800"; d="scan'208";a="92388699" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by FMSMGA003.fm.intel.com with ESMTP; 30 Oct 2018 06:53:32 -0700 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX106.ger.corp.intel.com (163.33.3.31) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 30 Oct 2018 13:53:31 +0000 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.144]) by irsmsx112.ger.corp.intel.com ([169.254.1.93]) with mapi id 14.03.0415.000; Tue, 30 Oct 2018 13:53:31 +0000 From: "Ananyev, Konstantin" To: Jerin Jacob CC: "dev@dpdk.org" , "Awal, Mohammad Abdul" , "Joseph, Anoob" , "Athreya, Narayana Prasad" Thread-Topic: [dpdk-dev] [RFC v2 5/9] ipsec: add SA data-path API Thread-Index: AQHUX/1MO7G62AqbpUemv5mhomzRtqUlQeGAgAUEBGCABAymAIAG56cwgADnjQCAAczLcA== Date: Tue, 30 Oct 2018 13:53:30 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725801030661D4@irsmsx105.ger.corp.intel.com> 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> <20181029101905.GB4738@jerin> In-Reply-To: <20181029101905.GB4738@jerin> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzZjODU3NzgtYmMwZC00M2U3LWExMTgtZTkyZWVhNjg0NDlhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiWTMyakgwTHRwdmZiK25CNGM5cktUMktUVG82STloejA5cjVQRTZLR0hiQW9LWXE5bDNYMERPSDNuc3FBXC9UNkoifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC v2 5/9] ipsec: add SA data-path API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 13:53:34 -0000 Hi Jerin, =20 > > > > > > + > > > > > > +/** > > > > > > + * Checks that inside given rte_ipsec_session crypto/security = fields > > > > > > + * are filled correctly and setups function pointers based on = these 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 = that 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 bel= ong to. > > > > > > + * @param mb > > > > > > + * The address of an array of *num* pointers to *rte_mbuf* s= tructures > > > > > > + * which contain the input packets. > > > > > > + * @param cop > > > > > > + * The address of an array of *num* pointers to the output *= rte_crypto_op* > > > > > > + * structures. > > > > > > + * @param num > > > > > > + * The maximum number of packets to process. > > > > > > + * @return > > > > > > + * Number of successfully processed packets, with error code= set 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[], uin= t16_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, struc= t 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= rte_mbuf *mb[],uint16_t num); > > > > uint16_t (*event_process)( const struct rte_ipsec_session *ss, stru= ct rte_event *ev[],uint16_t num); > > > > > > > > Or we can keep one function pointer, but change it to accept just a= rray of pointers: > > > > uint16_t (*process)( const struct rte_ipsec_session *ss, void *in[]= ,uint16_t num); > > > > and then make session_prepare() to choose a proper function based o= n 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 chec= k > > > by anonymous union of both functions > > > > > > RTE_STD_C11 > > > union { > > > uint16_t (*pkt_process)( const struct rte_ipsec_session *ss,str= uct rte_mbuf *mb[],uint16_t num); > > > uint16_t (*event_process)( const struct rte_ipsec_session *ss, = struct rte_event *ev[],uint16_t num); > > > }; > > > > > > > Yes, it is definitely possible, but then we still need 2 API functions, > > Depending on input type, i.e: > > > > 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); > > } > > > > static inline uint16_t __rte_experimental > > rte_ipsec_pkt_process(const struct rte_ipsec_session *ss, struct rte_mb= uf *mb[], uint16_t num) > > { > > return ss->func.pkt_process(ss, mb, num); > > } > > > > While if we'll have void *[], we can have just one function for both ca= ses: > > > > static inline uint16_t __rte_experimental > > rte_ipsec_process(const struct rte_ipsec_session *ss, void *in[], uint1= 6_t num) > > { > > return ss->func.process(ss, in, num); > > } >=20 > Since it will be called from different application code path. I would > prefer to have separate functions to allow strict compiler check. >=20 Ok, let's keep them separate, NP with that. I'll rename ipsec_(prepare|process) to ipsec_pkt_(prepare_process), so you guys can add '_event_' functions later. Konstantin