From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by dpdk.org (Postfix) with ESMTP id 5958E2BA7 for ; Thu, 24 Nov 2016 17:16:01 +0100 (CET) Received: from unknown [193.34.186.16] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-7.2.4-7) with ESMTP id 14217385.2ac17da08940.285081.00-2436.295264.nbfkord-smmo04.seg.att.com (envelope-from ); Thu, 24 Nov 2016 16:16:01 +0000 (UTC) X-MXL-Hash: 583712410859e272-a1fa5712809cb230d8dfbae8d28240584cbf3551 Received: from unknown [193.34.186.16] by nbfkord-smmo04.seg.att.com(mxl_mta-7.2.4-7) with SMTP id e3217385.0.285078.00-2389.295258.nbfkord-smmo04.seg.att.com (envelope-from ); Thu, 24 Nov 2016 16:16:00 +0000 (UTC) X-MXL-Hash: 583712406a3ebcb9-b73a54a6cd37dc3b81a10e87d6f4b5be84393706 Received: from [192.168.38.17] (84.52.89.52) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 24 Nov 2016 16:15:38 +0000 To: Ferruh Yigit , References: <1479740470-6723-1-git-send-email-arybchenko@solarflare.com> From: Andrew Rybchenko Message-ID: <0982edd5-0ee6-2d2a-0c15-38c1edab5d7a@solarflare.com> Date: Thu, 24 Nov 2016 19:15:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [84.52.89.52] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.000.1202-22718.003 X-TM-AS-Result: No--22.448200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=e9YAPPd/ c=1 sm=1 tr=0 a=8P+NB+fYZDP74ap4g4d9Kw==] X-AnalysisOut: [:17 a=RB3BGLmKESwA:10 a=L24OOQBejmoA:10 a=6I5d2MoRAAAA:8 a] X-AnalysisOut: [=NEAV23lmAAAA:8 a=8I-DJaMJej4K-FQySzAA:9 a=pILNOxqGKmIA:10] X-AnalysisOut: [ a=QyXUC8HyAAAA:8 a=Qmc0g7EYbwu_OcX3h4UA:9 a=lyke9sDePdGL3] X-AnalysisOut: [56B:21 a=_W_S_7VecoQA:10 a=IjZwj45LgO3ly-622nXo:22 a=Bn2pg] X-AnalysisOut: [wyD2vrAyMmN8A2t:22 a=avl4LiGQNoF5OB0DmCJ7:22] X-Spam: [F=0.2300878321; CM=0.500; S=0.230(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [193.34.186.16] Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH 00/56] Solarflare libefx-based PMD X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 16:16:01 -0000 On 11/23/2016 06:29 PM, Ferruh Yigit wrote: > On 11/21/2016 3:00 PM, Andrew Rybchenko wrote: >> The patch series adds Solarflare libefx-based network PMD. >> >> This version of the driver supports Solarflare SFN7xxx and SFN8xxx >> families of 10/40 Gbps adapters. >> >> libefx is a platform-independent library to implement drivers for >> Solarflare network adapters. It provides unified adapter family >> independent interface (if possible). FreeBSD [1] and illumos [2] >> drivers are built on top of the library. >> >> The patch series could be logically structured into 5 sub-series: >> 1. (1) add the driver skeleton including documentation >> 2. (2-30) import libefx and include it in build with the latest patch >> 3. (31-43) implement minimal device level operations in steps >> 4. (44-51) implement Rx subsystem >> 5. (52-56) implement Tx subsystem >> >> Functional driver with multi-queue support capable to send and receive >> traffic appears with the last patch in the series. >> >> The following design decisions are made during development: >> >> 1. Since libefx uses positive errno return codes, positive errno >> return codes are used inside the driver and coversion to negative >> is done on return from eth_dev_ops callbacks. We think that it >> is the less error-prone way. >> >> 2. Another Solarflare PMD with in-kernel part (for control operations) >> is considered and could be added in the future. Code for data path >> should be shared by these two drivers. libefx-based PMD is put into >> 'efx' subdirectory to have a space for another PMD and shared code. >> >> 3. Own event queue (a way to deliver events from HW to host CPU) is >> used for house-keeping (e.g. link status notifications), each Tx >> and each Rx queue. No locks on datapath are requires in this case. >> >> 4. Alarm is used to periodically poll house-keeping event queue. >> The event queue is used to deliver link status change notifications, >> Rx/Tx queue flush events, SRAM events. It is not used on datapath. >> The event queue polling is protected using spin-lock since >> concurrent access from different contexts is possible (e.g. device >> stop when polling alarm is running). >> >> [1] https://svnweb.freebsd.org/base/head/sys/dev/sfxge/common/ >> [2] https://github.com/illumos/illumos-gate/tree/master/usr/src/uts/common/io/sfxge/common/ >> >> --- > I would like to note that very well organized patchset. Thank you for > your effort. Thanks a lot, it is very pleasant to read it. Please, see my questions in thread for patches 01/56 (about compiler versions to test on) and 30/56 (about libefx configuration documentation). Also I'd like to ask a question about the further patches submission. We have about 40 patches which support various features (RSS, stats, flow control and many others). What is the preferred way to submit it? A. Separately since they are not so tightly related (but in fact cannot be applied in random order since some touch the same lines in code) B. As a series to process everything in one go. Thanks, Andrew.