From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 7F1BB1B201 for ; Thu, 19 Oct 2017 15:14:23 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP; 19 Oct 2017 06:14:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,401,1503385200"; d="scan'208";a="140024241" Received: from rnicolau-mobl.ger.corp.intel.com (HELO [10.237.221.73]) ([10.237.221.73]) by orsmga004.jf.intel.com with ESMTP; 19 Oct 2017 06:14:18 -0700 To: "Ananyev, Konstantin" , Akhil Goyal , "dev@dpdk.org" Cc: "Doherty, Declan" , "De Lara Guarch, Pablo" , "hemant.agrawal@nxp.com" , "borisp@mellanox.com" , "aviadye@mellanox.com" , "thomas@monjalon.net" , "sandeep.malik@nxp.com" , "jerin.jacob@caviumnetworks.com" , "Mcnamara, John" , "shahafs@mellanox.com" , "olivier.matz@6wind.com" References: <20171006181151.4758-1-akhil.goyal@nxp.com> <20171014221734.15511-1-akhil.goyal@nxp.com> <20171014221734.15511-11-akhil.goyal@nxp.com> <2601191342CEEE43887BDE71AB9772585FAAAD3E@IRSMSX103.ger.corp.intel.com> <524bc592-367d-26a0-fb24-9113c34254c4@intel.com> <2601191342CEEE43887BDE71AB9772585FAAB1D6@IRSMSX103.ger.corp.intel.com> <763A2F19A5EFF34F8B7F1657C992EE297B2F0453@IRSMSX104.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772585FAAB23F@IRSMSX103.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772585FAAB263@IRSMSX103.ger.corp.intel.com> From: Radu Nicolau Message-ID: Date: Thu, 19 Oct 2017 14:14:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB9772585FAAB263@IRSMSX103.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v4 10/12] net/ixgbe: enable inline ipsec 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: Thu, 19 Oct 2017 13:14:24 -0000 On 10/19/2017 1:29 PM, Ananyev, Konstantin wrote: > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin >> Sent: Thursday, October 19, 2017 1:17 PM >> To: Nicolau, Radu ; Akhil Goyal ; dev@dpdk.org >> Cc: Doherty, Declan ; De Lara Guarch, Pablo ; hemant.agrawal@nxp.com; >> borisp@mellanox.com; aviadye@mellanox.com; thomas@monjalon.net; sandeep.malik@nxp.com; jerin.jacob@caviumnetworks.com; >> Mcnamara, John ; shahafs@mellanox.com; olivier.matz@6wind.com >> Subject: Re: [dpdk-dev] [PATCH v4 10/12] net/ixgbe: enable inline ipsec >> >> >> >>> -----Original Message----- >>> From: Nicolau, Radu >>> Sent: Thursday, October 19, 2017 12:57 PM >>> To: Ananyev, Konstantin ; Akhil Goyal ; dev@dpdk.org >>> Cc: Doherty, Declan ; De Lara Guarch, Pablo ; hemant.agrawal@nxp.com; >>> borisp@mellanox.com; aviadye@mellanox.com; thomas@monjalon.net; sandeep.malik@nxp.com; jerin.jacob@caviumnetworks.com; >>> Mcnamara, John ; shahafs@mellanox.com; olivier.matz@6wind.com >>> Subject: RE: [PATCH v4 10/12] net/ixgbe: enable inline ipsec >>> >>> >>> >>>> -----Original Message----- >>>> From: Ananyev, Konstantin >>>> Sent: Thursday, October 19, 2017 12:04 PM >>>> To: Nicolau, Radu ; Akhil Goyal >>>> ; dev@dpdk.org >>>> Cc: Doherty, Declan ; De Lara Guarch, Pablo >>>> ; hemant.agrawal@nxp.com; >>>> borisp@mellanox.com; aviadye@mellanox.com; thomas@monjalon.net; >>>> sandeep.malik@nxp.com; jerin.jacob@caviumnetworks.com; Mcnamara, >>>> John ; shahafs@mellanox.com; >>>> olivier.matz@6wind.com >>>> Subject: RE: [PATCH v4 10/12] net/ixgbe: enable inline ipsec >>>> >>>> >>>> >>>>>>> >>>>>>> + >>>>>>> +static int >>>>>>> +ixgbe_crypto_update_mb(void *device __rte_unused, >>>>>>> + struct rte_security_session *session, >>>>>>> + struct rte_mbuf *m, void *params __rte_unused) { > > > Another sort of generic question - why not make security_set_pkt_metadata function > to accept bulk of packets? > In that case o can minimize the cost of function calls, accessing session data, etc. > Though I suppose that could wait till next patch series. > Konstantin It is a good suggestion, but we need to discuss it further; for example if it can accept a bulk of packets, will it need also a bulk of metadata pointers, or just one for all the packets? > >>>>>>> + struct ixgbe_crypto_session *ic_session = >>>>>>> + get_sec_session_private_data(session); >>>>>>> + if (ic_session->op == IXGBE_OP_AUTHENTICATED_ENCRYPTION) { >>>>>>> + struct ixgbe_crypto_tx_desc_md *mdata = >>>>>>> + (struct ixgbe_crypto_tx_desc_md *)&m->udata64; >>>>>>> + mdata->enc = 1; >>>>>>> + mdata->sa_idx = ic_session->sa_index; >>>>>>> + mdata->pad_len = *rte_pktmbuf_mtod_offset(m, >>>>>>> + uint8_t *, rte_pktmbuf_pkt_len(m) - 18) + 18; >>>>>> Could you explain what pad_len supposed to contain? >>>>>> Also what is a magical constant '18'? >>>>>> Could you create some macro if needed? >>>>> I added an explanation in the code, we read the payload padding size >>>>> that is stored at the len-18 bytes and add 18 bytes, 2 for ESP trailer >>>>> and 16 for ICV. >>>> Ok, can we at least have a macros for all these constants? >>>> Another question: you do use pkt_len() here - does it mean that multi- >>>> segment packets are not supported by ixgbe-ipsec? >>>> Konstantin >>> It does support multisegment, but the pad_len has to be set only for single send, it will be ignored otherwise. I have updated the code to >> set >>> it for single segment packets only. >> Sorry, I didn't understand that. >> If that function does support multiseg packets, then it has to go to the last segment via m->next, >> If it doesn't, then it should return an error I case of m->nb_seg != 1. >> Right? >> >>> Also, our test app does not support multisegment packets. >> Ok, I suppose that means, multi-seg case wasn't tested :) >> >> >>