Re: [dpdk-dev] [PATCH] mbuf: remove redundant line in rte_pktmbuf_attach

2017-01-21 Thread Ilya Matveychikov

> On Jan 20, 2017, at 4:08 PM, Ferruh Yigit  wrote:
> 
> On 1/20/2017 12:19 AM, Ilya Matveychikov wrote:
>> mi->next will be assigned to NULL few lines later, trivial patch
>> 
>> Signed-off-by: Ilya V. Matveychikov 
>> ---
>> lib/librte_mbuf/rte_mbuf.h | 1 -
>> 1 file changed, 1 deletion(-)
>> 
>> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
>> index ead7c6e..5589d54 100644
>> --- a/lib/librte_mbuf/rte_mbuf.h
>> +++ b/lib/librte_mbuf/rte_mbuf.h
>> @@ -1139,7 +1139,6 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf 
>> *mi, struct rte_mbuf *m)
>>  mi->buf_addr = m->buf_addr;
>>  mi->buf_len = m->buf_len;
>> 
>> -mi->next = m->next;
> 
> Do you know why attaching mbuf is not supporting multi-segment?
> Perhaps this can be documented in function comment, as one of the "not
> supported" items.

No, I don’t know. For my application I’ve found that nb_segs with it’s limit in 
256 segments is very annoying and I’ve decided not to use DPDK functions that 
dealt with nb_segs… But it is not about the rte_pktmbuf_attach() function and 
the patch.

> Also, should we check mi->next before overwriting, in case it is not NULL?
> 
>>  mi->data_off = m->data_off;
>>  mi->data_len = m->data_len;
>>  mi->port = m->port;
>> 
> 

I don’t know. It depends of the usage. Will someone needs to chain two chains 
of mbuf?

Re: [dpdk-dev] [PATCH] mbuf: remove redundant line in rte_pktmbuf_attach

2017-01-21 Thread Ananyev, Konstantin


> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ilya Matveychikov
> Sent: Saturday, January 21, 2017 3:08 PM
> To: Yigit, Ferruh 
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] mbuf: remove redundant line in 
> rte_pktmbuf_attach
> 
> 
> > On Jan 20, 2017, at 4:08 PM, Ferruh Yigit  wrote:
> >
> > On 1/20/2017 12:19 AM, Ilya Matveychikov wrote:
> >> mi->next will be assigned to NULL few lines later, trivial patch
> >>
> >> Signed-off-by: Ilya V. Matveychikov 
> >> ---
> >> lib/librte_mbuf/rte_mbuf.h | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> >> index ead7c6e..5589d54 100644
> >> --- a/lib/librte_mbuf/rte_mbuf.h
> >> +++ b/lib/librte_mbuf/rte_mbuf.h
> >> @@ -1139,7 +1139,6 @@ static inline void rte_pktmbuf_attach(struct 
> >> rte_mbuf *mi, struct rte_mbuf *m)
> >>mi->buf_addr = m->buf_addr;
> >>mi->buf_len = m->buf_len;
> >>
> >> -  mi->next = m->next;
> >
> > Do you know why attaching mbuf is not supporting multi-segment?

This is supported, but you have to do it segment by segment.
Actually  rte_pktmbuf_clone() does that.
Konstantin


> > Perhaps this can be documented in function comment, as one of the "not
> > supported" items.
> 
> No, I don’t know. For my application I’ve found that nb_segs with it’s limit 
> in 256 segments is very annoying and I’ve decided not to use
> DPDK functions that dealt with nb_segs… But it is not about the 
> rte_pktmbuf_attach() function and the patch.
> 
> > Also, should we check mi->next before overwriting, in case it is not NULL?
> >
> >>mi->data_off = m->data_off;
> >>mi->data_len = m->data_len;
> >>mi->port = m->port;
> >>
> >
> 
> I don’t know. It depends of the usage. Will someone needs to chain two chains 
> of mbuf?


Re: [dpdk-dev] [PATCH 01/15] eventdev: remove unneeded dependencies

2017-01-21 Thread Jerin Jacob
On Mon, Jan 16, 2017 at 03:40:41PM +, Harry van Haaren wrote:
> From: Bruce Richardson 
> 
> Since eventdev uses event structures rather than working directly on
> mbufs, there is no actual dependencies on the mbuf library. The
> inclusion of an mbuf pointer element inside the event itself does not
> require the inclusion of the mbuf header file. Similarly the pci
> header is not needed, but following their removal, rte_memory.h is
> needed for the definition of the __rte_cache_aligned macro.
> 
> Signed-off-by: Bruce Richardson 
> Signed-off-by: Harry van Haaren 

Acked-by: Jerin Jacob 

> ---
>  lib/librte_eventdev/Makefile   | 1 -
>  lib/librte_eventdev/rte_eventdev.h | 5 +++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/librte_eventdev/Makefile b/lib/librte_eventdev/Makefile
> index dac0663..396e5ec 100644
> --- a/lib/librte_eventdev/Makefile
> +++ b/lib/librte_eventdev/Makefile
> @@ -52,6 +52,5 @@ EXPORT_MAP := rte_eventdev_version.map
>  
>  # library dependencies
>  DEPDIRS-y += lib/librte_eal
> -DEPDIRS-y += lib/librte_mbuf
>  
>  include $(RTE_SDK)/mk/rte.lib.mk
> diff --git a/lib/librte_eventdev/rte_eventdev.h 
> b/lib/librte_eventdev/rte_eventdev.h
> index e1bd05f..c2f9310 100644
> --- a/lib/librte_eventdev/rte_eventdev.h
> +++ b/lib/librte_eventdev/rte_eventdev.h
> @@ -244,8 +244,9 @@ extern "C" {
>  #endif
>  
>  #include 
> -#include 
> -#include 
> +#include 
> +
> +struct rte_mbuf; /* we just use mbuf pointers; no need to include rte_mbuf.h 
> */
>  
>  /* Event device capability bitmap flags */
>  #define RTE_EVENT_DEV_CAP_QUEUE_QOS   (1ULL << 0)
> -- 
> 2.7.4
> 


Re: [dpdk-dev] [PATCH 00/15] next-eventdev: event/sw Software Eventdev

2017-01-21 Thread Jerin Jacob
On Mon, Jan 16, 2017 at 03:40:40PM +, Harry van Haaren wrote:
> The following patchset adds software eventdev implementation
> to the next-eventdev tree, and applies to current git HEAD.
> 
> This implementation is based on the previous software eventdev
> RFC patchset[1], updated to integrate with the latest rte_eventdev.h
> API.
> 
> The first two patches make changes to the eventdev API,
> then the software implementation is added, and finally
> tests are added for the sw eventdev implementation.
> 
> This patchset contains the work of multiple developers,
> please see signoffs on each patch.
> 
> Signed-off-by: Harry van Haaren 
> 
> [1] http://dpdk.org/ml/archives/dev/2016-November/050285.html
>

A few git-am, check-git-log.sh and checkpatches.sh errors in the patch
series.

1) [dpdk-next-eventdev-review] $ pwclient git-am 19436
Applying patch #19436 using 'git am'
Description: [dpdk-dev,03/15] event/sw: add new software-only eventdev
driver
Applying: event/sw: add new software-only eventdev driver
/export/dpdk-next-eventdev-review/.git/rebase-apply/patch:114: new blank
line at EOF.
+
warning: 1 line adds whitespace errors.

2) [dpdk-next-eventdev-review] $ ./devtools/check-git-log.sh
Wrong headline format:
event/sw: add start, stop and close functions

3) [dpdk-next-eventdev-review] $ ./devtools/checkpatches.sh *.patch

### [PATCH 03/12] event/sw: add support for event queues

ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#83: FILE: drivers/event/sw/iq_ring.h:60:
+#define force_inline inline __attribute__((always_inline))

ERROR:SPACING: spaces required around that '>' (ctx:OxW)
#163: FILE: drivers/event/sw/iq_ring.h:140:
+   for (i = nb_qes; i --> 0; )
 ^

WARNING:LONG_LINE_STRING: line over 80 characters
#257: FILE: drivers/event/sw/sw_evdev.c:90:
+   SW_LOG_DBG("invalid reorder_window_size for ordered 
queue\n");

WARNING:LONG_LINE_COMMENT: line over 80 characters
#454: FILE: drivers/event/sw/sw_evdev.h:116:
+   struct reorder_buffer_entry *reorder_buffer; /* packets awaiting 
reordering */

total: 2 errors, 2 warnings, 437 lines checked

### [PATCH 04/12] event/sw: add support for event ports

ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#89: FILE: drivers/event/sw/event_ring.h:65:
+#define force_inline inline __attribute__((always_inline))

WARNING:LONG_LINE: line over 80 characters
#235: FILE: drivers/event/sw/sw_evdev.c:65:
+   uint8_t enq_oversize = conf->enqueue_depth > 
info.max_event_port_enqueue_depth;

WARNING:LONG_LINE: line over 80 characters
#236: FILE: drivers/event/sw/sw_evdev.c:66:
+   uint8_t deq_oversize = conf->dequeue_depth > 
info.max_event_port_dequeue_depth;

WARNING:LONG_LINE_STRING: line over 80 characters
#244: FILE: drivers/event/sw/sw_evdev.c:74:
+   snprintf(buf, sizeof(buf), "sw%d_%s", dev->data->dev_id, 
"rx_worker_ring");

WARNING:LONG_LINE_STRING: line over 80 characters
#255: FILE: drivers/event/sw/sw_evdev.c:85:
+   snprintf(buf, sizeof(buf), "sw%d_%s", dev->data->dev_id, 
"cq_worker_ring");

WARNING:LONG_LINE_COMMENT: line over 80 characters
#309: FILE: drivers/event/sw/sw_evdev.h:53:
+#define SCHED_DEQUEUE_BURST_SIZE 32 /* how many packets pulled from port by 
sched */

WARNING:LONG_LINE_COMMENT: line over 80 characters
#360: FILE: drivers/event/sw/sw_evdev.h:169:
+   uint64_t avg_pkt_ticks;  /* tracks average over NUM_SAMPLES bursts 
*/

total: 1 errors, 6 warnings, 368 lines checked

### [PATCH 05/12] event/sw: add support for linking queues to ports

WARNING:LONG_LINE: line over 80 characters
#74: FILE: drivers/event/sw/sw_evdev.c:108:
+   q->cq_map[j] = q->cq_map[q->cq_num_mapped_cqs - 
1];

total: 0 errors, 1 warnings, 79 lines checked

### [PATCH 06/12] event/sw: add worker core functions

WARNING:LONG_LINE_COMMENT: line over 80 characters
#73: FILE: drivers/event/sw/sw_evdev.h:67:
+#define QE_FLAG_VALID(1 << QE_FLAG_VALID_SHIFT)  /* set for NEW, FWD, FRAG 
*/

WARNING:LONG_LINE: line over 80 characters
#191: FILE: drivers/event/sw/sw_evdev_worker.c:80:
+   int failed_to_get = 
rte_atomic32_dec_and_test(&sw->inflight_quanta);

WARNING:LONG_LINE: line over 80 characters
#217: FILE: drivers/event/sw/sw_evdev_worker.c:106:
+   uint64_t burst_pkt_ticks = burst_ticks / 
p->last_dequeue_burst_sz;

total: 0 errors, 3 warnings, 233 lines checked

### [PATCH 07/12] event/sw: add scheduling logic

WARNING:LONG_LINE_COMMENT: line over 80 characters
#156: FILE: drivers/event/sw/sw_evdev_scheduler.c:76:
+   /* use cheap bit mixing, since we only need to lose a few bits 
*/

WARNING:LONG_LINE: line over 80 characters
#170: FILE: drivers/event/sw/sw_evdev_scheduler.c:90:
+   for (cq_idx = 0; cq_idx < qid->cq_num_mapped_cqs; 
cq_idx++) {

WARNING:LONG_LINE: line over 80 characters
#174: FILE: drivers/event/sw/sw_evdev_sc

Re: [dpdk-dev] [PATCH 02/15] eventdev: add APIs for extended stats

2017-01-21 Thread Jerin Jacob
On Mon, Jan 16, 2017 at 03:40:42PM +, Harry van Haaren wrote:
> From: Bruce Richardson 
> 
> Add in APIs for extended stats so that eventdev implementations can report
> out information on their internal state. The APIs are based on, but not
> identical to, the equivalent ethdev functions.

Overall the xstat API looks good. I think, we need to extend the API to
support event port and event queue specific xstats too.

> 
> Signed-off-by: Bruce Richardson 
> Signed-off-by: Harry van Haaren 
> ---
>  lib/librte_eventdev/rte_eventdev.c   | 64 
>  lib/librte_eventdev/rte_eventdev.h   | 75 
> 
>  lib/librte_eventdev/rte_eventdev_pmd.h   | 58 +
>  lib/librte_eventdev/rte_eventdev_version.map |  3 ++
>  4 files changed, 200 insertions(+)
> 
> +
> +uint64_t
> +rte_event_dev_get_xstat_by_name(uint8_t dev_id, const char *name,
> + unsigned int *id)
> +{
> + const struct rte_eventdev *dev = &rte_eventdevs[dev_id];
> + unsigned int temp = -1;
> +
> + if (id != NULL)
> + *id = (unsigned int)-1;
> + else
> + id = &temp; /* ensure driver never gets a NULL value */
> +
> + RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, 0);
> +
> + /* implemented by driver */
> + if (dev->dev_ops->get_xstat_by_name != NULL)
> + return (*dev->dev_ops->get_xstat_by_name)(dev, name, id);
> + return 0;

Shouldn't we return -1 as per API specification?

> +}
> +
>  int
>  rte_event_dev_start(uint8_t dev_id)
>  {
> diff --git a/lib/librte_eventdev/rte_eventdev.h 
> b/lib/librte_eventdev/rte_eventdev.h
> index c2f9310..681cbfa 100644
> --- a/lib/librte_eventdev/rte_eventdev.h
> +++ b/lib/librte_eventdev/rte_eventdev.h
> @@ -1401,6 +1401,81 @@ rte_event_port_links_get(uint8_t dev_id, uint8_t 
> port_id,
>  int
>  rte_event_dev_dump(uint8_t dev_id, FILE *f);
>  
> +/** Maximum name length for extended statistics counters */
> +#define RTE_EVENT_DEV_XSTAT_NAME_SIZE 64
> +
> +/**
> + * A name-key lookup element for extended statistics.
> + *
> + * This structure is used to map between names and ID numbers
> + * for extended ethdev statistics.
> + */
> +struct rte_event_dev_xstat_name {
> + char name[RTE_EVENT_DEV_XSTAT_NAME_SIZE];
> +};
> +
> +/**
> + * Retrieve names of extended statistics of an event device.
> + *
> + * @param dev_id
> + *   The identifier of the event device.
> + * @param xstat_names
> + *  Block of memory to insert names into. Must be at least size in capacity.
> + *  If set to NULL, function returns required capacity.
> + * @param size
> + *  Capacity of xstat_names (number of names).
> + * @return
> + *   - positive value lower or equal to size: success. The return value
> + * is the number of entries filled in the stats table.
> + *   - positive value higher than size: error, the given statistics table
> + * is too small. The return value corresponds to the size that should
> + * be given to succeed. The entries in the table are not valid and
> + * shall not be used by the caller.
> + *   - negative value on error (invalid port id)

How about updating the rte_errno also in the failure case? It may useful
for application developer to have single check for error condition

> + */
> +int
> +rte_event_dev_get_xstat_names(uint8_t dev_id,
> + struct rte_event_dev_xstat_name *xstat_names,
> + unsigned int size);
> +
> +/**
> + * Retrieve extended statistics of an event device.
> + *
> + * @param dev_id
> + *   The identifier of the device.
> + * @param ids
> + *   The id numbers of the stats to get. The ids can be got from the stat
> + *   position in the stat list from rte_event_dev_get_xstat_names(), or
> + *   by using rte_eventdev_get_xstat_by_name()
> + * @param values

Please add [out] to indicate it is a output parameter
example: @param[out] values

> + *   The values for each stats request by ID.
> + * @param n
> + *   The number of stats requested
> + * @return
> + *   Number of stat entries filled into the values array
> + */
> +int
> +rte_event_dev_get_xstats(uint8_t dev_id, const unsigned int ids[],
> + uint64_t values[], unsigned int n);
> +
> +/**
> + * Retrieve the value of a single stat by requesting it by name.
> + *
> + * @param dev_id
> + *   The identifier of the device
> + * @param name
> + *   The stat name to retrieve
> + * @param id

Please add [out] to indicate it is output parameter

> + *   If non-NULL, the numerical id of the stat will be returned, so that 
> further
> + *   requests for the stat can be got using rte_eventdev_xstats_get, which 
> will

The function prototype is rte_event_dev_get_xstats. Change the
rte_eventdev_xstats_get to rte_event_dev_get_xstats in the above description

The rest of the file is following rte_eventdev_xxx_xxx_get syntax for
get functions. How about changing rte_eventdev_xxx_xxx_get syntax to
maintain the consistency?


> + *   be faster as it does

[dpdk-dev] Bug report: rte_table_hash_ext incorrectly compares signatures

2017-01-21 Thread Solal Pirelli
Hi,

I found a bug in the rte_table_hash_ext implementation, hopefully this
mailing list is the right place to report it.

It's pretty simple: in `rte_table_hash_ext.c` (using `add` as an example;
the bug is also elsewhere):
- line 53 declares the bucket signatures as arrays of `uint16_t`
- line 280 computes the key signature, an `uint64_t`
- line 283 shifts the signature by 16 bits to the right, resulting in a
"48-bit" number
- like 293 then compares the bucket signature (16 bits) to the shifted key
signature (48 bits).

Thus, rte_table_hash_ext only works if hashes have their upper 32 bits
unset.

I created a tiny repro:
https://github.com/SolalPirelli/dpdk-table-hash-ext-bug
It tries to insert then retrieve the same key/value pair, with specific
bits set in the hash; as can be seen from the output, the map works fine
when only one of the lower 32 bits is set, but stops working if one of the
upper 32 bits is.

The workaround is simple: the hash function should always clear the upper
32 bits of its output.

(I unfortunately don't have the time right now to provide a properly-tested
patch, sorry)


Cheers,
Solal Pirelli


Re: [dpdk-dev] [PATCH v4 8/8] doc: add guide to use virtio_user as exceptional path

2017-01-21 Thread Aws Ismail
On Jan 13, 2017 9:42 AM, "Jianfeng Tan"  wrote:

Signed-off-by: Jianfeng Tan 
---
 .../img/virtio_user_as_excpetional_path.png| Bin 0 -> 38600 bytes
 doc/guides/prog_guide/index.rst|   1 +
 .../prog_guide/virtio_user_as_exceptional_path.rst | 104
+
 3 files changed, 105 insertions(+)
 create mode 100644 doc/guides/prog_guide/img/virtio_user_as_excpetional_
path.png
 create mode 100644 doc/guides/prog_guide/virtio_
user_as_exceptional_path.rst

diff --git a/doc/guides/prog_guide/img/virtio_user_as_excpetional_path.png
b/doc/guides/prog_guide/img/virtio_user_as_excpetional_path.png
new file mode 100644
index ..
9fd45e13eefc2ef39ac2c389f407d60ab4144c59
GIT binary patch
literal 38600
zcmeFZdpy(qA2&W76`>TJkPbu+9mM6hkRnDo=QL5tVO(L(+mv$(Q4t~M97nNb*gBA;
znuUfnD`#ee88+K~AL_cUuIqcae~0`2J?=m5KN9o#ybrJA^Ywha-xAK7pWU)~_ht|X
zw8g~uv?U0%&Hw~j(=50F_(Yg*vi-TI8vT#u~x5|-Ak&q(l2h%zHLE{W-)EUd$ev#N^M`@`f-z!0zOOqRz4}dL?_;qa&t8o(
z5M2EzW6NgQ)o)zY{}(*;+u^)FCcKo~EUC{rw>lRH^QkS>`=GlNYJ>
zT&CZ=vYC1EeP6>z?}rknnDq`~D{mg%$_^D*-`YW3ev*$(p=2M}%{5hgSA*T}slTpA
zjfMMqVm)GNtm9PztX#qxcphYSI&0xAhthhI9lGOi`>peAiCwOpi{y>%+k3K==#BT!
z($2Y4%48m_xRC4qK#*V5(xRg{Q#FUz#Mkodz_vbC;_!G{O2q8U9Y&QW>>es-e
z>%qd|;BiM7Q~3gfHhW?IWFDJ8qt}JqGZtFZ&Itc_*f~~O+?jWB8&#Ce5387e{w9}E
zJ!O|UajbLhTzYvs*}a(a#Mjw*SVvVoAv;$u%ba+`+nY*RQ$AMjMnrSYdFy)AMwYf-
zgr1$RGa-8D_R~AaM>(<53{jjJqczM0zU0N|vfD@}GM$*CSII%F-u^{6b&RSJc02GP
zo9%|~?z2Vs(EJoWskfrtKQGMJDb+#C`}$5pb0_ED_s>3|SYxZI{Id@L;&MDPFC8i+
zOo_HCh^o_D3z1qJKmF-}-42)`B>^vDJ+GfEB6fS}7LFo$|g7w2$ia
zZj;A3XORzWNbvEY@^aaaiICL32auA{+jVsx4(g6@PIuD_%(b}Qo_i5@yeJyAgkHM6
zGgHTVE{rjKjWlP)(JuqHwhU?^u;kBZ?uGHXClCT@6s~N1xGCtG{((B`^;$-sv^yA!
zQ75tLG?BZhabae-cZeilt3Jv{HrSK)NeesXU2@hs`s~WZz?2ekCr-J&j$n6!kCc=#
z#eE*_!m>MgM}>&IiW=@>QKsv3*>=Y`*eXX#9=LOi&sme8Qc@|4u~}kO9qGU7jGih9
z>2Nx^32Sge&u(J}GMCe^J5ZOEZp>-YMYl(vOCQcflQ3S|fl^v2$?{IP2_%U0!_?cKX38hZ}n84n<%$?aOGLs-4MQPeHG`4X?F)rm+CaYG|Yr%u{(
zvU2=*n!9!Vm?9e>%N%v?hg?qB#yHc6Q$7yv8K+pvlnP&VJNrdrllQy{g1_O?m8!
z*VOfTbS@1-;mGb9@;0vDEopB@yo8jFuHU2%nOvoK{gMOO=45C$>^q{Ql+ZFt(8Ciw
z#OA3keB6}K_P)3Y_LVPwecSz*@Ymq8oTn-!xA0Xx*E`5y-3_cSI7BgrCK<=%!)ew{
z8^(z93%m^Pyuyzuqd@L@Vf#too{UZ}-edOKpO*O)$k=9b#+h8Oyv|a7hfS;=uyI%kvA8qf0;P1cU8}-k
z?6hu6k~_88iC9#Y@FYhFxsA#?*-Pl}p2sel-@zH2+JnGqAf3t0>+dV#(32rv6a8}H
z({_y4koAxvF1czG{`>hl8ep#>cYMRM<_|L#c=a}ZX}j2afk@hOj)!)Tkor0=B}RYz
z;Xz51yHrJ8QOm9@SL-cLxCd=16t$OKFKcyOI)gZY=RJv~nJFSomG5}|rEACGi`?#@
zeN*GSx>4_1!B22a9y-M)3J(5_Y;uYWUrb0Tp1}AMa^M)F@tIGfwmZ(BdnB3FjOq61
z>|JM>Y+;AD7|Rw@2ofeUusq*S0?1FCq6Dc?Yv^qM?ZgKi7#7bYo`N-^icB
zeO>SdM#X!U;?x%#HaAqA9ruT8GndQ4xI2Gt<@$|NRtt7a%%p0RmaC7VW#QPVzP_}~
zLbeIK6ZZNY?J4yNCot8USdQxs8H05TRC8VAH`BkT%~nNS8D5AIc~7pt-)CW&$-7xK
z?jILRN{G^hTGdrza^P5_lRGR{baSV!+aqmUuP&%+E_0M~+U63GrrR;UlRa#=!(n2K
zT|uycJ`j4j+;o_8}?pG5!1cb&y-A56;1k)>Nd@_0@272;BQr
z;OxW){AJE|KxsKd8=rV`vRHuNGVJ<~e9$Ci);=X;HAY-H1_
zj5bh%ybZHnS?y?Q&`-}3FV4t)T+yI
zew^NG-;y2GyR3CU4>@88q0cbg+fN8o1ud!NZ2
z0#b!LY`*t0{<|&w>{%(4iXG(1{N4q04O^?LSd?Bv4mg|JIqJKnAwWNU#~g)L@_f9q
zq3Mkand9^9DcwFIJ&Mp^&Kbik`v-=**MGJuY5uX+ic_xZ*K>t%TdJ4@=c$~dJk?pv
zZK9vx)i8p$HpnUX#h9O;Io0_n6Qjt-FX^pcQzY(1kpytg?^&;6A(I^5a1Vcnt_vFC
z(kFo}Q`<5L(=FX(rn0i$G_M7@xnR{oc91wixn`8S!)`v9SCd&hIG(t@e%k_8J-D{Q
zJ)2>}gCnT>8%bmZ=cNAo-^S^=l?BsOS9mUED3PqWP-!=?>W&WT3am5(uzi<_JDD=e
zsIT9~ulr2<)IXxE!&9X@%irUv-0Ip#LZ%-nC74kt=}h~f#~h+X7rY)41<$f)B4p}!
zD5%ZwYIB2?ZCfg?6;LwV=q3#R%KS&DpI|L8}JD=igChChc`43Q>3S
zM)CNR42ND~p2Pl*{Sc0XvYI$A`?GQtpA0!!+_xNUDV_=5eNp`)MO({q*--|!eJb$g
zbYe9br_q~k4=?sPzKHuUU7re!eoZP5?q
z-w*uizP7Xr_6qs9D5_U|?OCvXhsjql9Ivi&yedh{R>`=@xu6-N$Z4Mw%bh?6@9tS=
z%g@UEo#XhK({FTX{r%@p3h32A%-(d|UXJ(g-TwX+CFZ4bZk_f5?>;Rkn;Xu_TG-78_rxPAOlehvkZHWVOoS)5_>|1-A&^$GdF_
zIeJFfT8BOYRbgahVbtk8#x_)iZyT$%u0LUW=Xi)OsGt-W1{*(pE>>sEU?YRC_-!i9
zR1yZ_Z(sj{?`=i=`FojNdDx<4S6v6
zqv}UpJYKm6AGL-^#P-`lqj$~*?Dx^OY9)(4hi`lKF=!&dC$*y8m>TNVT1u>B+YWVD
zLqvRZ>At3W409#Nh`C3clkVm;giSGZ<=7`LBF~KNRa)~1#~a=mn2!@
zswG^BdZLcHLB8>bdaklG>&rOk;{)oI>e8s=9MdrBECXEw9^DJi7Kis=(C;k
zCYd%?a{A4+LSM_F)!t-mi
zE^?qQxO}r0?_&av9E*Ct9cfL%Msrbx2L=shpzvvFsh!T0TJY+3@xAbMMh#cb>
zOzxIeNL_1iQ~L`)L+a&APhd89!5WbUQ-fs3?wL=UZdV?dPj|@5pda@M4VzM9@I(Cb
ziJqCliv(*rzCye8o-~w()COnuZx|*Qcv=aQOwfeHQ)HWkMpX}V@(rB3+E1t*SUt4S
z0=7grHST&&{+>->J+rQT>A`nBbP6RD>ixhNuWYk?_?W#
zP+kub)ecl7z5B49ZqP%>hIkcXU(pQeTZLkL@48d`@<~Hch9*u#S2Zw{4dr50$QI_z
zdYGKRJHnka1?`{QzbzD1on5G>rQ@7Ge^y69k{0gxCekz{vJa0|8vGDOgM%80e8jm}8b#A!(rg9>G9<(+2;KPC+p)8n!AWxws{d=;mvevQL~pH0TP
zoM0|sq-hIqM4uif*jd)Pg-(KfLilms`a%9v07(=q7IYFPYfXw1eb0+
z7TE`{wlUiH04et69*z=u9~#^V-F&}_CJnW#H6h(7)w9_605;Tbdu6R%c1UHrWMEl7
z#op#g^`?Y6eac>o@AQ054ZYB1;|xo3sCew)sg3M+ePwhXL$bJqUS_^gBF0GSWOL|^
zh=Es*R?I~WDH&ZF;$^iWu0qb4lf}v^-k%MbnkQ&7sV>lzrx-dtoPsZ>|&#{Y<#
zg5ZyPt^$zys-s_)e!jT@V+Mi+x7I?~jhHmA`vH#kC1h&1ApD@81sYV2bj!gkZ1M~i
z9_p&}i)zh0aVQq4ou7f-vazX!;BJ>8O6i|X5^CBqipN#!av;{s(9-#9%;)3KEcz`Z
z+&@?Ht!c7%cfAj(p%j-x)OrYkjLdsDLxbn*%qSTSIcHEMqlhfBk+SjFQVu665{|Va
zBEl=C-TO-B>(E|Vbzr!{&cYsVcP}ZnRx$UpOfYK8gg=CIWlVEux<9_4y^CC1Mjn*Y
zT#03%%f)LA8V)`8zV7Cw4s(R(!x)|?##zB4dqn
zA^1qw#^N_gcbbgkT9=C3s|T~)w@q-qbZ{?8Ib-

[dpdk-dev] [PATCH v4] doc: add known uio_pci_generic issue for i40e

2017-01-21 Thread Jeff Guo
When bind the "uio_pci_generic" module in X710/XL710/XXV710,
the result is failed. The "uio_pci_generic" module is not
supported by X710/XL710/XXV710.

Signed-off-by: Jeff Guo 
Acked-by: Jingjing Wu 
---
v4: modify the signed-off name to be consistent, fix quotes and make doc issue.
v3: add related linux kernel commit info and fix some syntax issues
v2: add X710/XXV710 limitation case
---
 doc/guides/rel_notes/known_issues.rst | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/doc/guides/rel_notes/known_issues.rst 
b/doc/guides/rel_notes/known_issues.rst
index 3cd4237..ef43d01 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -640,3 +640,29 @@ I40e VF may not receive packets in the promiscuous mode
 
 **Driver/Module**:
Poll Mode Driver (PMD).
+
+
+The uio_pci_generic module bind failed in X710/XL710/XXV710
+---
+
+**Description**:
+   The "uio_pci_generic" module is not supported by XL710, since the errata of 
XL710
+   states that the Interrupt Status bit is not implemented. The errata is the 
item #71
+   from the `xl710 controller spec
+   
`_.
+   The hw limitation is the same as other X710/XXV710 NICs.
+
+**Implication**:
+   When use "--bind=uio_pci_generic", the "uio_pci_generic" module probes 
device and check the Interrupt
+   Status bit. Since it is not supported by X710/XL710/XXV710, it return a 
*failed* value. The statement
+   that these products don’t support INTx masking, is indicated in the related 
`linux kernel commit
+   
`_.
+
+**Resolution/Workaround**:
+   Do not bind the "uio_pci_generic" module in X710/XL710/XXV710 NICs.
+
+**Affected Environment/Platform**:
+   All.
+
+**Driver/Module**:
+   Poll Mode Driver (PMD).
-- 
2.7.4



[dpdk-dev] [PATCH] mk: parallelize make config

2017-01-21 Thread Ferruh Yigit
make config dependency resolving was always running serial,
parallelize it for better performance.

$ time make T=x86_64-native-linuxapp-gcc config
real0m12.633s

$ time make -j8 T=x86_64-native-linuxapp-gcc config
real0m1.826s

Signed-off-by: Ferruh Yigit 
---
 mk/internal/rte.depdirs-post.mk | 11 ++-
 mk/rte.sdkdepdirs.mk| 21 -
 mk/rte.subdir.mk| 15 +++
 3 files changed, 25 insertions(+), 22 deletions(-)

diff --git a/mk/internal/rte.depdirs-post.mk b/mk/internal/rte.depdirs-post.mk
index 102a369..eb73ad3 100644
--- a/mk/internal/rte.depdirs-post.mk
+++ b/mk/internal/rte.depdirs-post.mk
@@ -29,11 +29,12 @@
 #   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 #   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
-.PHONY: depdirs
-depdirs:
-   @for d in $(DEPDIRS-y); do \
-   $(RTE_SDK)/buildtools/depdirs-rule.sh $(S) $$d ; \
-   done
+.PHONY: depdirs $(DEPDIRS-y)
+depdirs: $(DEPDIRS-y)
+   @echo ""
+
+$(DEPDIRS-y):
+   @$(RTE_SDK)/buildtools/depdirs-rule.sh $(S) $@
 
 .PHONY: depgraph
 depgraph:
diff --git a/mk/rte.sdkdepdirs.mk b/mk/rte.sdkdepdirs.mk
index bebaf2a..daf42eb 100644
--- a/mk/rte.sdkdepdirs.mk
+++ b/mk/rte.sdkdepdirs.mk
@@ -36,19 +36,22 @@ ifeq (,$(wildcard $(RTE_OUTPUT)/Makefile))
   $(error "need a make config first")
 endif
 
+DEPDIRS = $(addsuffix /.depdirs, $(addprefix $(BUILDDIR)/,$(ROOTDIRS-y)))
+
 # use a "for" in a shell to process dependencies: we don't want this
 # task to be run in parallel.
 .PHONY: depdirs
 depdirs: $(RTE_OUTPUT)/.depdirs
-$(RTE_OUTPUT)/.depdirs: $(RTE_OUTPUT)/.config
-   @rm -f $(RTE_OUTPUT)/.depdirs ; \
-   for d in $(ROOTDIRS-y); do \
-   if [ -f $(RTE_SRCDIR)/$$d/Makefile ]; then \
-   [ -d $(BUILDDIR)/$$d ] || mkdir -p $(BUILDDIR)/$$d ; \
-   $(MAKE) S=$$d -f $(RTE_SRCDIR)/$$d/Makefile depdirs \
-   >> $(RTE_OUTPUT)/.depdirs ; \
-   fi ; \
-   done
+$(RTE_OUTPUT)/.depdirs: $(DEPDIRS)
+   @rm -f $@
+   @for f in $(DEPDIRS); do cat $$f >> $@; done
+   @sort -u -o $@ $@
+
+$(DEPDIRS): $(RTE_OUTPUT)/.config
+   @f=$(lastword $(subst /, ,$(dir $@))); \
+   [ -d $(BUILDDIR)/$$f ] || mkdir -p $(BUILDDIR)/$$f; \
+   rm -f $@; \
+   $(MAKE) S=$$f -f $(RTE_SRCDIR)/$$f/Makefile depdirs >> $@
 
 .PHONY: depgraph
 depgraph:
diff --git a/mk/rte.subdir.mk b/mk/rte.subdir.mk
index 256e64e..3bb3019 100644
--- a/mk/rte.subdir.mk
+++ b/mk/rte.subdir.mk
@@ -76,7 +76,7 @@ clean: _postclean
 # include .depdirs and define rules to order priorities between build
 # of directories.
 #
-include $(RTE_OUTPUT)/.depdirs
+-include $(RTE_OUTPUT)/.depdirs
 
 define depdirs_rule
 $(1): $(sort $(patsubst $(S)/%,%,$(LOCAL_DEPDIRS-$(S)/$(1
@@ -84,16 +84,15 @@ endef
 
 $(foreach d,$(DIRS-y),$(eval $(call depdirs_rule,$(d
 
+DEPDIRS = $(wildcard $(addprefix $(S)/,$(DIRS-y)))
 
 # use a "for" in a shell to process dependencies: we don't want this
 # task to be run in parallel.
-.PHONY: depdirs
-depdirs:
-   @for d in $(DIRS-y); do \
-   if [ -f $(SRCDIR)/$$d/Makefile ]; then \
-   $(MAKE) S=$S/$$d -f $(SRCDIR)/$$d/Makefile depdirs ; \
-   fi ; \
-   done
+.PHONY: depdirs $(DEPDIRS)
+depdirs: $(DEPDIRS)
+
+$(DEPDIRS):
+   @$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile depdirs
 
 .PHONY: depgraph
 depgraph:
-- 
2.9.3



[dpdk-dev] [PATCH v4] doc: add known uio_pci_generic issue for i40e

2017-01-21 Thread Jeff Guo
When bind the ``uio_pci_generic`` module in X710/XL710/XXV710,
the result is failed. The ``uio_pci_generic`` module is not
supported by X710/XL710/XXV710.

Signed-off-by: Jeff Guo 
Acked-by: Jingjing Wu 
---
v4: modify the signed-off name to be consistent and fix make doc issue.
v3: add related linux kernel commit info and fix some syntax issues
v2: add X710/XXV710 limitation case
---
 doc/guides/rel_notes/known_issues.rst | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/doc/guides/rel_notes/known_issues.rst 
b/doc/guides/rel_notes/known_issues.rst
index 3cd4237..018e999 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -640,3 +640,29 @@ I40e VF may not receive packets in the promiscuous mode
 
 **Driver/Module**:
Poll Mode Driver (PMD).
+
+
+uio pci generic module bind failed in X710/XL710/XXV710
+---
+
+**Description**:
+   The ``uio_pci_generic`` module is not supported by XL710, since the errata 
of XL710
+   states that the Interrupt Status bit is not implemented. The errata is the 
item #71
+   from the `xl710 controller spec
+   
`_.
+   The hw limitation is the same as other X710/XXV710 NICs.
+
+**Implication**:
+   When use ``--bind=uio_pci_generic``, the ``uio_pci_generic`` module probes 
device and check the Interrupt
+   Status bit. Since it is not supported by X710/XL710/XXV710, it return a 
*failed* value. The statement
+   that these products don’t support INTx masking, is indicated in the related 
`linux kernel commit
+   
`_.
+
+**Resolution/Workaround**:
+   Do not bind the ``uio_pci_generic`` module in X710/XL710/XXV710 NICs.
+
+**Affected Environment/Platform**:
+   All.
+
+**Driver/Module**:
+   Poll Mode Driver (PMD).
-- 
2.7.4



Re: [dpdk-dev] [PATCH] ethdev: fix wrong memset

2017-01-21 Thread Yuanhan Liu
On Fri, Jan 20, 2017 at 03:27:43PM +, Ferruh Yigit wrote:
> On 1/20/2017 11:21 AM, Ferruh Yigit wrote:
> > On 1/20/2017 8:04 AM, Yuanhan Liu wrote:
> >> Fix an silly error by auto-complete while managing the merge conflicts.
> >> It's the eth_dev_data (but not eth_dev) entry should be memset.
> >>
> >> Fixes: d948f596fee2 ("ethdev: fix port data mismatched in multiple process 
> >> model")
> >>
> >> Reported-by: Ferruh Yigit 
> >> Signed-off-by: Yuanhan Liu 
> >> ---
> >>  lib/librte_ether/rte_ethdev.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> >> index 4790faf..61f44e2 100644
> >> --- a/lib/librte_ether/rte_ethdev.c
> >> +++ b/lib/librte_ether/rte_ethdev.c
> >> @@ -225,7 +225,7 @@ struct rte_eth_dev *
> >>return NULL;
> >>}
> >>  
> >> -  memset(&rte_eth_devices[port_id], 0, sizeof(*eth_dev->data));
> >> +  memset(&rte_eth_dev_data[port_id], 0, sizeof(struct rte_eth_dev_data));
> > 
> > Not directly related to the this issue, but, after fix, this may have
> > issues with secondary process.
> > 
> > There were patches sent to fix this.
> 
> I mean this one:
> http://dpdk.org/ml/archives/dev/2017-January/054422.html

d948f596fee2 ("ethdev: fix port data mismatched in multiple process
model") should have fixed it.

--yliu


Re: [dpdk-dev] [PATCH v3 2/3] net/e1000: e1000 igb support to free consumed buffers

2017-01-21 Thread Lu, Wenzhuo
Hi Billy,

> -Original Message-
> From: Billy McFall [mailto:bmcf...@redhat.com]
> Sent: Saturday, January 21, 2017 12:01 AM
> To: thomas.monja...@6wind.com; Lu, Wenzhuo
> Cc: dev@dpdk.org; Billy McFall
> Subject: [PATCH v3 2/3] net/e1000: e1000 igb support to free consumed
> buffers
> 
> Add support to the e1000 igb driver for the new API to force free consumed
> buffers on Tx ring. e1000 igb driver does not implement a tx_rs_thresh to free
> mbufs, it frees a slot in the ring as needed, so a new function needed to be
> written.
> 
> Signed-off-by: Billy McFall 
> ---
>  drivers/net/e1000/e1000_ethdev.h |   2 +
>  drivers/net/e1000/igb_ethdev.c   |   1 +
>  drivers/net/e1000/igb_rxtx.c | 126
> +++
>  3 files changed, 129 insertions(+)
> 
> diff --git a/drivers/net/e1000/e1000_ethdev.h
> b/drivers/net/e1000/e1000_ethdev.h
> index 81a6dbb..39b2f43 100644
> --- a/drivers/net/e1000/e1000_ethdev.h
> +++ b/drivers/net/e1000/e1000_ethdev.h
> @@ -315,6 +315,8 @@ int eth_igb_tx_queue_setup(struct rte_eth_dev *dev,
> uint16_t tx_queue_id,
>   uint16_t nb_tx_desc, unsigned int socket_id,
>   const struct rte_eth_txconf *tx_conf);
> 
> +int eth_igb_tx_done_cleanup(void *txq, uint32_t free_cnt);
> +
>  int eth_igb_rx_init(struct rte_eth_dev *dev);
> 
>  void eth_igb_tx_init(struct rte_eth_dev *dev); diff --git
> a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c index
> 8843dd1..12a1a30 100644
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -408,6 +408,7 @@ static const struct eth_dev_ops eth_igb_ops = {
>   .rx_descriptor_done   = eth_igb_rx_descriptor_done,
>   .tx_queue_setup   = eth_igb_tx_queue_setup,
>   .tx_queue_release = eth_igb_tx_queue_release,
> + .tx_done_cleanup  = eth_igb_tx_done_cleanup,
>   .dev_led_on   = eth_igb_led_on,
>   .dev_led_off  = eth_igb_led_off,
>   .flow_ctrl_get= eth_igb_flow_ctrl_get,
> diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c index
> 45f3f24..00cd2aa 100644
> --- a/drivers/net/e1000/igb_rxtx.c
> +++ b/drivers/net/e1000/igb_rxtx.c
> @@ -1277,6 +1277,132 @@ eth_igb_tx_queue_release(void *txq)
>   igb_tx_queue_release(txq);
>  }
> 
> +static int
> +igb_tx_done_cleanup(struct igb_tx_queue *txq, uint32_t free_cnt) {
> + struct igb_tx_entry *sw_ring;
> + volatile union e1000_adv_tx_desc *txr;
> + uint16_t tx_first; /* First segment analyzed. */
> + uint16_t tx_id;/* Current segment being processed. */
> + uint16_t tx_last;  /* Last segment in the current packet. */
> + uint16_t tx_next;  /* First segment of the next packet. */
> + int count;
> +
> + if (txq != NULL) {
> + count = 0;
> + sw_ring = txq->sw_ring;
> + txr = txq->tx_ring;
> +
> + /*
> +  * tx_tail is the last sent packet on the sw_ring. Goto the end
> +  * of that packet (the last segment in the packet chain) and
> +  * then the next segment will be the start of the oldest
> segment
> +  * in the sw_ring. This is the first packet that will be
> +  * attempted to be freed.
> +  */
> +
> + /* Get last segment in most recently added packet. */
> + tx_first = sw_ring[txq->tx_tail].last_id;
> +
> + /* Get the next segment, which is the oldest segment in ring.
> */
> + tx_first = sw_ring[tx_first].next_id;
> +
> + /* Set the current index to the first. */
> + tx_id = tx_first;
> +
> + /*
> +  * Loop through each packet. For each packet, verify that an
> +  * mbuf exists and that the last segment is free. If so, free
> +  * it and move on.
> +  */
> + while (1) {
> + tx_last = sw_ring[tx_id].last_id;
> +
> + if (sw_ring[tx_last].mbuf) {
> + if (txr[tx_last].wb.status &
> + E1000_TXD_STAT_DD) {
> + /*
> +  * Increment the number of packets
> +  * freed.
> +  */
> + count++;
> +
> + /* Get the start of the next packet. */
> + tx_next = sw_ring[tx_last].next_id;
> +
> + /*
> +  * Loop through all segments in a
> +  * packet.
> +  */
> + do {
> +
>   rte_pktmbuf_free_seg(sw_ring[tx_id].mbuf);
> + sw_ring[tx_id].mbuf = NULL;
> +

Re: [dpdk-dev] [PATCH v4 8/8] doc: add guide to use virtio_user as exceptional path

2017-01-21 Thread Tan, Jianfeng



On 1/22/2017 8:46 AM, Aws Ismail wrote:



On Jan 13, 2017 9:42 AM, "Jianfeng Tan" > wrote:


Signed-off-by: Jianfeng Tan mailto:jianfeng@intel.com>>
---
 .../img/virtio_user_as_excpetional_path.png| Bin 0 ->
38600 bytes
 doc/guides/prog_guide/index.rst |   1 +
 .../prog_guide/virtio_user_as_exceptional_path.rst | 104
+
 3 files changed, 105 insertions(+)
 create mode 100644
doc/guides/prog_guide/img/virtio_user_as_excpetional_path.png
 create mode 100644
doc/guides/prog_guide/virtio_user_as_exceptional_path.rst

[...]
+Sample Usage
+
+
+As a prerequisite, the vhost/vhost-net kernel CONFIG should be
chosen before compiling the kernel and those kernel modules should
be inserted.
+
+#.  Compile the DPDK and bind a physical NIC (for communicating
with outside) to igb_uio/uio_pci_generic/vfio-pci.
+
+#.  Run testpmd:
+
+.. code-block:: console
+
+examples/kni/build/app/kni -c -0xf0 -n 4 -- -p 0x3 -P
--config="(0,4,6),(1,5,7)"


Is this correct? The section says "run testpmd" but the first thing 
you are doing here is run the KNI example app.


Oops, forget to delete this line.

Thanks,
Jianfeng