From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by dpdk.org (Postfix) with ESMTP id 3AB85567E for ; Wed, 23 Nov 2016 08:49:44 +0100 (CET) Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo03.seg.att.com(mxl_mta-7.2.4-7) with ESMTP id 81a45385.2afaf585b940.2421480.00-2494.5470839.nbfkord-smmo03.seg.att.com (envelope-from ); Wed, 23 Nov 2016 07:49:44 +0000 (UTC) X-MXL-Hash: 58354a187841efa1-02304c7cf3954c141ffea26b83ff8c30261a513d Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo03.seg.att.com(mxl_mta-7.2.4-7) over TLS secured channel with ESMTP id 51a45385.0.2421478.00-2356.5470833.nbfkord-smmo03.seg.att.com (envelope-from ); Wed, 23 Nov 2016 07:49:42 +0000 (UTC) X-MXL-Hash: 58354a1600a7e79a-eabc418de5d1093ebed5ed426f728c2dc3a4583c 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; Wed, 23 Nov 2016 07:49:36 +0000 To: Ferruh Yigit , References: <1479740470-6723-1-git-send-email-arybchenko@solarflare.com> <9cdced57-ba4c-fd0e-c509-904d333aab50@intel.com> From: Andrew Rybchenko Message-ID: <5d041f12-ec8d-77da-47ac-671eb3a39a5b@solarflare.com> Date: Wed, 23 Nov 2016 10:49: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: <9cdced57-ba4c-fd0e-c509-904d333aab50@intel.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit 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-22716.003 X-TM-AS-Result: No--29.465400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=SaLxA6lu c=1 sm=1 tr=0 a=8P+NB+fYZDP74ap4g4d9Kw==] X-AnalysisOut: [:17 a=RB3BGLmKESwA:10 a=N659UExz7-8A:10 a=L24OOQBejmoA:10 ] X-AnalysisOut: [a=6I5d2MoRAAAA:8 a=NEAV23lmAAAA:8 a=Jg2KuINkVdLKxbzE8dwA:9] X-AnalysisOut: [ a=pILNOxqGKmIA:10 a=IjZwj45LgO3ly-622nXo:22 a=Bn2pgwyD2vr] X-AnalysisOut: [AyMmN8A2t:22] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [193.34.186.16] 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: Wed, 23 Nov 2016 07:49:44 -0000 On 11/23/2016 03:02 AM, 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/ >> >> --- >> >> Andrew Rybchenko (49): >> net/sfc: libefx-based PMD stub sufficient to build and init >> net/sfc: import libefx base >> net/sfc: import libefx register definitions >> net/sfc: import libefx filters support >> net/sfc: import libefx MCDI definition >> net/sfc: import libefx MCDI implementation >> net/sfc: import libefx MCDI logging support >> net/sfc: import libefx MCDI proxy authorization support >> net/sfc: import libefx 5xxx/6xxx family support >> net/sfc: import libefx SFN7xxx family support >> net/sfc: import libefx SFN8xxx family support >> net/sfc: import libefx diagnostics support >> net/sfc: import libefx built-in selftest support >> net/sfc: import libefx software per-queue statistics support >> net/sfc: import libefx PHY flags control support >> net/sfc: import libefx PHY statistics support >> net/sfc: import libefx PHY LEDs control support >> net/sfc: import libefx MAC statistics support >> net/sfc: import libefx event prefetch support >> net/sfc: import libefx Rx scatter support >> net/sfc: import libefx RSS support >> net/sfc: import libefx loopback control support >> net/sfc: import libefx monitors statistics support >> net/sfc: import libefx support to access monitors via MCDI >> net/sfc: import libefx support for Rx packed stream mode >> net/sfc: import libefx NVRAM support >> net/sfc: import libefx VPD support >> net/sfc: import libefx bootrom configuration support >> net/sfc: import libefx licensing support >> net/sfc: implement dummy callback to get device information >> net/sfc: implement driver operation to init device on attach >> net/sfc: add device configure and close stubs >> net/sfc: add device configuration checks >> net/sfc: implement device start and stop operations >> net/sfc: make available resources estimation and allocation >> net/sfc: interrupts support sufficient for event queue init >> net/sfc: implement event queue support >> net/sfc: implement EVQ dummy exception handling >> net/sfc: maintain management event queue >> net/sfc: periodic management EVQ polling using alarm >> net/sfc: minimum port control sufficient to receive traffic >> net/sfc: implement Rx subsystem stubs >> net/sfc: check configured rxmode >> net/sfc: implement Rx queue setup release operations >> net/sfc: calculate Rx buffer size which may be used >> net/sfc: validate Rx queue buffers setup >> net/sfc: implement Rx queue start and stop operations >> net/sfc: implement device callback to Rx burst of packets >> net/sfc: discard scattered packet on Rx correctly >> >> Artem Andreev (2): >> net/sfc: include libefx in build >> net/sfc: implement device operation to retrieve link info >> >> Ivan Malov (5): >> net/sfc: provide basic stubs for Tx subsystem >> net/sfc: add function to check configured Tx mode >> net/sfc: add callbacks to set up and release Tx queues >> net/sfc: implement transmit path start / stop >> net/sfc: add callback to send bursts of packets >> > Hi Andrew, > > Thank you for the patch, I have encounter with a few minor issues, can > you please check them [1]? > > Also folder structure is drivers/net/sfc/efx/, why /sfc/ > layer is created? > sfc is company name (solarflare communications), right? Other driver > folders not structured based on company, what about using > drivers/net/efx/* ? I've tried to explain it above in item (2): >>> 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. <<< So, main reason is to have location for the code shared by two Solarflare network PMDs. May be it better to relocate when we really have it. I'm open for other ideas/suggestions. > [1]: > 1- There are a few (non-base) checkpatch warnings, can you please check > patch 36, 49, 50 and 55 please? Thanks, I'll fix spelling in v2. 36, 49 and 55 also ask to check multiple assignments. IMHO, it is the right usage of multiple assignment when logically bound variables must have the same value. > 2- Got following compile issues, not investigated, directly sharing here: > > b) for icc getting following warnings: > ======================================= > icc: command line warning #10006: ignoring unknown option '-Wno-empty-body' > icc: command line warning #10006: ignoring unknown option > '-Waggregate-return' > icc: command line warning #10006: ignoring unknown option > '-Wbad-function-cast' > icc: command line warning #10006: ignoring unknown option '-Wnested-externs' > > > c) icc compiler errors: > ======================================= > In file included from > .../x86_64-native-linuxapp-icc/include/rte_ethdev.h(185), > from .../drivers/net/sfc/efx/sfc.h(35), > from .../drivers/net/sfc/efx/sfc.c(37): > .../x86_64-native-linuxapp-icc/include/rte_ether.h(258): warning #2203: > cast discards qualifiers from target type > uint16_t *from_words = (uint16_t *)(ea_from->addr_bytes); > ^ > > .../drivers/net/sfc/efx/base/efx_mcdi.c(1157): warning #3179: deprecated > conversion of string literal to char* (should be const char*) > .../drivers/net/sfc/efx/base/ef10_filter.c(1276): warning #188: > enumerated type mixed with another type > : "unknown assertion"; > ^ > > filter_flags = 0; > ^ > > .../drivers/net/sfc/efx/base/efx_mcdi.c(1426): warning #188: enumerated > type mixed with another type > epp->ep_fixed_port_type = > ^ > > .../drivers/net/sfc/efx/base/efx_nic.c(556): warning #188: enumerated > type mixed with another type > enp->en_family = 0; Yes, I have no ICC compilers. I'll try to fix these warnings, but I can't be sure without checking it. Also we cannot claim ICC supported without building and testing the generated binary. Many thanks, Andrew.