From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id 92E0D2A5F for ; Fri, 28 Oct 2016 14:33:58 +0200 (CEST) Received: by mail-wm0-f53.google.com with SMTP id p190so7132775wmp.1 for ; Fri, 28 Oct 2016 05:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=8BykJpSPSH9o9WFpnf6n9ke+vhDH0NYR+LV9qisVOgM=; b=rK9dsy+IJH+B9pcOdc/uO1CNM8JkWXehomtd5dFjAV0sZpXeVJ0zn+fBTTcuPO/vrj eIMMBRHgpet9VwaEixEf8UoCyL/Z+UQB/AfXyyV7DIs8Ph+qhsyowDG0gImpvKg/UWWJ fKcJJmLWv3pvaOwqkNMbNq/0JwGRZ+yFKDtT9utonYuj3OXwDdF7OrUPKQO+bMYB+wUP dHHQN7yJfN009XY1MR9C/tiTzOW1wHkHvTIbpv4wbCmjI3HwFNZMz5FkDrzmJupKfzMh B6CIKKzyV9ZjWHzw+mAvac5YXaYlrK/epjR9BrmHxRYxP16lYtTdhlDRymkIE7i4aT0l zMSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=8BykJpSPSH9o9WFpnf6n9ke+vhDH0NYR+LV9qisVOgM=; b=MQKTf3P0siksp4m04CpzKeECyEGOYQ3iSEr1Vgjsz9YPFZIp5Ig4/U/EXCqrLd2Rrn aIrF38ZqsRbx8f7SRqagHeaaJbN9SZO/jdYI6D+iTcuPNwQ5IfcM5N9+5SX2NVFD/GRW bKLE4ZuQWvWa+HPz9melxG+hMbZEqEKEnM7tn11ny5Rj7R52mdrsCF6kBX2bRVzzYnU8 kZ+2/N3SEgXVZzOk+eLD825EDt6d7NxM4QkKH4LuMrdlQNhgmuBiPaZBlg87o+IJF0q3 e3BmPziomPoO5BTstf3fERKIXj3LF/MkKsixi2dcFoQPJCT4irb4PwlJ6pYZd9ZczFCU Q3uw== X-Gm-Message-State: ABUngvcM6pCsqmfi+Cv+o24SYTA82rTk3qFZCyuf4SW96gC95ltCsW2gU2drA4plRHb7K0hk X-Received: by 10.194.158.131 with SMTP id wu3mr11186345wjb.93.1477658038157; Fri, 28 Oct 2016 05:33:58 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id q134sm8748255wme.3.2016.10.28.05.33.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Oct 2016 05:33:57 -0700 (PDT) From: Thomas Monjalon To: Andrew Rybchenko Date: Fri, 28 Oct 2016 14:33:56 +0200 Message-ID: <1838661.tWJoShD1UF@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <2de43e28-37f8-86f5-b45f-2e598137b3dc@solarflare.com> References: <7987614.kmGMHz0qWb@xps13> <2de43e28-37f8-86f5-b45f-2e598137b3dc@solarflare.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 12:33:58 -0000 2016-10-28 13:50, Andrew Rybchenko: > 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. I don't know libefx. In DPDK, a base driver is often a subdirectory inside the PMD. Will it be the case? > 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. Such commit is also the opportunity to explain acronyms and so on. > > 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. Thanks