[dpdk-dev] [PATCH v2] mbuf: optimize rte_mbuf_refcnt_update

2015-12-27 Thread Hanoch Haim (hhaim) 
Hi Bruce,

I'm Hanoch from Cisco Systems works for  the 
https://github.com/cisco-system-traffic-generator/trex-core traffic generator 
project.

While upgrading from DPDK 1.8 to 2.2 Ido found that the following commit 
creates a mbuf corruption and result in Tx hang



commit f20b50b946da9070d21e392e4dbc7d9f68bc983e

Author: Olivier Matz 

Date:   Mon Jun 8 16:57:22 2015 +0200



Looking at the change it is clear why there is an issue, wanted to get your 
input.



Init

-

alloc const mbuf  ==> mbuf-a (ref=1)



Simple case that works

-



thread 1 , tx: alloc-mbuf->attach(mbuf-a) (ref=2)  inc- non atomic

thread 1 , tx: alloc-mbuf->attach(mbuf-a) (ref32)  inc- atomic

thread 1 , drv : free()(ref=2) dec- atomic

thread 1 , drv : free()(ref=3) dec - non atomic





Simple case that does not work

-



Both do that in parallel



thread 2 tx : alloc-mbuf->attach(mbuf-a)  (ref=2)  inc- non atomic

thread 1 tx : alloc-mbuf->attach(mbuf-a)  (ref=2)  inc- non atomic



  ==> ref in corrupted



thread 1 drv : free()(ref=0)   - free

thread 1 drv : free()(ref=-1)  - ???





Just as a side note that in our case we could benefit from this optimization by 
making a small change in our code, as our common case could be alloc/free of 
simple mbuf and in such scenario there is no atomic operation in both cases. 
But I think the general case is broken.



Could you explain what was your use case or this optimization? Is it a valid 
example the aforementioned example



thanks,

Hanoh

Cisco Systems







On Mon, Jun 08, 2015 at 04:57:22PM +0200, Olivier Matz wrote:

> In __rte_pktmbuf_prefree_seg(), there was an optimization to avoid using

> a costly atomic operation when updating the mbuf reference counter if

> its value is 1. Indeed, it means that we are the only owner of the mbuf,

> and therefore nobody can change it at the same time.

>

> We can generalize this optimization directly in rte_mbuf_refcnt_update()

> so the other callers of this function, like rte_pktmbuf_attach(), can

> also take advantage of this optimization.

>

> Signed-off-by: Olivier Matz  6wind.com>



Acked-by: Bruce Richardson http://dpdk.org/ml/listinfo/dev>>


Hanoh

[dpdk-dev] Errors Rx count increasing while pktgen doing nothing on Intel 82598EB 10G

2015-12-27 Thread Laurent GUERBY 
Hi,

I reported today an issue when using Pktgen-DPDK:
https://github.com/pktgen/Pktgen-DPDK/issues/52

But I think it's more in DPDK than pktgen

two identical machines with SFP+ DA cable between them
DPDK 2.2.0 from tarball
Pktgen-DPDK from git
two identical machines:
core i7 2600 (sandy bridge 4C/8T), HT disabled in the BIOS
ASUS P8H67-M PRO BIOS 3904 (latest available)
Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF Dual Port
Network Connection (rev 01)
01:00.0 0200: 8086:10f1 (rev 01)
Subsystem: 8086:a21f
boot kernel 3.16 unbutu 14.04 with isolcpus=2,3,4

When launching pktgen even with no TX asked the Errors RX counters keeps
going up by about 7.4 millions per second:

Errors Rx/Tx : 7471857054/0

In the log I get "Could not enable Rx Queue", might be the
source of the issue?

PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 0
PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 1

When sending traffic  single UDP src/dst/IP/MAC the setup
reaches 14204188 pps 64 bytes, the error counter is also
increasing.

Any idea what to look for?

Laurent

[dpdk-dev] Errors Rx count increasing while pktgen doing nothing on Intel 82598EB 10G

2015-12-27 Thread Wiles, Keith 
On 12/27/15, 12:31 PM, "dev on behalf of Laurent GUERBY"  wrote:

>Hi,
>
>I reported today an issue when using Pktgen-DPDK:
>https://github.com/pktgen/Pktgen-DPDK/issues/52
>
>But I think it's more in DPDK than pktgen
>
>two identical machines with SFP+ DA cable between them
>DPDK 2.2.0 from tarball
>Pktgen-DPDK from git
>two identical machines:
>core i7 2600 (sandy bridge 4C/8T), HT disabled in the BIOS
>ASUS P8H67-M PRO BIOS 3904 (latest available)
>Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF Dual Port
>Network Connection (rev 01)
>01:00.0 0200: 8086:10f1 (rev 01)
>   Subsystem: 8086:a21f
>boot kernel 3.16 unbutu 14.04 with isolcpus=2,3,4
>
>When launching pktgen even with no TX asked the Errors RX counters keeps
>going up by about 7.4 millions per second:
>
>Errors Rx/Tx : 7471857054/0
>
>In the log I get "Could not enable Rx Queue", might be the
>source of the issue?
>
>PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 0
>PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 1
>
>When sending traffic  single UDP src/dst/IP/MAC the setup
>reaches 14204188 pps 64 bytes, the error counter is also
>increasing.
>
>Any idea what to look for?

One more suggestion is to run test_pmd on one machine and something like iperf 
on the other to verify the DPDK is working correct, which I assume will be 
true. Not sure the RX errors are reported in the test_pmd or you could use the 
l3fwd application too.

Please also send me the 'lspci | grep Ethernet? output.
Also send me the command line.

>
>Laurent
>
>


Regards,
Keith

[dpdk-dev] Errors Rx count increasing while pktgen doing nothing on Intel 82598EB 10G

2015-12-27 Thread Laurent GUERBY 
On Sun, 2015-12-27 at 19:43 +, Wiles, Keith wrote:
> On 12/27/15, 12:31 PM, "dev on behalf of Laurent GUERBY"  dpdk.org on behalf of laurent at guerby.net> wrote:
> 
> >Hi,
> >
> >I reported today an issue when using Pktgen-DPDK:
> >https://github.com/pktgen/Pktgen-DPDK/issues/52
> >
> >But I think it's more in DPDK than pktgen
> >
> >two identical machines with SFP+ DA cable between them
> >DPDK 2.2.0 from tarball
> >Pktgen-DPDK from git
> >two identical machines:
> >core i7 2600 (sandy bridge 4C/8T), HT disabled in the BIOS
> >ASUS P8H67-M PRO BIOS 3904 (latest available)
> >Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF Dual Port
> >Network Connection (rev 01)
> >01:00.0 0200: 8086:10f1 (rev 01)
> > Subsystem: 8086:a21f
> >boot kernel 3.16 unbutu 14.04 with isolcpus=2,3,4
> >
> >When launching pktgen even with no TX asked the Errors RX counters keeps
> >going up by about 7.4 millions per second:
> >
> >Errors Rx/Tx : 7471857054/0
> >
> >In the log I get "Could not enable Rx Queue", might be the
> >source of the issue?
> >
> >PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 0
> >PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 1
> >
> >When sending traffic  single UDP src/dst/IP/MAC the setup
> >reaches 14204188 pps 64 bytes, the error counter is also
> >increasing.
> >
> >Any idea what to look for?
> 
> One more suggestion is to run test_pmd on one machine and something
> like iperf on the other to verify the DPDK is working correct, which I
> assume will be true. Not sure the RX errors are reported in the
> test_pmd or you could use the l3fwd application too.

Ok, I will check the test_pmd documentation and try to do this test: I'm
just starting on DPDK :).

> Please also send me the 'lspci | grep Ethernet? output.

I included one line in my original email above (plus extract of lspci
-vn), here is the full output of the command:

01:00.0 Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF
Dual Port Network Connection (rev 01)
01:00.1 Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF
Dual Port Network Connection (rev 01)
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

(The realtek is used only for internet connectivity).

> Also send me the command line.

On the first machine t1 :
root at t1:~/pktgen-dpdk# ./app/app/x86_64-native-linuxapp-gcc/pktgen \
-c e -n 1 --proc-type auto -- -m '[2:3].1' -P -f t1-t3.pkt -N  

And on the other machine t3:
root at t3:~/pktgen-dpdk# ./app/app/x86_64-native-linuxapp-gcc/pktgen \
-c e -n 1 --proc-type auto -- -m '[2:3].1' -P -f t3-t1.pkt -N

The two "-f" pkt files are attached to this email, I do "start 1"
manually at the pktgen prompt.

Thanks for your time,

Sincerely,

Laurent


> >
> >Laurent
> >
> >
> 
> 
> Regards,
> Keith
> 
> 
> 
>

[dpdk-dev] Errors Rx count increasing while pktgen doing nothing on Intel 82598EB 10G

2015-12-27 Thread Wiles, Keith 
On 12/27/15, 2:09 PM, "Laurent GUERBY"  wrote:

>On Sun, 2015-12-27 at 19:43 +, Wiles, Keith wrote:
>> On 12/27/15, 12:31 PM, "dev on behalf of Laurent GUERBY" > dpdk.org on behalf of laurent at guerby.net> wrote:
>> 
>> >Hi,
>> >
>> >I reported today an issue when using Pktgen-DPDK:
>> >https://github.com/pktgen/Pktgen-DPDK/issues/52
>> >
>> >But I think it's more in DPDK than pktgen
>> >
>> >two identical machines with SFP+ DA cable between them
>> >DPDK 2.2.0 from tarball
>> >Pktgen-DPDK from git
>> >two identical machines:
>> >core i7 2600 (sandy bridge 4C/8T), HT disabled in the BIOS
>> >ASUS P8H67-M PRO BIOS 3904 (latest available)
>> >Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF Dual Port
>> >Network Connection (rev 01)
>> >01:00.0 0200: 8086:10f1 (rev 01)
>> >Subsystem: 8086:a21f
>> >boot kernel 3.16 unbutu 14.04 with isolcpus=2,3,4
>> >
>> >When launching pktgen even with no TX asked the Errors RX counters keeps
>> >going up by about 7.4 millions per second:
>> >
>> >Errors Rx/Tx : 7471857054/0
>> >
>> >In the log I get "Could not enable Rx Queue", might be the
>> >source of the issue?
>> >
>> >PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 0
>> >PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 1
>> >
>> >When sending traffic  single UDP src/dst/IP/MAC the setup
>> >reaches 14204188 pps 64 bytes, the error counter is also
>> >increasing.
>> >
>> >Any idea what to look for?
>> 
>> One more suggestion is to run test_pmd on one machine and something
>> like iperf on the other to verify the DPDK is working correct, which I
>> assume will be true. Not sure the RX errors are reported in the
>> test_pmd or you could use the l3fwd application too.
>
>Ok, I will check the test_pmd documentation and try to do this test: I'm
>just starting on DPDK :).
>
>> Please also send me the 'lspci | grep Ethernet? output.
>
>I included one line in my original email above (plus extract of lspci
>-vn), here is the full output of the command:
>
>01:00.0 Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF
>Dual Port Network Connection (rev 01)
>01:00.1 Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF
>Dual Port Network Connection (rev 01)
>05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
>
>(The realtek is used only for internet connectivity).
>
>> Also send me the command line.
>
>On the first machine t1 :
>root at t1:~/pktgen-dpdk# ./app/app/x86_64-native-linuxapp-gcc/pktgen \
>-c e -n 1 --proc-type auto -- -m '[2:3].1' -P -f t1-t3.pkt -N  
>
>And on the other machine t3:
>root at t3:~/pktgen-dpdk# ./app/app/x86_64-native-linuxapp-gcc/pktgen \
>-c e -n 1 --proc-type auto -- -m '[2:3].1' -P -f t3-t1.pkt -N

You need to always start with port numbering for Pktgen with zero.

Change the [2:3].1 to [2:3].0 the reason is you removed one of the two ports 
and Pktgen starts port counting from zero for the first available port :-)

Sorry, I did not spot that sooner.
>
>The two "-f" pkt files are attached to this email, I do "start 1"
>manually at the pktgen prompt.
>
>Thanks for your time,
>
>Sincerely,
>
>Laurent
>
>
>> >
>> >Laurent
>> >
>> >
>> 
>> 
>> Regards,
>> Keith
>> 
>> 
>> 
>> 
>
>


Regards,
Keith

[dpdk-dev] bnx2x pmd performance expectations

2015-12-27 Thread Chas Williams 
I wouldn't consider myself an expert on this driver but while looking
at some other things, I have noted that?RTE_PMD_BNX2X_TX_MAX_BURST is
defined to be 1. ?This bursts single packets to bnx2x_tx_encap() but it
looks like bnx2x_tx_encap() is far more capable than that.

On Tue, 2015-12-22 at 14:52 +0300, Alexander Belyakov wrote:
> Hi,
> 
> just tried to forward a lot of tiny packets with testpmd (dpdk-2.2.0)
> running on Broadcom Corporation NetXtreme II BCM57810S 10 Gigabit
> Ethernet
> (rev 10) adapter. I see forwarding performance of 2.6Mpps instead of
> expected 14.8Mpps. What should be done to achieve better results?
> 
> Thank you,
> Alexander Belyakov

[dpdk-dev] [PATCH v2 1/3] app/test-pmd: Handle SIGINT and SIGTERM in testpmd

2015-12-27 Thread Stephen Hemminger 
On Thu, 24 Dec 2015 21:37:10 -0500
Zhihong Wang  wrote:

> Handle SIGINT and SIGTERM in testpmd.
> 
> Signed-off-by: Zhihong Wang 
> ---
>  app/test-pmd/cmdline.c | 19 +--
>  app/test-pmd/testpmd.c | 38 --
>  app/test-pmd/testpmd.h |  1 +
>  3 files changed, 46 insertions(+), 12 deletions(-)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index 73298c9..4ff1739 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -90,6 +90,8 @@
>  
>  #include "testpmd.h"
>  
> +static struct cmdline *testpmd_cl;
> +
>  static void cmd_reconfig_device_queue(portid_t id, uint8_t dev, uint8_t 
> queue);
>  
>  #ifdef RTE_NIC_BYPASS
> @@ -9778,17 +9780,22 @@ cmdline_parse_ctx_t main_ctx[] = {
>  void
>  prompt(void)
>  {
> - struct cmdline *cl;
> -
>   /* initialize non-constant commands */
>   cmd_set_fwd_mode_init();
>  
> - cl = cmdline_stdin_new(main_ctx, "testpmd> ");
> - if (cl == NULL) {
> + testpmd_cl = cmdline_stdin_new(main_ctx, "testpmd> ");
> + if (testpmd_cl == NULL) {
>   return;
>   }

Style nit: don't need {} around single statement.

> - cmdline_interact(cl);
> - cmdline_stdin_exit(cl);
> + cmdline_interact(testpmd_cl);
> + cmdline_stdin_exit(testpmd_cl);
> +}
> +
> +void
> +prompt_exit(void)
> +{
> + if (testpmd_cl != NULL)
> + cmdline_quit(testpmd_cl);
>  }
>  
>  static void
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index 98ae46d..cb38d56 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -1570,13 +1570,16 @@ pmd_test_exit(void)
>   if (test_done == 0)
>   stop_packet_forwarding();
>  
> - FOREACH_PORT(pt_id, ports) {
> - printf("Stopping port %d...", pt_id);
> - fflush(stdout);
> - rte_eth_dev_close(pt_id);
> - printf("done\n");
> + if (ports != NULL) {
> + FOREACH_PORT(pt_id, ports) {
> + printf("Stopping port %d...", pt_id);
> + fflush(stdout);
> + rte_eth_dev_stop(pt_id);
> + rte_eth_dev_close(pt_id);
> + printf(" Done\n");
> + }
>   }
> - printf("bye...\n");
> + printf("Bye...\n");
>  }
>  
>  typedef void (*cmd_func_t)(void);
> @@ -1984,12 +1987,34 @@ init_port(void)
>   ports[pid].enabled = 1;
>  }
>  
> +static void
> +force_quit(void)
> +{
> + pmd_test_exit();
> + prompt_exit();
> +}
> +
> +static void
> +sigint_handler(__rte_unused int signum)
> +{
> + if (signum == SIGINT || signum == SIGTERM) {

signmum is used, so don't want __rte_unused

> + printf("\nSignal %d received, preparing to exit...\n",
> + signum);
> + force_quit();
> + signal(signum, SIG_DFL);
> + kill(getpid(), signum);
> + }
> +}
> +
>  int
>  main(int argc, char** argv)
>  {
>   int  diag;
>   uint8_t port_id;
>  
> + signal(SIGINT, sigint_handler);
> + signal(SIGTERM, sigint_handler);
> +
>   diag = rte_eal_init(argc, argv);
>   if (diag < 0)
>   rte_panic("Cannot init EAL\n");
> @@ -2041,6 +2066,7 @@ main(int argc, char** argv)
>   start_packet_forwarding(0);
>   printf("Press enter to exit\n");
>   rc = read(0, &c, 1);
> + pmd_test_exit();
>   if (rc < 0)
>   return 1;
>   }
> diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
> index ee7de98..7ffc17b 100644
> --- a/app/test-pmd/testpmd.h
> +++ b/app/test-pmd/testpmd.h
> @@ -462,6 +462,7 @@ unsigned int parse_item_list(char* str, const char* 
> item_name,
>   unsigned int *parsed_items, int check_unique_values);
>  void launch_args_parse(int argc, char** argv);
>  void prompt(void);
> +void prompt_exit(void);
>  void nic_stats_display(portid_t port_id);
>  void nic_stats_clear(portid_t port_id);
>  void nic_xstats_display(portid_t port_id);

[dpdk-dev] [PATCH v2 2/3] examples/l2fwd: Handle SIGINT and SIGTERM in l2fwd

2015-12-27 Thread Stephen Hemminger 
On Thu, 24 Dec 2015 21:37:11 -0500
Zhihong Wang  wrote:

> Handle SIGINT and SIGTERM in l2fwd.
> 
> Signed-off-by: Zhihong Wang 
> ---
>  examples/l2fwd/main.c | 60 
> +++
>  1 file changed, 60 insertions(+)
> 
> diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
> index 720fd5a..75899dd 100644
> --- a/examples/l2fwd/main.c
> +++ b/examples/l2fwd/main.c
> @@ -44,6 +44,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> @@ -69,6 +71,9 @@
>  #include 
>  #include 
>  
> +static int force_quit = -1;
> +static int signo_quit = -1;

These need to be volatile otherwise you risk compiler optimizing
away your checks.

Also, don't use -1/0 just use 0/1 for boolean or better yet
the definition in  of bool and true/false.
That way the code can read much nicer.

>  #define RTE_LOGTYPE_L2FWD RTE_LOGTYPE_USER1
>  
>  #define NB_MBUF   8192
> @@ -284,6 +289,8 @@ l2fwd_main_loop(void)
>   }
>  
>   while (1) {
> + if (unlikely(force_quit != 0))
> + break;

Please maske this a proper while loop instead.

while (!force_quit) {

>  
>   cur_tsc = rte_rdtsc();
>  
> @@ -534,6 +541,45 @@ check_all_ports_link_status(uint8_t port_num, uint32_t 
> port_mask)
>   }
>  }
>  
> +static void
> +stop_ports(void)
> +{
> + unsigned portid, nb_ports;
> +
> + nb_ports = rte_eth_dev_count();
> + for (portid = 0; portid < nb_ports; portid++) {
> + if ((l2fwd_enabled_port_mask & (1 << portid)) == 0) {
> + continue;
> + }

No need for {} here.

> + printf("Stopping port %d...", portid);
> + rte_eth_dev_stop(portid);
> + rte_eth_dev_close(portid);
> + printf(" Done\n");
> + }
> +}
> +
> +static void
> +signal_handler(__rte_unused int signum)
> +{
> + if (signum == SIGINT || signum == SIGTERM) {

signum is used, dont give __rte_unused attribute.

>  
>   /* launch per-lcore init on every lcore */
> + force_quit = 0;

What is gained by having tri-value here. Just initialize it as false.


>   rte_eal_mp_remote_launch(l2fwd_launch_one_lcore, NULL, CALL_MASTER);
>   RTE_LCORE_FOREACH_SLAVE(lcore_id) {
>   if (rte_eal_wait_lcore(lcore_id) < 0)
>   return -1;
>   }
>  
> + printf("Stopping forwarding... Done\n");
> + /* stop ports */
> + stop_ports();
> + printf("Bye...\n");
> + /* inform if there's a caller */
> + if (force_quit != 0) {
> + signal(signo_quit, SIG_DFL);
> + kill(getpid(), signo_quit);

The kill should not be needed.

It would be good if examples cleaned up allocations, that way they
could be used with valgrind for validation of drivers, etc.

[dpdk-dev] releases scheduling

2015-12-27 Thread Thomas Monjalon 
2015-12-19 22:58, O'Driscoll, Tim:
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> > 2015-12-19 16:21, Wiles, Keith:
> > > On 12/19/15, 3:47 AM, "Thomas Monjalon"  
> > > wrote:
> > > >2015-12-19 02:16, Wiles, Keith:
> > > >> On 12/18/15, 6:01 PM, "dev on behalf of Thomas Monjalon" wrote:
> > > >> >2015-12-13 20:22, Thomas Monjalon:
> > > >> >> We need to define the deadlines for the next releases.
> > > >> >> During 2015, we were doing a release every 4 months.
> > > >> >> If we keep the same pace, the next releases would be:
> > > >> >> 2.3: end of March
> > > >> >> 2.4: end of July
> > > >> >> 2.5: end of November
> > > >> >>
> > > >> >> However, things move fast and it may be a bit long to wait 4
> > months for
> > > >> >> a feature. That's why I suggest to progressively shorten release
> > terms:
> > > >> >> 2.3: end of March
> > > >> >> 2.4: mid July
> > > >> >> 2.5: end of October
> > > >> >> and continue with a release every 3 months:
> > > >> >> 2.6: end of January
> > > >> >> 2.7: end of April
> > > >> >> 2.8: end of July
> > > >> >> This planning would preserve some of the major holiday periods
> > > >> >> (February, May, August, December).
> > > >> >>
> > > >> >> The first period, for the first submission of a feature, was 2
> > months long.
> > > >> >> Then we had 2 other months to discuss, merge and fix.
> > > >> >> We should shorten only the first period.
> > > >> >>
> > > >> >> Anyway, the next deadlines should be unchanged:
> > > >> >> - January 31: end of first submission phase
> > > >> >> - March 31: release 2.3
> > > >> >>
> > > >> >> Opinions are welcome.
> > > >> >
> > > >> >It seems everybody agree with this new scheduling.
> > > >> >The web site will be updated accordingly:
> > > >> >http://dpdk.org/ml/archives/web/2015-December/08.html
[...]
> > > >I add it here again to make it more visible:
> > > > http://dpdk.org/ml/archives/web/2015-December/08.html
> > > >And I copy-paste here:
> > > > The release cycles are progressively shorten during 2016.
> > > > Release 16.04
> > > > Proposal deadline: January 31
> > > > Integration deadline: March 10
> > > > Release: April 7
> > > > Release 16.07
> > > > Proposal deadline: May 8
> > > > Integration deadline: June 16
> > > > Release: July 18
> > > > Release 16.11
> > > > Proposal deadline: August 28
> > > > Integration deadline: September 30
> > > > Release: November 2
> > > > Release 17.02
> > > > Release: February 1
> > > > Release 17.05
> > > > Release: May 2
> > > > Release 17.08
> > > > Release: August 1
> > > > Release 17.11
> > > > Release: November 2
[...]
> > > Please consider making the months fixed instead of having them move a
> > bit each year.
> > 
> > Yes that's what I considered. The dates are not the same in 2016 and
> > 2017
> > because of the progressive change.
> > But 2017 and 2018 should be identical.
> > And more importantly, these dates should respect the major holidays.
> 
> +1
> 
> I think this is a good compromise. It changes the release dates for 2016 
> gradually, so it avoids disrupting any existing plans. It also avoids the 
> major holiday periods as much as possible, and gives us a consistent release 
> schedule from 2017 onwards.

So it will be applied and visble on the web site.
Thanks for your comments

[dpdk-dev] [PATCH] mk: fix examples build failure

2015-12-27 Thread Thomas Monjalon 
2015-12-24 20:38, steeven lee:
> 1. Fix examples build failure

Please explain in the commit log what was the issue.

> 2. make build as default output folder name

It should be a separate patch.
What is the benefit?
Please give some example command lines.

Thanks