From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nbfkord-smmo01.seg.att.com (nbfkord-smmo01.seg.att.com [209.65.160.76]) by dpdk.org (Postfix) with ESMTP id 142A958CB for ; Fri, 25 Nov 2016 13:45:52 +0100 (CET) Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo01.seg.att.com(mxl_mta-7.2.4-7) with ESMTP id 18238385.2ba7f600f940.1168047.00-2473.2475287.nbfkord-smmo01.seg.att.com (envelope-from ); Fri, 25 Nov 2016 12:45:53 +0000 (UTC) X-MXL-Hash: 583832814c877fa9-dedd3f39f1ed2c3edeb2e953eee5fc1df0ae8f73 Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo01.seg.att.com(mxl_mta-7.2.4-7) over TLS secured channel with ESMTP id b4238385.0.1167962.00-2393.2475118.nbfkord-smmo01.seg.att.com (envelope-from ); Fri, 25 Nov 2016 12:45:00 +0000 (UTC) X-MXL-Hash: 5838324c5945e2ef-dc904f6e0cfa0593b7cb858767274e4d8c65a63c 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; Fri, 25 Nov 2016 12:44:55 +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: <277f5931-f934-a22f-a1e3-b46f6372f993@solarflare.com> Date: Fri, 25 Nov 2016 15:44:50 +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-22720.003 X-TM-AS-Result: No--29.753700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=P5Y8830u 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=AGmkXnh99pbHM9qMs4YA: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: Fri, 25 Nov 2016 12:45:53 -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/* ? > > > [1]: > 1- There are a few (non-base) checkpatch warnings, can you please check > patch 36, 49, 50 and 55 please? > > 2- Got following compile issues, not investigated, directly sharing here: > > <...> > > 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); > ^ I think this one is not mine. > .../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"; > ^ It looks like output is mixed here. Looking at the code I think the first is false warning. Assigned variable is 'const char *' and all assigned values are string literals. > filter_flags = 0; > ^ Will fix in v2. > .../drivers/net/sfc/efx/base/efx_mcdi.c(1426): warning #188: enumerated > type mixed with another type > epp->ep_fixed_port_type = > ^ Wil try to fix in v2. > .../drivers/net/sfc/efx/base/efx_nic.c(556): warning #188: enumerated > type mixed with another type > enp->en_family = 0; > ^ Will fix in v2. Andrew.