From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 343061B211 for ; Thu, 19 Oct 2017 15:09:17 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2017 06:09:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,401,1503385200"; d="scan'208";a="140023042" 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:09:13 -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> From: Radu Nicolau Message-ID: <420b017f-8978-f25a-7d81-8437839c20af@intel.com> Date: Thu, 19 Oct 2017 14:09:12 +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: <2601191342CEEE43887BDE71AB9772585FAAB23F@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:09:18 -0000 On 10/19/2017 1:16 PM, Ananyev, Konstantin wrote: > >> -----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) { >>>>>> + 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? No need to return an error, just don't try to read the padding and don't set the pad_len in the metadata. My understanding of the datasheet is that multisegment egress IPsec is supported only for TCP/UDP packets, and the pad_len is ignored even if it's set. So I changed it to only process the padding for m->nb_seg == 1. > >> Also, our test app does not support multisegment packets. > Ok, I suppose that means, multi-seg case wasn't tested :) > > > >