From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id BE3D8558A for ; Fri, 25 Nov 2016 11:25:27 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 25 Nov 2016 02:25:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,546,1473145200"; d="scan'208";a="1064028486" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.57]) ([10.237.220.57]) by orsmga001.jf.intel.com with ESMTP; 25 Nov 2016 02:25:25 -0800 To: Andrew Rybchenko , dev@dpdk.org References: <1479740470-6723-1-git-send-email-arybchenko@solarflare.com> <0982edd5-0ee6-2d2a-0c15-38c1edab5d7a@solarflare.com> From: Ferruh Yigit Message-ID: Date: Fri, 25 Nov 2016 10:25:25 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <0982edd5-0ee6-2d2a-0c15-38c1edab5d7a@solarflare.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: Fri, 25 Nov 2016 10:25:28 -0000 On 11/24/2016 4:15 PM, Andrew Rybchenko wrote: > 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. If they can't be applied in random order, it is better send as a patchset. But if you can make multiple logically independent patchsets with small effort, please do, smaller patchsets are easier to chew. > > Thanks, > Andrew.