DPDK patches and discussions
 help / color / mirror / Atom feed
From: Andrew Rybchenko <arybchenko@solarflare.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Solarflare PMD submission question
Date: Fri, 28 Oct 2016 17:43:43 +0300	[thread overview]
Message-ID: <b0978fcf-1bb1-d454-cc72-364c4b7aa9b0@solarflare.com> (raw)
In-Reply-To: <1838661.tWJoShD1UF@xps13>

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.

  parent reply	other threads:[~2016-10-28 14:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-27  6:34 Andrew Rybchenko
2016-10-27 10:37 ` Thomas Monjalon
2016-10-28 10:50   ` Andrew Rybchenko
2016-10-28 12:33     ` Thomas Monjalon
2016-10-28 13:05       ` Andrew Rybchenko
2016-10-28 13:14         ` Thomas Monjalon
2016-10-28 14:43       ` Andrew Rybchenko [this message]
2016-11-18 16:50         ` Andrew Rybchenko
2016-11-21  8:19           ` Thomas Monjalon
2016-11-21  8:46             ` Andrew Rybchenko
2016-11-21  8:59               ` Thomas Monjalon
2016-11-21 10:30                 ` Ferruh Yigit
2016-11-21 15:03                   ` Andrew Rybchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b0978fcf-1bb1-d454-cc72-364c4b7aa9b0@solarflare.com \
    --to=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).