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 03FC9326C for ; Fri, 28 Oct 2016 12:51:07 +0200 (CEST) Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo04.seg.att.com(mxl_mta-7.2.4-7) with ESMTP id c9d23185.2b7a7608f940.2111597.00-2456.4740319.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 28 Oct 2016 10:51:08 +0000 (UTC) X-MXL-Hash: 58132d9c634245c0-546f9c06216e082e21a22d9a976ce72358be0b29 Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo04.seg.att.com(mxl_mta-7.2.4-7) over TLS secured channel with ESMTP id 99d23185.0.2111596.00-2389.4740315.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 28 Oct 2016 10:51:06 +0000 (UTC) X-MXL-Hash: 58132d9a45795067-f0aeeaf929d828c0a763710a0745342eecb65b61 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 11:51:00 +0100 To: Thomas Monjalon References: <7987614.kmGMHz0qWb@xps13> From: Andrew Rybchenko Message-ID: <2de43e28-37f8-86f5-b45f-2e598137b3dc@solarflare.com> Date: Fri, 28 Oct 2016 13:50:55 +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: <7987614.kmGMHz0qWb@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--17.668100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=YdO7kllf 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=z56nC09_Ld1okZdxl9sA:9 a=pILNOxqGKmIA:10] X-Spam: [F=0.3223164237; CM=0.500; S=0.322(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 10:51:08 -0000 Thomas, On 10/27/2016 01:37 PM, Thomas Monjalon wrote: > First of all, welcome to DPDK! Thanks! > 2016-10-27 09:34, Andrew Rybchenko: >> we would like to include Solarflare libefx-based PMD in the DPDK 17.02 >> and start the upstreaming process. >> The driver supports Solarflare SFN7xxx and SFN8xxx families of 10/40 >> Gbps adapters. >> The driver has base driver. It is just fresh version of the same code >> which is used in the FreeBSD [1], illumos [2] and some other Solarflare >> drivers. > Unfortunately it is common to have some big base drivers in DPDK. > Note that some PMD rely on their kernel counterpart for the control path. > It is a way to avoid code duplication. Linux kernel sfc driver has control path functionality, but technically it is a different code. > As far as I understand, it is easier to share queues with DPDK from kernel > when the device supports an IOMMU. > >> The question is how to submit the base driver which is pretty big. Mail >> size of the patch which imports it is about 2 Mb. > First answer is a question: > Have you thought about cooperating with the kernel driver for your PMD? Yes, we considered it, but decided that we need pure userspace driver since the approach has its advantages: no specific dependencies from kernel, the same PMD for Linux and FreeBSD etc. > If you really cannot use this approach, then we have to maintain this > whole base driver in DPDK. > It will be easier to read, understand and reference if it is a bit split. > Could you try to send it as 10 to 20 patches explaining the role of each > part and giving some design details? First of all I'd like to double check that it is clear that we discuss libefx (base driver in terms of DPDK) import here. The PMD itself is already split in 20+ patches. 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. > 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. > Please be prepare to work on several iterations of the patch series. We have already passed a number of iterations internally, so it will not frighten. > PS: the mailing list put emails exceeding 300KB into a moderation queue. Nice to know that it is not completely rejected, since even if we split as described above, we still have one candidate which will end-up in moderation queue. Thanks, Andrew.