From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id C9C045F16 for ; Fri, 12 Apr 2019 13:22:54 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 1207AB831; Fri, 12 Apr 2019 07:22:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 12 Apr 2019 07:22:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=vShPiasMl3RO+2z7aLn7nIeGH8/pON23A8TnbUEt/gU=; b=f2R8AKVwhhG5 qozfuftTUq+DYHrBl7LRdTqX3z58lvibtXBzpXmlaaQHC8d/m6SEqJYbOvA+vodq BvrTWKpQjWl+IuLoDdboGv86dESyQBA8iPO2wCi16MlyeuZDHJgk0AhMAuyYxc4S P6ygS1XUzxHM8TwYaGgi4Oil/lFoeM4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=vShPiasMl3RO+2z7aLn7nIeGH8/pON23A8TnbUEt/ gU=; b=ZIFWRCVH6MaZm3o2jD1kgkyTszPHTDytvjqSs5f3S7UVE+SwrUFKcqkAZ ZSFtYYxQMoEKjNQ4hmD7vpDbJa+w+RC/jmw1+Nrq3VsZLsKS3Geo4Yb75MnM+gX/ Te/f0QZ/r3LEyrFauisBhULSzA4e3CLJB20kBVDhAbvpNGaKJ/koZu7LA67GpDtu khraptG/7lPmHY48T8Gp5dkrbo38VrrG+oSuEGzcdkge9bYZ0ICGbkF54Fc8J37y 1ThEYY8xANtOJZ2URHCg0bIh2cseSCQQQfssY8i90vFHWjws+VAJY2z6Aam3TyHB C6ZItwbQUKYet0enwyUmkgOJwv4iw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrvddugdduhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id BA101100E5; Fri, 12 Apr 2019 07:22:50 -0400 (EDT) From: Thomas Monjalon To: Igor Russkikh , "akhil.goyal@nxp.com" Cc: "dev@dpdk.org" , Pavel Belous , Wenzhuo Lu , Jingjing Wu , Bernard Iremonger , John McNamara , Marko Kovacevic , Konstantin Ananyev , Ferruh Yigit , Andrew Rybchenko Date: Fri, 12 Apr 2019 13:22:49 +0200 Message-ID: <2900506.7bG6BaBg05@xps> In-Reply-To: <455dcd32-d2a5-776b-9883-3112db2e9e3c@aquantia.com> References: <10808776.O5mG4nBl1r@xps> <455dcd32-d2a5-776b-9883-3112db2e9e3c@aquantia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops 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: Fri, 12 Apr 2019 11:22:55 -0000 12/04/2019 10:50, Igor Russkikh: > > >>> Please can you explain how it is related to rte_security? > >> > >> It is not. > >> Do you mean macsec control API could be moved and logically be a part of rte_security api? > >> I can't comment now on how feasible is this. Moreover this depends on how Intel considers > >> and uses the existing macsec offload in ixgbe. > > > > There are RTE_SECURITY_PROTOCOL_MACSEC and rte_security_macsec_* structs > > in librte_security. > > Please check how it can be used while defining an ethdev API. > > There is nothing in rte_security defined explicitly for macsec except that enum item. > All the macsec structures are dummy. Was there any intent to implement this? > > I can writeup the generic macsec structures for rte_security, do you think that's feasible? I don't know. We are in front of a case of dead code written well too far in advance. Akhil, any suggestion? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 6CE8CA0096 for ; Fri, 12 Apr 2019 13:22:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A2C4F5F2E; Fri, 12 Apr 2019 13:22:56 +0200 (CEST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id C9C045F16 for ; Fri, 12 Apr 2019 13:22:54 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 1207AB831; Fri, 12 Apr 2019 07:22:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 12 Apr 2019 07:22:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=vShPiasMl3RO+2z7aLn7nIeGH8/pON23A8TnbUEt/gU=; b=f2R8AKVwhhG5 qozfuftTUq+DYHrBl7LRdTqX3z58lvibtXBzpXmlaaQHC8d/m6SEqJYbOvA+vodq BvrTWKpQjWl+IuLoDdboGv86dESyQBA8iPO2wCi16MlyeuZDHJgk0AhMAuyYxc4S P6ygS1XUzxHM8TwYaGgi4Oil/lFoeM4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=vShPiasMl3RO+2z7aLn7nIeGH8/pON23A8TnbUEt/ gU=; b=ZIFWRCVH6MaZm3o2jD1kgkyTszPHTDytvjqSs5f3S7UVE+SwrUFKcqkAZ ZSFtYYxQMoEKjNQ4hmD7vpDbJa+w+RC/jmw1+Nrq3VsZLsKS3Geo4Yb75MnM+gX/ Te/f0QZ/r3LEyrFauisBhULSzA4e3CLJB20kBVDhAbvpNGaKJ/koZu7LA67GpDtu khraptG/7lPmHY48T8Gp5dkrbo38VrrG+oSuEGzcdkge9bYZ0ICGbkF54Fc8J37y 1ThEYY8xANtOJZ2URHCg0bIh2cseSCQQQfssY8i90vFHWjws+VAJY2z6Aam3TyHB C6ZItwbQUKYet0enwyUmkgOJwv4iw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrvddugdduhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id BA101100E5; Fri, 12 Apr 2019 07:22:50 -0400 (EDT) From: Thomas Monjalon To: Igor Russkikh , "akhil.goyal@nxp.com" Cc: "dev@dpdk.org" , Pavel Belous , Wenzhuo Lu , Jingjing Wu , Bernard Iremonger , John McNamara , Marko Kovacevic , Konstantin Ananyev , Ferruh Yigit , Andrew Rybchenko Date: Fri, 12 Apr 2019 13:22:49 +0200 Message-ID: <2900506.7bG6BaBg05@xps> In-Reply-To: <455dcd32-d2a5-776b-9883-3112db2e9e3c@aquantia.com> References: <10808776.O5mG4nBl1r@xps> <455dcd32-d2a5-776b-9883-3112db2e9e3c@aquantia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190412112249.B6lEDH8hMH0uFtbGYNIwH982KuHpaLS8O-SuXiiAEto@z> 12/04/2019 10:50, Igor Russkikh: > > >>> Please can you explain how it is related to rte_security? > >> > >> It is not. > >> Do you mean macsec control API could be moved and logically be a part of rte_security api? > >> I can't comment now on how feasible is this. Moreover this depends on how Intel considers > >> and uses the existing macsec offload in ixgbe. > > > > There are RTE_SECURITY_PROTOCOL_MACSEC and rte_security_macsec_* structs > > in librte_security. > > Please check how it can be used while defining an ethdev API. > > There is nothing in rte_security defined explicitly for macsec except that enum item. > All the macsec structures are dummy. Was there any intent to implement this? > > I can writeup the generic macsec structures for rte_security, do you think that's feasible? I don't know. We are in front of a case of dead code written well too far in advance. Akhil, any suggestion?