From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id B3CEC58C4 for ; Sun, 28 Oct 2018 21:37:27 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Oct 2018 13:37:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,437,1534834800"; d="scan'208";a="84860250" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga007.jf.intel.com with ESMTP; 28 Oct 2018 13:37:25 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.144]) by IRSMSX107.ger.corp.intel.com ([169.254.10.79]) with mapi id 14.03.0415.000; Sun, 28 Oct 2018 20:37:24 +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/1MO7G62AqbpUemv5mhomzRtqUlQeGAgAUEBGCABAymAIAG56cw Date: Sun, 28 Oct 2018 20:37:23 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580103064BF1@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> In-Reply-To: <20181024120346.GA15208@jerin> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYWY1ODY4NTktNDAyZC00OWE3LWI1NTctMjAzMGRlMTE1NjVlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNmZ1b2llR05ZeFduTlV0ODc4TXR6b3I2K1wvYktmSms4S3VzYjJaeVlYbVNmenEyamRNeEF0NEUzVjNPaTVNNysifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.182] 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: Sun, 28 Oct 2018 20:37:28 -0000 Hi Jerin, > > > > + > > > > +/** > > > > + * Checks that inside given rte_ipsec_session crypto/security fiel= ds > > > > + * are filled correctly and setups function pointers based on thes= e 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 belong = to. > > > > + * @param mb > > > > + * The address of an array of *num* pointers to *rte_mbuf* struc= tures > > > > + * 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[], uint16_= 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 rt= e_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, struct r= te_event *ev[],uint16_t num); > > > > Or we can keep one function pointer, but change it to accept just array= of pointers: > > uint16_t (*process)( const struct rte_ipsec_session *ss, void *in[],uin= t16_t num); > > and then make session_prepare() to choose a proper function based on in= put. > > > > I am ok with both schemes, but second one seems a bit nicer to me. >=20 > How about best of both worlds, i.e save space and enable compile check > by anonymous union of both functions >=20 > RTE_STD_C11 > union { > uint16_t (*pkt_process)( const struct rte_ipsec_session *ss,struct rte_m= buf *mb[],uint16_t num); > uint16_t (*event_process)( const struct rte_ipsec_session *ss, struct rt= e_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: static inline uint16_t __rte_experimental rte_ipsec_event_process(const struct rte_ipsec_session *ss, struct rte_even= t *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_mbuf *= 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 cases: 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); } Konstantin