From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0066.outbound.protection.outlook.com [104.47.42.66]) by dpdk.org (Postfix) with ESMTP id 1ED107CA2 for ; Thu, 4 May 2017 13:23:30 +0200 (CEST) Received: from DM2PR03CA0044.namprd03.prod.outlook.com (10.141.96.43) by BLUPR03MB167.namprd03.prod.outlook.com (10.255.212.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Thu, 4 May 2017 11:23:26 +0000 Received: from BL2FFO11FD039.protection.gbl (2a01:111:f400:7c09::105) by DM2PR03CA0044.outlook.office365.com (2a01:111:e400:2428::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11 via Frontend Transport; Thu, 4 May 2017 11:23:26 +0000 Authentication-Results: spf=fail (sender IP is 192.88.158.2) smtp.mailfrom=nxp.com; intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=fail action=none header.from=nxp.com; Received-SPF: Fail (protection.outlook.com: domain of nxp.com does not designate 192.88.158.2 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.158.2; helo=az84smr01.freescale.net; Received: from az84smr01.freescale.net (192.88.158.2) by BL2FFO11FD039.mail.protection.outlook.com (10.173.161.135) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1047.9 via Frontend Transport; Thu, 4 May 2017 11:23:23 +0000 Received: from [127.0.0.1] (B35197-11.ap.freescale.net [10.232.134.49]) by az84smr01.freescale.net (8.14.3/8.14.0) with ESMTP id v44BNECr005560; Thu, 4 May 2017 04:23:19 -0700 To: Sergio Gonzalez Monroy , Pablo de Lara , References: <1493402588-163123-1-git-send-email-pablo.de.lara.guarch@intel.com> <46d732a5-3ab0-a63b-bd12-acc9372a3c57@nxp.com> <058e6ed7-9404-1333-31be-c389fe08d246@intel.com> <152e5bc5-26b3-2505-f5b7-842652110641@nxp.com> CC: , , , From: Akhil Goyal Message-ID: Date: Thu, 4 May 2017 16:53:14 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131383706066018560; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.158.2; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(39860400002)(39840400002)(39450400003)(39380400002)(39400400002)(39410400002)(39850400002)(2980300002)(1110001)(1109001)(3190300001)(339900001)(377454003)(199003)(24454002)(43544003)(52314003)(189002)(9170700003)(230700001)(50986999)(47776003)(31696002)(561944003)(33646002)(7246003)(38730400002)(65956001)(6666003)(50466002)(86362001)(54356999)(76176999)(5660300001)(93886004)(77096006)(65826007)(7126002)(229853002)(106466001)(105606002)(65806001)(31686004)(2950100002)(8676002)(189998001)(2906002)(23746002)(4001350100001)(36756003)(8656002)(8936002)(498600001)(356003)(53936002)(81166006)(69596002)(83506001)(4326008)(120886001)(54906002)(6246003)(85426001)(305945005)(64126003)(53546009)(104016004); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB167; H:az84smr01.freescale.net; FPR:; SPF:Fail; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD039; 1:h8928g6bZuw2YDLEhYW8zVxYzG0jGUrGj+nskyUBMeT97V+suLVybd9eHVnihAR0x4HIdrW1UfrpgGQ2+5j30anbLT7XitD6aPSee9S30IuFJCE5zwr8Jy/lQAtBm4k4DL+LWoSJjyihhyL24gc7mO2Jd1aEmJ/byOJSZqEag8pFYfStXUqW2ex0rpHwyyOCALTLVfc0nj6UnZ2c9hheH/ctewMzzoB1Xv/IomevlVQ7leVkt02QCeyki4+fyOi3ACr7K2tgRxbd5nehHhusXOc8Ps1MTTJg4dmViwNJHvP9GyCpwAB+nh+7PjTcx+4C8wNXC6q0iMcn91XzbfxMnMCfP5SV35d+VVbyec7t4W+q8UrBeApRWa5rCuoGTJ0Z4jkxySXD9CGydGTtO37bX38L41tmmQ/89jBiZMYZWs+EnTTmKgKeWMYXg0zjI6HwYYTankwL7cJ4rAaKkGofqnSBUhfR1cfMb22Rj1Qu8xq7KU0maQlS1qtt8BZ+8Vn96qCksqWs0m9b0uIdPS2qGJd1mjOabFI+3OtO/VHRKWRsP7MpJBgJ/Z2TXresBIx9ulB5Pe2bcLXN7wXPzsRZJpGkPkW/mW2Z7T/q0mo8js+bVlorPSR+dYCoXaKP1O3PhfqdnN6+bsHeBOAh6hNp0Q== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d0c376a8-1ea0-46fb-7fa0-08d492dffbcb X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131430075)(201703131517081); SRVR:BLUPR03MB167; X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB167; 3:ipgrGt+9wW1u6i3XECbHXfRTzNo7tGynuIONXGMDKHmMaQos73qolDG2LOU1hNwy4lHbY5CH9FXOpB6/9UjNHyfSuhMThxKGnTulMWfpjqTBSYTQt8DseY7ZfbdFfWyPowSq+HuYbAzxioaVWCBLUtQMTZ9OhqWz5Ib5w9FDQ7tvcK3bG1oCNi0fHGfedY82l5V3RECDzd1MGbaIDwj2kXciDuh47SzxAgTn4YY4DDEFqVaxUCC0Ri9cRAMmDmiBh1UE9JRD/dUZyCNLRQoqBVnzTGdzJC4V62I2BI3D/hQRVwA/dxRwPTUfvifnCdjKcywt9Boc9Ue4WeaSYJOWuD67AxF7CKahIGaNm/4tY5v7uv1E//kBV9JjiqnS7aBLRhlxHGOvbjOdzP0skHF/CYir2Cy4Y6Aw5eY8XNnCTEuH4EI7ndJUg3axCU/EVU7S; 25:kxYrG0gTMI/ku0QW2ZGXcwFkBRYpFILJlfwRQXgmCG8fnjsoqNrMMjtQP93D+M0b5mv5jOIWQKIej/QxBs4ozguRL5UxTmkDcTydEyWuxz6GtRxDXfxZmwNNFFwKqc0yK99QNS02AlT353JdfvaqDUJ95Ro5EjdsbWiInt6pEZulIJy3rYO8KJPcQqttyocUzelMDmkMOu3rmwqOcUaqXTrY8lWtN+M5sWTI3zKl9Z0AmiDAqPb4nfapWmH+HtVPhlZ4ZkcklRWF2Oo5L808FvSHq14aNRycuC+RiGJ6Gg/PidnlzWNEqmPWhs0zg+zwhT7e8yXefK6qsw/R7hGWWcTh0CxDsTA+gLN95cg10JHA1ehJC5nT+lE8mt1vLXxim4FBFgia3JO9ts70ypE5IDujxLTVYZ+6PK+4LCnVPPy77qyMQFFvxdgoPJmRhYu6DyhqZJ1czPpr71kiMfxz2w== X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB167; 31:ZjrSFfNe+I7OS3yskqhH7vT/l0Wii3vVHeH0JFWMQE/xe/2oBsQDMrZGQBcjegsobEO3IFAaG//4E2a4SeZ5A2WLILMuR/Ynu/w72YpttUF9zURV0YdI3JL3zGSRHsQGzslIWVnMLwKT4go6louxbwcXpk6Yt8VKsSGqTk50qG4d2n2MMhLzQbOXT3f556+10q+CRYpPSkbNwUQzFUPuFoH8CTnBcE1I2s+X+OqrktpszzGaiIXH8aiHf0DfMInaxUWJ8ke51kiM3wjWBPGxRg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095135)(601004)(2401047)(8121501046)(13015025)(5005006)(13024025)(13018025)(13023025)(13017025)(10201501046)(3002001)(93006095)(93001095)(6055026)(6096035)(20161123561025)(20161123563025)(20161123556025)(20161123559100)(201703131430075)(201703131433075)(201703131448075)(201703161259150)(201703151042153)(20161123565025); SRVR:BLUPR03MB167; BCL:0; PCL:0; RULEID:(400006); SRVR:BLUPR03MB167; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BLUPR03MB167; 4:990hWsZUTkCSuwxhNfFJzKCQlfFOaSiVWmKVv+7?= =?Windows-1252?Q?KRXVGxNt3KrjAOnllvuGg/rrg+V1hUyiFwWLFVgtQ1ROZKYvo6junZmf?= =?Windows-1252?Q?iguK10p5tKqIduuG03MDt1MdWI3KrSHkcuchjzv2NweiXgJIYkUoQjGC?= =?Windows-1252?Q?0Lb6SmsErfeP7mRMYK+rnB0kGxNQ3sTgVrNOgaKAkdfq7B81hlE/lRPW?= =?Windows-1252?Q?iR+M8Qens9N38xWLuER2upOQ0tMPlYjgq7i2Qxi0fhzyB5etKMVp4Lfh?= =?Windows-1252?Q?2l6yvuEeWywiYi05SNjP62ejcb3TeH3gIPGm/fR9OkjSeJrGe46nYhmH?= =?Windows-1252?Q?kA2RtHcAcJRV99YShn6uLqW6GyHkxpUhke1zNZh9FHY9aGdm6floXjto?= =?Windows-1252?Q?0PgUUYnIqp5cotmTxnR4KHHkNofuyRmj2mj/vmu/HYs0AURy4rqy2vrb?= =?Windows-1252?Q?IgnfuRUjNlnA0ADtb+7o0WRqNiS2wjzmkkIE8j6GD2yxFCsTkZTQXcFs?= =?Windows-1252?Q?i3EDTMyF3GgYIHMKwZoLgWq9RRV9Pr8oVxddiQ5+LGR9ATES00M/s0rt?= =?Windows-1252?Q?q8ln7nWprTZwzBjbAqoximKaJQyQZ3c+9h8Ar12xYUnF2loU/WkPq70K?= =?Windows-1252?Q?xw1JNFPnaF1ccJeerBE+A/U0gWLvkXP1Dc/FMCIt2DsaHJ5oagTvJ/+B?= =?Windows-1252?Q?hz9Fht37CJxvNtwC9wOUEJn/vgAP5u9BusfbRr83K7a7bg1sfGjrz82G?= =?Windows-1252?Q?2tdjEi8HsBCey4dsZaEqx/AzuAh9EDtWHarW0KDcY55mkVUwEtAMroA9?= =?Windows-1252?Q?M15smAsmr89ZAIHYstTNUhe0tN9eMmoHxjHJAXErKgFVurzdpJw13Q0W?= =?Windows-1252?Q?3fv6b8Go3p+crFh61hhm2rVfBOGk05yHz3DfHPw+qao/rbnP08gJ88BI?= =?Windows-1252?Q?g/0RraK3KtPTW37GVAbXa/jMAK/QxBTjiffD3QJc9Lk9AH2wWHCPTUq9?= =?Windows-1252?Q?9Q8nfWuL8SYzZDDisszmzpg+xw2eWq0rLrB3MuT8AqF8aZA=3D=3D?= X-Forefront-PRVS: 02973C87BC X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BLUPR03MB167; 23:raK2AUj6JU8auDaOF6+NZI3gRDyOd1uLuVec4c?= =?Windows-1252?Q?SXybo6Jpyz6DJmuVr4NOsx+PYotlsUoycOdXRk4gkzymz/KacOKdGON0?= =?Windows-1252?Q?iPjRLWldqNR0EB8GX0W8FuQ+U5LaWPMr+oL814dvr76fzgM4KH2WM60t?= =?Windows-1252?Q?bcrrMbNwGPLxAJCwA/1MlV4Xkey6X042WCSaau8ohQAwwHZBWax+URFh?= =?Windows-1252?Q?NKAMFatUvquInil6NZsjDBVL2bhhdCIehIKW9V7Bc8F8N23WwUwijQdW?= =?Windows-1252?Q?raKqLo6+ZKMChvu+CvAK3OFcuhTxdiz4hBRE/a5IJTtApNpEhp+LHELs?= =?Windows-1252?Q?9zMq/QbRSiI+Ad7oerT0YhYbiPNdFEsaxneQc4cGH+qb8o7dwy9/W+gO?= =?Windows-1252?Q?jLvkiWSG/GI50VIYQMbqiEYmhbtYnChTKUQN3JbM+ZbkgY3HAZqmnFwD?= =?Windows-1252?Q?ZXdG06GF7fozBz9MXalvSB9uUAgZXROEg0OT/yaihruyit5o0XmJNj2s?= =?Windows-1252?Q?knAdytWZfKE3HwlEJtEGSUnJ134TzA/vqYsvN9AKLMeBuK0WHMoutP1n?= =?Windows-1252?Q?+Vt8YW39BGNdmT/9ONdcfCqQYwMFBYEFzY8zUb3lttUpbsLd98WWuV/9?= =?Windows-1252?Q?HAL7wXGLv6OQ+JVBHejtqoSy/+2jSZgw3qnINU/y9wGXXcd3KGtrdYZV?= =?Windows-1252?Q?vZxxdK9UFURq0nnfaBN7P2fk89VbNVrlFJxIeXnBM6POvt4ape/Ez8Vi?= =?Windows-1252?Q?6R/KZ11rF2wFTE55dqMtbhZPKEVUFgpWVYnPbLGcju/IEKZ8VuiHd5Ce?= =?Windows-1252?Q?p8GZe9DejYxXwL+IpVtT8VqBxmopj/M1Dt9Gu+jgch7/mjQn33LJc5FK?= =?Windows-1252?Q?OW6Av7tiRL53iu1fpy8quVV3jyYaZWHnZsVSAbAxvtd+HsNqBCkCQKPk?= =?Windows-1252?Q?wszejMsRuyo2ErBeivihcYs5H8GvRZ1x/sWouUH/j4KnTEBueTRfJOGe?= =?Windows-1252?Q?dLfDIlkuBsTQZAzZEvGzOJtcOpEL9iSYeyOl8/gvkyRmypdRV37JMxco?= =?Windows-1252?Q?+YSQdxHyv11jJf4rRg5UB/ojspdGm457zcCC4crQdIX2T5z4P8tiNunB?= =?Windows-1252?Q?JKRvsUMDiqLY1p3jADpKQzvM3OhpGcLCu/TnltSCGu74SeeQX0lzlCj5?= =?Windows-1252?Q?dFk4pt4hX640PmLJITPnRmlPDs9zqtEeXDyeSTXNhKBK1okragMoaqgv?= =?Windows-1252?Q?b/oJvFBKa5bTR+L54lnHSmr42KZFTW8WJyFXRYpHh9NqTJQ+jTg0XRFc?= =?Windows-1252?Q?R8YjTUP3tq2pcL1gdz4vJ7FUNUwYHM+98yVS3zfBuGQZypeb2/EHIFCV?= =?Windows-1252?Q?Ptv2WW05s2Rx7cuw3956c23CYbWkT0puU1rZ4/c9ytlw2clP56bp05OQ?= =?Windows-1252?Q?HLopleaEhzi/oljlRe0lKcSOSvVauN8JSBfiGnSeUC2+h7v30H+aLSW/?= =?Windows-1252?Q?oSMuP3Cb/WMQvSCJ3tvzsIdOYItfsHB+vl7Gt5RM7/ZzOOLt2nrkALna?= =?Windows-1252?Q?f3xlKLR2wUo+o2W3wSlV+3XIaO4bNM6y4a4U4IFIa25WhUVbcVZI/bjp?= =?Windows-1252?Q?r9YeltnnGUeuCESM9y9buiyEfQOS3Svs1BqDb0g7KV9j7BFvfnxtiojD?= =?Windows-1252?Q?za8tHcdquVrHBPhNUONl6fZtZEh6Awmx4sdy0066eJkbueAvVCgGvnGa?= =?Windows-1252?Q?X3u0kQpOtcpb/EOCJzU9UuQn6Z6rsyKT5RarsOYo6V2KMpmx5xqOy6vD?= =?Windows-1252?Q?i5?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB167; 6:GA70DK5oAZx0Ljd8+EeJDKpo6JV7MMKEBh/zZhg9zhnst1jBBmgKCoatsTC/Wpj1Xb80mExAGbRddg7VnqMlajD+pcT2Wux647Q2MbE7PmcG4T+P2FlFvBuObagFa5mYpY77Gvv0XFIPePt5y6KpFZ2sn0ZbDO8560GfRBbISUZU+Kp9cAiB25TJWWLZOMQfRmhT/YXuuMHE8x+hCK0iE5rBylzQPCTC4DwINiZKeCP0bdCXqwLlo10IAt6ZoXxAMFqW7/mPU6+vWJx6MRJ7VIMDS8qUdmglZ05kg+ZhOqGCqKG1xcXH2Cieb9SBRkvj6PVJKpMU2F0JoOR5ev0ebA69MLJqIiumLMj3xOeIz+8EpQGTcCZ4gJ3jC6gwcjOuKkLPOhDJ/9yLbkNwmTkPVswgqQNE1PfYz7MbY5P6MDMX1hQKt4sZThnHYCdYOJlam4yOd088gIDPp/EDa1nSc5iJZgVMu2lTR0kkcP3rEn2Tsicus0tPeJLVzNwNH85Cskytcyrl8bzcLhZlReH5fA==; 5:KavIadiuqfesJO23O2YFH841j/GD82eHOalMo/On4Ohpe4zaDfNXhPxzLL6DwFBoiFVO48HzS1Wd7rKZ4gnhCurcA3y+QGNZI+R+JiE6n//EEp2X3QSmnhuZ6wFuLzJ5O3gdJ7EKdNrkEtlInBRjpDjJ57H7hUg2WfBtc/EPtx39B0Ouykh+fU/6R9qhQFEl; 24:7l2Gxz8v4Qtk/l6Qg5Nrtg+O8p7Lmfh15CVjS6/DyHInzlmyD32e1b5DLxReCXIB2ifrrPVPzTxuNUAb+bmOl6YICfX8ZcSBxTZi7NNYirs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB167; 7:eXPfXZbRShLQkaUZYpVR8V4QHoisQHgqiioTki1rF9C1ZvroV/SZJPZvIwf+V7FZGPQ9EY1pwqWicDdisHeDIkAMppxP/hCklgcgYEbHWBRHraxnWHoLA9iWuGEeM4FNrOjucYMxk1CsdR7Tg9zyDnt/8u79HjNHk629tjeotUA35YBBv/lV6LqD9DJUuEGa2pa7+DNGogWDaynYY8BR1miY57DnSjUnJJ/x0VqRSkkBIPRXKVE+i7JmiAck5T14BhbM2TjM9GbPDAlSS9ytJD8Mv3sPMT6/rvR2sb9aNV7s/SrpME7gUWdsBs9v/Ycd21zL4SNT42t51QgDAcsh5Q== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2017 11:23:23.7782 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.158.2]; Helo=[az84smr01.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB167 Subject: Re: [dpdk-dev] [PATCH] [RFC] cryptodev: crypto operation restructuring 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, 04 May 2017 11:23:31 -0000 On 5/4/2017 1:49 PM, Sergio Gonzalez Monroy wrote: > On 04/05/2017 08:38, Akhil Goyal wrote: >> On 5/4/2017 1:01 PM, Sergio Gonzalez Monroy wrote: >>> On 04/05/2017 07:09, Akhil Goyal wrote: >>>> Hi Sergio, >>>> >>>> On 5/3/2017 7:48 PM, Sergio Gonzalez Monroy wrote: >>>>> On 03/05/2017 12:01, Akhil Goyal wrote: >>>>>> Hi Pablo, >>>>>> >>>>>> On 4/28/2017 11:33 PM, Pablo de Lara wrote: >>>>>>> This is a proposal to correct and improve the current crypto >>>>>>> operation (rte_crypto_op) >>>>>>> and symmetric crypto operation (rte_crypto_sym_op) structures, >>>>>>> shrinking >>>>>>> their sizes to fit both structures into two 64-byte cache lines as >>>>>>> one of the goals. >>>>>>> >>>>>>> The following changes are proposed: >>>>>>> >>>>>>> In rte_crypto_op: >>>>>>> >>>>>>> - Move session type (with session/sessionless) from symmetric op to >>>>>>> crypto op, >>>>>>> as this could be used for other types >>>>>>> >>>>>>> - Combine operation type, operation status and session type into a >>>>>>> 64-bit flag (each one taking 1 byte), >>>>>>> instead of having enums taking 4 bytes each >>>>>> [Akhil] wouldn't this be a problem? Bit fields create endianness >>>>>> issues. Can we have uint8_t for each of the field. >>>>> >>>>> Sure, as it is proposed it would be the same as having 3 uint8_t >>>>> fields. >>>>> The idea was to possibly compact those fields (ie. we do not need 8 >>>>> bits >>>>> for sess_type) to make better use of the bits and add asym fields >>>>> there >>>>> if needed. >>>>> >>>>> I don't think bitfields would be a problem in this case. Agree, we >>>>> should not use both bitmask and bitfields, but we would use just >>>>> bitfields. >>>>> Can you elaborate on the issue you see? >>>>> >>>>> Regards, >>>>> Sergio >>>>> >>>> >>>> The problem will come when we run on systems with different >>>> endianness. The bit field positioning will be different for LE and BE. >>>> It would be like in LE >>>> uint64_t type:8; >>>> uint64_t status:8; >>>> uint64_t sess_type:8; >>>> uint64_t reserved:40; >>>> >>>> and on BE it would be >>>> uint64_t reserved:40; >>>> uint64_t sess_type:8; >>>> uint64_t status:8; >>>> uint64_t type:8; >>>> >>>> So it would be better to use uint8_t for each of the field. >>> >>> Understood, but why is that an issue? Those fields are used by >>> application code and PMD, same system. >>> Do you have a use case where you are offloading crypto ops to a >>> different arch/system? >>> >>> Sergio >> same application may run on LE or BE machines. So if we use masks for >> accessing these fields and take the complete field as uint64_t, then >> LE and BE machine would interpret it differently as the code is same. >> > > Right, either you use bitfields or you define macros and work on the > complete uint64_t. The proposal here was to just use bitfields and for > the given use case it would not be an issue while IMHO allowing better > packing and readability than defining each field as a Byte. > > Anyway, if you feel strongly against bitfields, we can just define it as > uint8_t as you suggest or single uint64_t with macros. > > Sergio > I am not against bitfields. But we should take care of the endianness using the compile time flags for byte ordering or we can use the uint8_t. I am ok with both. Thanks, Akhil >> Akhil >>> >>>> >>>>>>> >>>>>>> - Remove opaque data from crypto operation, as private data can be >>>>>>> allocated >>>>>>> just after the symmetric (or other type) crypto operation >>>>>>> >>>>>>> - Modify symmetric operation pointer to zero-array, as the symmetric >>>>>>> op should be always after the crypto operation >>>>>>> >>>>>>> In rte_crypto_sym_xform: >>>>>>> >>>>>>> - Remove AAD length from sym_xform (will be taken from operation >>>>>>> only) >>>>>>> >>>>>>> - Add IV length in sym_xform, so this length will be fixed for all >>>>>>> the operations in a session >>>>>> A much needed change. This would remove hard codings for iv length >>>>>> while configuring sessions. >>>>>>> >>>>>>> In rte_crypto_sym_op: >>>>>>> >>>>>>> - Separate IV from cipher structure in symmetric crypto >>>>>>> operation, as >>>>>>> it is also used in authentication, for some algorithms >>>>>>> >>>>>>> - Remove IV pointer and length from sym crypto op, and leave just >>>>>>> the >>>>>>> offset (from the beginning of the crypto operation), >>>>>>> as the IV can reside after the crypto operation >>>>>>> >>>>>>> - Create union with authentication data and AAD, as these two values >>>>>>> cannot be used at the same time >>>>>> [Akhil] Does this mean, in case of AEAD, additional authentication >>>>>> data and auth data are contiguous as we do not have explicit auth >>>>>> data >>>>>> offset here. Pablo/Sergio, Is my understanding correct here? Akhil >>>>>>> >>>>>>> - Remove digest length from sym crypto op, so this length will be >>>>>>> fixed for all the operations in a session >>>>>>> >>>>>>> - Add zero-array at the end of sym crypto op to be used to get extra >>>>>>> allocated memory (IV + other user data) >>>>>>> >>>>>>> Previous rte_crypto_op (40 bytes) and rte_crypto_sym_op (114 bytes) >>>>>>> structures: >>>>>>> >>>>>>> struct rte_crypto_op { >>>>>>> enum rte_crypto_op_type type; >>>>>>> >>>>>>> enum rte_crypto_op_status status; >>>>>>> >>>>>>> struct rte_mempool *mempool; >>>>>>> >>>>>>> phys_addr_t phys_addr; >>>>>>> >>>>>>> void *opaque_data; >>>>>>> >>>>>>> union { >>>>>>> struct rte_crypto_sym_op *sym; >>>>>>> }; >>>>>>> } __rte_cache_aligned; >>>>>>> >>>>>>> struct rte_crypto_sym_op { >>>>>>> struct rte_mbuf *m_src; >>>>>>> struct rte_mbuf *m_dst; >>>>>>> >>>>>>> enum rte_crypto_sym_op_sess_type sess_type; >>>>>>> >>>>>>> RTE_STD_C11 >>>>>>> union { >>>>>>> struct rte_cryptodev_sym_session *session; >>>>>>> struct rte_crypto_sym_xform *xform; >>>>>>> }; >>>>>>> >>>>>>> struct { >>>>>>> struct { >>>>>>> uint32_t offset; >>>>>>> uint32_t length; >>>>>>> } data; >>>>>>> >>>>>>> struct { >>>>>>> uint8_t *data; >>>>>>> phys_addr_t phys_addr; >>>>>>> uint16_t length; >>>>>>> } iv; >>>>>>> } cipher; >>>>>>> >>>>>>> struct { >>>>>>> struct { >>>>>>> uint32_t offset; >>>>>>> uint32_t length; >>>>>>> } data; >>>>>>> struct { >>>>>>> uint8_t *data; >>>>>>> phys_addr_t phys_addr; >>>>>>> uint16_t length; >>>>>>> } digest; /**< Digest parameters */ >>>>>>> >>>>>>> struct { >>>>>>> uint8_t *data; >>>>>>> phys_addr_t phys_addr; >>>>>>> uint16_t length; >>>>>>> } aad; >>>>>>> >>>>>>> } auth; >>>>>>> } __rte_cache_aligned; >>>>>>> >>>>>>> New rte_crypto_op (24 bytes) and rte_crypto_sym_op (72 bytes) >>>>>>> structures: >>>>>>> >>>>>>> struct rte_crypto_op { >>>>>>> uint64_t type: 8; >>>>>>> uint64_t status: 8; >>>>>>> uint64_t sess_type: 8; >>>>>>> >>>>>>> struct rte_mempool *mempool; >>>>>>> >>>>>>> phys_addr_t phys_addr; >>>>>>> >>>>>>> RTE_STD_C11 >>>>>>> union { >>>>>>> struct rte_crypto_sym_op sym[0]; >>>>>>> }; >>>>>>> } __rte_cache_aligned; >>>>>>> >>>>>>> struct rte_crypto_sym_op { >>>>>>> struct rte_mbuf *m_src; >>>>>>> struct rte_mbuf *m_dst; >>>>>>> >>>>>>> RTE_STD_C11 >>>>>>> union { >>>>>>> struct rte_cryptodev_sym_session *session; >>>>>>> struct rte_crypto_sym_xform *xform; >>>>>>> }; >>>>>>> >>>>>>> struct { >>>>>>> uint8_t offset; >>>>>>> } iv; >>>>>>> >>>>>>> struct { >>>>>>> union { >>>>>>> struct { >>>>>>> uint32_t offset; >>>>>>> uint32_t length; >>>>>>> } data; >>>>>>> struct { >>>>>>> uint32_t length; >>>>>>> uint8_t *data; >>>>>>> phys_addr_t phys_addr; >>>>>>> } aad; >>>>>>> }; >>>>>>> >>>>>>> struct { >>>>>>> uint8_t *data; >>>>>>> phys_addr_t phys_addr; >>>>>>> } digest; >>>>>>> >>>>>>> } auth; >>>>>>> struct { >>>>>>> struct { >>>>>>> uint32_t offset; >>>>>>> uint32_t length; >>>>>>> } data; >>>>>>> >>>>>>> } cipher; >>>>>>> >>>>>>> __extension__ char _private[0]; >>>>>>> }; >>>>>>> >>>>>>> Signed-off-by: Pablo de Lara >>>>>>> --- >>>>>> >>>>>> Comments inline. >>>>>> >>>>>> Regards, >>>>>> Akhil >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >