From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B34ABC10F0E for ; Fri, 12 Apr 2019 11:22:58 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 3F53320674 for ; Fri, 12 Apr 2019 11:22:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=monjalon.net header.i=@monjalon.net header.b="f2R8AKVw"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="ZIFWRCVH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3F53320674 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=monjalon.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org 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="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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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?