From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id B1BF358C5 for ; Thu, 29 Sep 2016 16:39:27 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP; 29 Sep 2016 07:39:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,415,1470726000"; d="scan'208";a="14638680" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.221.27]) ([10.237.221.27]) by orsmga005.jf.intel.com with ESMTP; 29 Sep 2016 07:39:04 -0700 To: "De Lara Guarch, Pablo" , "dev@dpdk.org" References: <1471971574-108998-1-git-send-email-sergio.gonzalez.monroy@intel.com> <1474616734-118291-1-git-send-email-sergio.gonzalez.monroy@intel.com> <1474616734-118291-2-git-send-email-sergio.gonzalez.monroy@intel.com> From: Sergio Gonzalez Monroy Message-ID: <622eeba3-527f-8126-1e80-014895f35dd5@intel.com> Date: Thu, 29 Sep 2016 15:39:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 1/7] examples/ipsec-secgw: change CBC IV generation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 14:39:28 -0000 On 28/09/2016 04:51, De Lara Guarch, Pablo wrote: > Hi Sergio, > >> -----Original Message----- >> From: Gonzalez Monroy, Sergio >> Sent: Friday, September 23, 2016 12:45 AM >> To: dev@dpdk.org; De Lara Guarch, Pablo >> Subject: [PATCH v2 1/7] examples/ipsec-secgw: change CBC IV generation >> >> NIST SP800-38A recommends two methods to generate unpredictable IVs >> (Initilisation Vector) for CBC mode: >> 1) Apply the forward function to a nonce (ie. counter) >> 2) Use a FIPS-approved random number generator >> >> This patch implements the first recommended method by using the forward >> function to generate the IV. >> >> Signed-off-by: Sergio Gonzalez Monroy > [...] > >> +static inline void * >> +get_cop(struct rte_mbuf *m) >> +{ >> + struct ipsec_mbuf_metadata *priv = get_priv(m); >> + >> + return &priv->cop; >> +} > This function is not used in anywhere. Should it be called somewhere to get the crypto op? Indeed! Will be removed in v3. >> + >> +static inline void * >> +get_sym_cop(struct rte_crypto_op *cop) >> +{ >> + return (cop + 1); > Why is this cop + 1? Am I missing something obvious? > Maybe it is worth a comment here (I noticed this was already in the previous code, but I don't understand it :)) It is just the way the app stores the metadata. If you look at 'struct ipsec_mbuf_metadata' you can see that sym_cop is just after cop. Sergio >> +} >> + >> int >> inbound_sa_check(struct sa_ctx *sa_ctx, struct rte_mbuf *m, uint32_t >> sa_idx); >> >> -- >> 2.5.5 > Thanks, > Pablo