All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Andrew Rybchenko <arybchenko@solarflare.com>,
	John McNamara <john.mcnamara@intel.com>,
	dev@dpdk.org, Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [PATCH v3] doc: document NIC features
Date: Fri, 7 Jul 2017 14:57:16 +0100	[thread overview]
Message-ID: <1f389cf5-ed5d-0768-ab91-76f458a0c219@intel.com> (raw)
In-Reply-To: <8948822.3HyaHf9bfD@xps>

On 7/7/2017 2:53 PM, Thomas Monjalon wrote:
> 07/07/2017 15:37, Ferruh Yigit:
>> On 7/7/2017 11:55 AM, Andrew Rybchenko wrote:
>>> Also some PMDs have few implementations of the datapath (like vector and 
>>> usual). Ideally
>>> we need common way to highlight it. May be it is OK that control path 
>>> features are duplicated
>>> in this case, but ideally it should be expressed somehow.
>>
>> I agree different datapath implementations can be documented better, I
>> just don't know how to do ...
>>
>> For some drivers there are multiple vector implementations and the
>> feature set for them is not clear. And as you said control features are
>> duplicated in the table.
>>
>> Perhaps control and datapath features can be separated.
>>
>> Or as Thomas suggested sometime ago, vector and scalar version can be
>> merged into one in the table and feature can be marked as supported if
>> both scalar and vector has support for it. But this is not solving
>> multiple vector implementation problem.
> 
> Yes it is the way to go.
> The features should not be different from a datapath implementation to
> another one. So they must be merged in only one column.
> If a feature is not supported in every datapaths of a driver, it should
> be marked as partially supported... and the developers must implement it.

But for example for i40e, there are altivec, neon and sse vector
implementations, how should we document this?

  reply	other threads:[~2017-07-07 13:57 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-15 16:37 [RFC] doc: document NIC features Ferruh Yigit
2017-06-21 13:25 ` [PATCH] " Ferruh Yigit
2017-06-22 19:02   ` [PATCH v2] " Ferruh Yigit
2017-07-02 20:20     ` Mcnamara, John
2017-07-05 13:20     ` [PATCH v3] " Ferruh Yigit
2017-07-05 16:03       ` Mcnamara, John
2017-07-07 10:55       ` Andrew Rybchenko
2017-07-07 13:37         ` Ferruh Yigit
2017-07-07 13:53           ` Thomas Monjalon
2017-07-07 13:57             ` Ferruh Yigit [this message]
2017-07-07 14:02               ` Thomas Monjalon
2017-07-07 14:13                 ` Ferruh Yigit
2017-07-07 14:20                   ` Wiles, Keith
2017-07-07 20:37                     ` Thomas Monjalon
2017-07-07 23:54                       ` Wiles, Keith
2017-07-07 15:06         ` Ferruh Yigit
2017-07-07 15:38           ` Andrew Rybchenko
2017-07-07 17:21       ` [PATCH v4] " Ferruh Yigit
2017-07-08  9:47         ` Andrew Rybchenko
2017-07-20  9:10           ` Ferruh Yigit
2017-07-20  9:23         ` [PATCH v5] " Ferruh Yigit
2017-07-26  5:08           ` Shreyansh Jain
2017-08-01 10:15             ` Ferruh Yigit
2017-08-01 15:23           ` [PATCH v6] " Ferruh Yigit
2017-08-03  8:56             ` Shreyansh Jain
2017-08-03  8:57               ` Shreyansh Jain
2017-08-03 10:42             ` Mcnamara, John
2017-08-03 22:57             ` Thomas Monjalon
2017-08-04  8:56               ` Ferruh Yigit
2017-08-04  9:32                 ` Thomas Monjalon
2017-08-04 10:04                   ` Ferruh Yigit
2017-08-04 10:10                     ` Thomas Monjalon
2017-08-04 11:11                   ` Mcnamara, John
2017-08-04 11:40                     ` Ferruh Yigit
2017-08-04 13:06             ` [PATCH v7] " Ferruh Yigit
2017-08-04 13:34               ` Mcnamara, John
2017-08-05  9:34               ` Thomas Monjalon

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=1f389cf5-ed5d-0768-ab91-76f458a0c219@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=john.mcnamara@intel.com \
    --cc=olivier.matz@6wind.com \
    --cc=thomas@monjalon.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.