From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id 1A70E1B4A7 for ; Tue, 16 Apr 2019 12:11:50 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 76F9FB3F5; Tue, 16 Apr 2019 06:11:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 16 Apr 2019 06:11:49 -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=+jWxJqBovelpc3SWyQholV2pMFXZh8m1HEzDXUexLAY=; b=Efq/JXHRCC4k VLq7J8TpUmriuMzGmypyy2S5JXdR9N2XI1J3CcooHYMdfbPPsyktACF5rfQrvV+R attpubDNud4CC4pj9Tmy3I0W+zvrh+6XZd2UKvMIeGOI86PiBUX0ohDe2fdRuELr r852GVLrhUjjIUHc4jD7F7Ln6owdNPM= 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=+jWxJqBovelpc3SWyQholV2pMFXZh8m1HEzDXUexL AY=; b=uLuzCtq2DiYXYzC1o/QqZhWio/PnFlLyFAJs6OmAuzHQN2R7+Z+I13tVF KL97EdA2PCHJhqo+hxOntIvCn0D4KtkS3qnriiE/m9c3q/b1ol4u1Aw+LL1NpZeE ka0LThGtdapSHw1CH4x/6M6ePlttyTSyAwznE7PYtiL9n/APEEu+kOuYN91frB4M Y+Jf/uZldmzXFPIBH0zY7AzJG/Yc2z2Sil9DGh6AepsDt2t1ZXGA++RHiFI4Pntk ak8Bdih3WCXS9WVdkFWrlDcU4EjsuuVZ0UB7jxJKvNJyFqVv5ce09h3ffU3HwT5c 3UQlObu0tFkc2F/RnneMcrBpKVwpg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrfedugddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgepud 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 5D4C3E407B; Tue, 16 Apr 2019 06:11:47 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko Cc: Ferruh Yigit , Igor Russkikh , "dev@dpdk.org" , Pavel Belous , Wenzhuo Lu , Jingjing Wu , Bernard Iremonger , John McNamara , Marko Kovacevic , Konstantin Ananyev Date: Tue, 16 Apr 2019 12:11:45 +0200 Message-ID: <2770175.vkBUT7hhTE@xps> In-Reply-To: References: 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: Tue, 16 Apr 2019 10:11:50 -0000 16/04/2019 11:58, Andrew Rybchenko: > On 4/16/19 12:43 PM, Ferruh Yigit wrote: > > On 4/13/2019 8:24 AM, Igor Russkikh wrote: > >> Hi Ferruh, > >> > >>>> +int > >>>> +rte_eth_macsec_select_txsa(uint16_t port_id, > >>>> + uint8_t idx, uint8_t an, > >>>> + uint32_t pn, uint8_t *key); > >>>> + > >>>> > >>>> #include > >>>> > >>> These are new ethdev APIs, not driver code, that have been sent after rc1, so > >>> these didn't go through a proper review cycle, we didn't get any comment on any > >>> other possible driver can use it, I am for postponing the series to next release. > >>> > >>> Also there are some mechanical issues [1] but main thing is adding a set of API > >>> to late in release cycle without proper review. > >> I see, that's reasonable. > >> > >> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)? > >> Two points here: > >> > >> 1) Thomas raised a reasonable question whether all the macsec control in general should happen > >> through the rte_security set of APIs. This obviously could be done, but with proper design > >> of rte_security structures and ops. > >> > >> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form > >> of private driver API as it runs in ixgbe now. This code is functional and will not be > >> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion. > >> > > If there is a commitment to work on a generic solution for 19.08, involving > > other users too, I would be OK to get the support as PMD API for this release. > > > > If that is accepted, please bu sure too add experimental tag to new PMD APIs and > > even add to release notes about intention and that the PMD specific APIs are > > temporary. And if ABI breakage required, put any necessary deprecation notice > > withing this release scope so that the development is not blocked for next release. > > > > Thomas, Andrew, what do you think? > > I agree. +1 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 05E42A00E6 for ; Tue, 16 Apr 2019 12:11:52 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C8DF51B4A8; Tue, 16 Apr 2019 12:11:51 +0200 (CEST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id 1A70E1B4A7 for ; Tue, 16 Apr 2019 12:11:50 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 76F9FB3F5; Tue, 16 Apr 2019 06:11:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 16 Apr 2019 06:11:49 -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=+jWxJqBovelpc3SWyQholV2pMFXZh8m1HEzDXUexLAY=; b=Efq/JXHRCC4k VLq7J8TpUmriuMzGmypyy2S5JXdR9N2XI1J3CcooHYMdfbPPsyktACF5rfQrvV+R attpubDNud4CC4pj9Tmy3I0W+zvrh+6XZd2UKvMIeGOI86PiBUX0ohDe2fdRuELr r852GVLrhUjjIUHc4jD7F7Ln6owdNPM= 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=+jWxJqBovelpc3SWyQholV2pMFXZh8m1HEzDXUexL AY=; b=uLuzCtq2DiYXYzC1o/QqZhWio/PnFlLyFAJs6OmAuzHQN2R7+Z+I13tVF KL97EdA2PCHJhqo+hxOntIvCn0D4KtkS3qnriiE/m9c3q/b1ol4u1Aw+LL1NpZeE ka0LThGtdapSHw1CH4x/6M6ePlttyTSyAwznE7PYtiL9n/APEEu+kOuYN91frB4M Y+Jf/uZldmzXFPIBH0zY7AzJG/Yc2z2Sil9DGh6AepsDt2t1ZXGA++RHiFI4Pntk ak8Bdih3WCXS9WVdkFWrlDcU4EjsuuVZ0UB7jxJKvNJyFqVv5ce09h3ffU3HwT5c 3UQlObu0tFkc2F/RnneMcrBpKVwpg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrfedugddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgepud 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 5D4C3E407B; Tue, 16 Apr 2019 06:11:47 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko Cc: Ferruh Yigit , Igor Russkikh , "dev@dpdk.org" , Pavel Belous , Wenzhuo Lu , Jingjing Wu , Bernard Iremonger , John McNamara , Marko Kovacevic , Konstantin Ananyev Date: Tue, 16 Apr 2019 12:11:45 +0200 Message-ID: <2770175.vkBUT7hhTE@xps> In-Reply-To: References: 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: <20190416101145.nVecHKp3w14Ptd_hne-DqHhKyzbre88PwNI-OAowXJM@z> 16/04/2019 11:58, Andrew Rybchenko: > On 4/16/19 12:43 PM, Ferruh Yigit wrote: > > On 4/13/2019 8:24 AM, Igor Russkikh wrote: > >> Hi Ferruh, > >> > >>>> +int > >>>> +rte_eth_macsec_select_txsa(uint16_t port_id, > >>>> + uint8_t idx, uint8_t an, > >>>> + uint32_t pn, uint8_t *key); > >>>> + > >>>> > >>>> #include > >>>> > >>> These are new ethdev APIs, not driver code, that have been sent after rc1, so > >>> these didn't go through a proper review cycle, we didn't get any comment on any > >>> other possible driver can use it, I am for postponing the series to next release. > >>> > >>> Also there are some mechanical issues [1] but main thing is adding a set of API > >>> to late in release cycle without proper review. > >> I see, that's reasonable. > >> > >> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)? > >> Two points here: > >> > >> 1) Thomas raised a reasonable question whether all the macsec control in general should happen > >> through the rte_security set of APIs. This obviously could be done, but with proper design > >> of rte_security structures and ops. > >> > >> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form > >> of private driver API as it runs in ixgbe now. This code is functional and will not be > >> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion. > >> > > If there is a commitment to work on a generic solution for 19.08, involving > > other users too, I would be OK to get the support as PMD API for this release. > > > > If that is accepted, please bu sure too add experimental tag to new PMD APIs and > > even add to release notes about intention and that the PMD specific APIs are > > temporary. And if ABI breakage required, put any necessary deprecation notice > > withing this release scope so that the development is not blocked for next release. > > > > Thomas, Andrew, what do you think? > > I agree. +1