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 D1E1558CF for ; Fri, 28 Oct 2016 16:44:15 +0200 (CEST) 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 f3463185.2b42d5a88940.1262998.00-2453.3002034.nbfkord-smmo01.seg.att.com (envelope-from ); Fri, 28 Oct 2016 14:44:15 +0000 (UTC) X-MXL-Hash: 5813643f692b25c9-3217ad920324e769ab0cc65c33a3c49e0b4da911 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 e3463185.0.1262997.00-2373.3002030.nbfkord-smmo01.seg.att.com (envelope-from ); Fri, 28 Oct 2016 14:44:14 +0000 (UTC) X-MXL-Hash: 5813643e0b15f7b1-4736f0ed6c1ef79ac5347cefe363bc4b8ead7515 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, 28 Oct 2016 15:43:47 +0100 To: Thomas Monjalon References: <7987614.kmGMHz0qWb@xps13> <2de43e28-37f8-86f5-b45f-2e598137b3dc@solarflare.com> <1838661.tWJoShD1UF@xps13> From: Andrew Rybchenko Message-ID: Date: Fri, 28 Oct 2016 17:43:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1838661.tWJoShD1UF@xps13> 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-22664.003 X-TM-AS-Result: No--14.923800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=KdTUxFsD c=1 sm=1 tr=0 a=8P+NB+fYZDP74ap4g4d9Kw==] X-AnalysisOut: [:17 a=RB3BGLmKESwA:10 a=N659UExz7-8A:10 a=CH0kA5CcgfcA:10 ] X-AnalysisOut: [a=VwQbUJbxAAAA:8 a=6I5d2MoRAAAA:8 a=NEAV23lmAAAA:8 a=DuC14] X-AnalysisOut: [KTujpC5C7-JadgA:9 a=pILNOxqGKmIA:10 a=AjGcO6oz07-iQ99wixmX] X-AnalysisOut: [:22 a=IjZwj45LgO3ly-622nXo:22 a=Bn2pgwyD2vrAyMmN8A2t:22] X-Spam: [F=0.4920277412; CM=0.500; S=0.492(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [193.34.186.16] Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Solarflare PMD submission question 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, 28 Oct 2016 14:44:16 -0000 On 10/28/2016 03:33 PM, Thomas Monjalon wrote: > 2016-10-28 13:50, Andrew Rybchenko: >> The only thing which comes to my mind is to split libefx import on subsystem >> basis (few files per subsystem). It is artificial and added files will >> be abandoned >> until the patch which adds them into build. It could be something like: >> 1. External interfaces definition >> 2. Internal interfaces definition >> 3. Registers definition (hardware interface) >> 4. Management CPU interface definition (it is one file, but still big >> 650K) >> 5. Management CPU interface implementation >> and so on for NIC global controls, interrupts, event queue, transmit, >> receive, >> filtering etc. > Yes it is artificial. > The most valuable would be a transversal logical split, kind of feature > per feature, in order to explain how the device works. I'm not the main author of the libefx and personally would consider it very useful. From the other hand I understand that it is a huge amount of work to make it. > Such commit is also the opportunity to explain acronyms and so on. Good. We'll go this way and 'll do my best to make it useful to understand overall structure of the code and how the device works. >>> It would be also really appreciated to provide a design documentation >>> in doc/guides/nics. Are the datasheets open? A link in the doc would help. >> We have a documentation which grows together with supported features, >> but it is rather for users. Important design decisions (not so many) are >> documented nearby corresponding code. Unfortunately there is no open >> datasheets. Management CPU interface definition has comments. > Without neither a datasheet, nor a comprehensive code introduction, it is > almost impossible to dive in your code. So it misses the point about bringing > it to an Open Source project. > Please do the the effort to bring some knowledge to the community. I've raised this internally and see what extra documentation we can provide to the community. But this may take some time and I hope it is OK to post patches in the interim. I use the management CPU interface (MCDI) definition mentioned above when I add features. It is shared by all drivers: [1], [2], [3]. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/sfc/mcdi_pcol.h [2] https://svnweb.freebsd.org/base/head/sys/dev/sfxge/common/efx_regs_mcdi.h?view=markup [3] https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/io/sfxge/common/efx_regs_mcdi.h Andrew.