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 B9D6CA00E6 for ; Tue, 16 Apr 2019 11:58:53 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8FFF91B499; Tue, 16 Apr 2019 11:58:52 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 9AE8F1B479 for ; Tue, 16 Apr 2019 11:58:50 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us2.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 9D8D3700079; Tue, 16 Apr 2019 09:58:48 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 16 Apr 2019 10:58:40 +0100 To: Ferruh Yigit , Igor Russkikh , "dev@dpdk.org" , Thomas Monjalon CC: Pavel Belous , Wenzhuo Lu , Jingjing Wu , "Bernard Iremonger" , John McNamara , Marko Kovacevic , Konstantin Ananyev References: <69b3fcf19cb3e11fae93281f40a1bbc0ec5a2e38.1554894242.git.igor.russkikh@aquantia.com> <429e73da-ca5b-1e97-7098-e720be3fae09@intel.com> From: Andrew Rybchenko Message-ID: Date: Tue, 16 Apr 2019 12:58:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24554.003 X-TM-AS-Result: No-17.166600-8.000000-10 X-TMASE-MatchedRID: WMT2WRIkHPMOwH4pD14DsPHkpkyUphL9RvyVHewb0kJnnK6mXN72myQ5 BpELg58D0g3HcVPWRMvhQxzbXWVk8MwdQieqpnTabMGKOuLn5FVAq6/y5AEOOtvpj5+dNlQvz2A LiRhzI8xE24kViAQnIZLKkPOo0Em89WAJysGWJAyd4hCa7xSZocnlJe2gk8vIlL1/3IuU47KPf+ sJS4b6eCScV1R9l9FpIo8NzYXOl0pdQf5WtNLrlJ6k6jtSoiX5Kx5ICGp/WtEhvFjBsLEZNEsq2 Qq9h9WiOQdhOYExg1YOl4+I2REw+nLQziG6bbRD6/xAZojbl7ehQhstwJ9G4K2ixYJpDDfR807t +VEWpeYgZIcq73TEpZJTzjwz+Gzox7hajJv6RUXIOn6NK8S1ayXdp9l6EkRZ52VTYrkmb1ssyVh q83/5UjU3HPhRrRy9/76CM4Z/MGblRxm3A2wKujl/1fD/GopdWQy9YC5qGvz6APa9i04WGLyah9 aCYUCHTZkoqxqVJdQMU7TYQZPa5Fn/01m/m2uVNNg8KPDtp8OMzbb06CPHF+eEd/0E17SNIDOX4 XuFMy0MXBye7Zlx6ydL0fdDCGg1 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--17.166600-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24554.003 X-MDID: 1555408729-DOQGfikiErC6 Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: <20190416095835.iu2O3hH7Z3ONVW_uq664pcyd9dRgbmNudWg3YRDOczU@z> 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.