[dpdk-dev] [PATCH v7 1/6] Move common functions in eal_thread.c

2015-04-25 Thread Ravi Kerur 
On Sat, Apr 25, 2015 at 6:02 AM, Neil Horman  wrote:

> On Sat, Apr 25, 2015 at 08:32:42AM -0400, Neil Horman wrote:
> > On Fri, Apr 24, 2015 at 06:45:06PM -0700, Ravi Kerur wrote:
> > > On Fri, Apr 24, 2015 at 2:24 PM, Ravi Kerur  wrote:
> > >
> > > >
> > > >
> > > > On Fri, Apr 24, 2015 at 12:51 PM, Neil Horman  >
> > > > wrote:
> > > >
> > > >> On Fri, Apr 24, 2015 at 12:21:23PM -0700, Ravi Kerur wrote:
> > > >> > On Fri, Apr 24, 2015 at 11:53 AM, Neil Horman <
> nhorman at tuxdriver.com>
> > > >> wrote:
> > > >> >
> > > >> > > On Fri, Apr 24, 2015 at 09:45:24AM -0700, Ravi Kerur wrote:
> > > >> > > > On Fri, Apr 24, 2015 at 8:22 AM, Neil Horman <
> nhorman at tuxdriver.com
> > > >> >
> > > >> > > wrote:
> > > >> > > >
> > > >> > > > > On Fri, Apr 24, 2015 at 08:14:04AM -0700, Ravi Kerur wrote:
> > > >> > > > > > On Fri, Apr 24, 2015 at 6:51 AM, Neil Horman <
> > > >> nhorman at tuxdriver.com>
> > > >> > > > > wrote:
> > > >> > > > > >
> > > >> > > > > > > On Thu, Apr 23, 2015 at 02:35:31PM -0700, Ravi Kerur
> wrote:
> > > >> > > > > > > > Changes in v7
> > > >> > > > > > > > Remove _setname_ pthread calls.
> > > >> > > > > > > > Use rte_gettid() API in RTE_LOG to print thread_id.
> > > >> > > > > > > >
> > > >> > > > > > > > Changes in v6
> > > >> > > > > > > > Remove RTE_EXEC_ENV_BSDAPP from eal_common_thread.c
> file.
> > > >> > > > > > > > Add pthread_setname_np/pthread_set_name_np for
> Linux/FreeBSD
> > > >> > > > > > > > respectively. Plan to use _getname_ in RTE_LOG when
> > > >> available.
> > > >> > > > > > > > Use existing rte_get_systid() in RTE_LOG to print
> thread_id.
> > > >> > > > > > > >
> > > >> > > > > > > > Changes in v5
> > > >> > > > > > > > Rebase to latest code.
> > > >> > > > > > > >
> > > >> > > > > > > > Changes in v4
> > > >> > > > > > > > None
> > > >> > > > > > > >
> > > >> > > > > > > > Changes in v3
> > > >> > > > > > > > Changed subject to be more explicit on file name
> inclusion.
> > > >> > > > > > > >
> > > >> > > > > > > > Changes in v2
> > > >> > > > > > > > None
> > > >> > > > > > > >
> > > >> > > > > > > > Changes in v1
> > > >> > > > > > > > eal_thread.c has minor differences between Linux and
> BSD,
> > > >> move
> > > >> > > > > > > > entire file into common directory.
> > > >> > > > > > > > Use RTE_EXEC_ENV_BSDAPP to differentiate on minor
> > > >> differences.
> > > >> > > > > > > > Rename eal_thread.c to eal_common_thread.c
> > > >> > > > > > > > Makefile changes to reflect file move and name change.
> > > >> > > > > > > > Fix checkpatch warnings.
> > > >> > > > > > > >
> > > >> > > > > > > > Signed-off-by: Ravi Kerur 
> > > >> > > > > > > > ---
> > > >> > > > > > > >  lib/librte_eal/bsdapp/eal/Makefile|   2 +-
> > > >> > > > > > > >  lib/librte_eal/bsdapp/eal/eal_thread.c| 152
> > > >> > > > > > > --
> > > >> > > > > > > >  lib/librte_eal/common/eal_common_thread.c | 147
> > > >> > > > > > > -
> > > >> > > > > > > >  lib/librte_eal/linuxapp/eal/eal_thread.c  | 152
> > > >> > > > > > > +-
> > > >> > > > > > > >  4 files changed, 148 insertions(+), 305 deletions(-)
> > > >> > > > > > > >
> > > >> > > > > > > > diff --git a/lib/librte_eal/bsdapp/eal/Makefile
> > > >> > > > > > > b/lib/librte_eal/bsdapp/eal/Makefile
> > > >> > > > > > > > index 2357cfa..55971b9 100644
> > > >> > > > > > > > --- a/lib/librte_eal/bsdapp/eal/Makefile
> > > >> > > > > > > > +++ b/lib/librte_eal/bsdapp/eal/Makefile
> > > >> > > > > > > > @@ -87,7 +87,7 @@ CFLAGS_eal_common_log.o :=
> -D_GNU_SOURCE
> > > >> > > > > > > >  # workaround for a gcc bug with noreturn attribute
> > > >> > > > > > > >  # http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
> > > >> > > > > > > >  ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
> > > >> > > > > > > > -CFLAGS_eal_thread.o += -Wno-return-type
> > > >> > > > > > > > +CFLAGS_eal_common_thread.o += -Wno-return-type
> > > >> > > > > > > >  CFLAGS_eal_hpet.o += -Wno-return-type
> > > >> > > > > > > >  endif
> > > >> > > > > > > >
> > > >> > > > > > > > diff --git a/lib/librte_eal/bsdapp/eal/eal_thread.c
> > > >> > > > > > > b/lib/librte_eal/bsdapp/eal/eal_thread.c
> > > >> > > > > > > > index 9a03437..5714b8f 100644
> > > >> > > > > > > > --- a/lib/librte_eal/bsdapp/eal/eal_thread.c
> > > >> > > > > > > > +++ b/lib/librte_eal/bsdapp/eal/eal_thread.c
> > > >> > > > > > > > @@ -35,163 +35,11 @@
> > > >> > > > > > > >  #include 
> > > >> > > > > > > >  #include 
> > > >> > > > > > > >  #include 
> > > >> > > > > > > > -#include 
> > > >> > > > > > > > -#include 
> > > >> > > > > > > > -#include 
> > > >> > > > > > > > -#include 
> > > >> > > > > > > >  #include 
> > > >> > > > > > > >
> > > >> > > > > > > > -#include 
> > > >> > > > > > > > -#include 
> > > >> > > > > > > > -#include 
> > > >> > > > > > > > -#include 
> > > >> > > > > > > > -#include 
> > > >> > > > > > > > -#include 
> > > >> > > > > > > > -#include 
> > > >> > > > > > > > -#include 
> > > >> > > > > >

[dpdk-dev] Beyond DPDK 2.0

2015-04-25 Thread Wiles, Keith 


On 4/25/15, 8:30 AM, "Marc Sune"  wrote:

>
>
>On 24/04/15 19:51, Matthew Hall wrote:
>> On Fri, Apr 24, 2015 at 12:39:47PM -0500, Jay Rolette wrote:
>>> I can tell you that if DPDK were GPL-based, my company wouldn't be
>>>using
>>> it. I suspect we wouldn't be the only ones...
>>>
>>> Jay
>> I could second this, from the past employer where I used it. Right now
>>I am
>> using it in an open source app, I have a bit of GPL here and there but
>>I'm
>> trying to get rid of it or confine it to separate address spaces, where
>>it
>> won't impact the core code written around DPDK, as I don't want to cause
>> headaches for any downstream users I attract someday.
>>
>> Hard-core GPL would not be possible for most. LGPL could be possible,
>>but I
>> don't think it could be worth the relicensing headache for that small
>>change.
>>
>> Instead we should make the patch process as easy as humanly possible so
>>people
>> are encouraged to send us the fixes and not cart them around their
>>companies
>> constantly.

+1 and besides the GPL or LGPL ship has sailed IMHO and we can not go back.
>
>I agree. My feeling is that as the number of patches in the mailing list
>grows, keeping track of them gets more and more complicated. Patchwork
>website was a way to try to address this issue. I think it was an
>improvement, but to be honest, patchwork lacks a lot of functionality,
>such as properly tracking multiple versions of the patch (superseding
>them automatically), and it lacks some filtering capabilities e.g. per
>user, per tag/label or library, automatically track if it has been
>merged, give an overall status of the pending vs merged patches, set
>milestones... Is there any alternative tool or improved version for that?

I agree patchwork has some limitation, but I think the biggest issue is
keeping up with the patches. Getting patches introduced into the main line
is very slow. A patch submitted today may not get applied for weeks or
months, then when another person submits a patch he is starting to run a
very high risk of having to redo that patch, because a pervious patch
makes his fail weeks/months later. I would love to see a better tool then
patchwork, but the biggest issue is we have a huge backlog of patches.
Personally I am not sure how Thomas or any is able to keep up with the
patches.

The other problem I see is how patches are agreed on to be included in the
mainline. Today it is just an ACK or a NAK on the mailing list. Then I see
what I think to be only a few people ACKing or NAKing patches. This
process has a lot of problems from a patch being ignore for some reason or
someone having negative feed back on very minor detail or no way to push a
patch forward a single NAK or comment.

I would like to see some type of layering process to allow patches to be
applied in a timely manner a few weeks not months or completely ignored.
Maybe some type of voting is reasonable, but we need to do something to
turn around the patches in clean reasonable manner.

Think we need some type of group meeting every week to look at the patches
and determining which ones get applied, this gives quick feedback to the
submitter as to the status of the patch.

>
>On the other side, since user questions, community discussions and
>development happens in the same mailing list, things get really
>complicated, specially for users seeking for help. Even though I think
>the average skills of the users of DPDK is generally higher than in
>other software projects, if DPDK wants to attract more users, having a
>better user support is key, IMHO.
>
>So I would see with good eyes a separation between, at least, dpdk-user
>and dpdk-dev.

I do not remember seeing too many users on the list and making a list just
for then is OK if everyone is fine with a list that has very few emails.
>
>If the number of patches keeps growing, splitting the "dev" mailing
>lists into different categories (eal and common, pmds, higher level
>abstractions...) could be an option. However, this last point opens a
>lot of questions on how to minimize interference between the different
>parts and API/ABI compatibility during the development.

I believe if we just make sure we use tags in the subject line then we can
have our email clients do the splitting of the emails instead of adding
more emails lists.

>
>>
>> Perhaps it means having some ReviewBoard type of tools, a clone in
>>Github or
>> Bitbucket where the less hardcore kernel-workflow types could send back
>>their
>> small bug fixes a bit more easily, this kind of stuff. Google has been
>>getting
>> good uptake since they moved most of their open source across to Github,
>> because the contribution workflow was more convenient than Google Code
>>was.

I like GitHub it is a much better designed tool then patchwork, plus it
could get more eyes as it is very well know to the developer community in
general. I feel GitHub has many advantages over the current systems in
place but, it does not solve the all patch i

[dpdk-dev] Beyond DPDK 2.0

2015-04-25 Thread Marc Sune 


On 24/04/15 19:51, Matthew Hall wrote:
> On Fri, Apr 24, 2015 at 12:39:47PM -0500, Jay Rolette wrote:
>> I can tell you that if DPDK were GPL-based, my company wouldn't be using
>> it. I suspect we wouldn't be the only ones...
>>
>> Jay
> I could second this, from the past employer where I used it. Right now I am
> using it in an open source app, I have a bit of GPL here and there but I'm
> trying to get rid of it or confine it to separate address spaces, where it
> won't impact the core code written around DPDK, as I don't want to cause
> headaches for any downstream users I attract someday.
>
> Hard-core GPL would not be possible for most. LGPL could be possible, but I
> don't think it could be worth the relicensing headache for that small change.
>
> Instead we should make the patch process as easy as humanly possible so people
> are encouraged to send us the fixes and not cart them around their companies
> constantly.

I agree. My feeling is that as the number of patches in the mailing list 
grows, keeping track of them gets more and more complicated. Patchwork 
website was a way to try to address this issue. I think it was an 
improvement, but to be honest, patchwork lacks a lot of functionality, 
such as properly tracking multiple versions of the patch (superseding 
them automatically), and it lacks some filtering capabilities e.g. per 
user, per tag/label or library, automatically track if it has been 
merged, give an overall status of the pending vs merged patches, set 
milestones... Is there any alternative tool or improved version for that?

On the other side, since user questions, community discussions and 
development happens in the same mailing list, things get really 
complicated, specially for users seeking for help. Even though I think 
the average skills of the users of DPDK is generally higher than in 
other software projects, if DPDK wants to attract more users, having a 
better user support is key, IMHO.

So I would see with good eyes a separation between, at least, dpdk-user 
and dpdk-dev.

If the number of patches keeps growing, splitting the "dev" mailing 
lists into different categories (eal and common, pmds, higher level 
abstractions...) could be an option. However, this last point opens a 
lot of questions on how to minimize interference between the different 
parts and API/ABI compatibility during the development.

>
> Perhaps it means having some ReviewBoard type of tools, a clone in Github or
> Bitbucket where the less hardcore kernel-workflow types could send back their
> small bug fixes a bit more easily, this kind of stuff. Google has been getting
> good uptake since they moved most of their open source across to Github,
> because the contribution workflow was more convenient than Google Code was.

Although I agree, we have to be careful on how github or bitbucket is 
used. Having issues or even (e.g. github) pull requests *in addition* to 
the normal contribution workflow can be a nightmare to deal with, in 
terms of synchronization and preventing double work. So I guess setting 
up an official github or bitbucket mirror would be fine, via some simple 
cronjob, but I guess it would end-up not using PRs or issues in github 
like the Linux kernel does.

Btw, is this github organization already registered by Intel or some 
other company of the community?

https://github.com/dpdk

Marc

>
> Matthew.

[dpdk-dev] [PATCH v7 1/6] Move common functions in eal_thread.c

2015-04-25 Thread Neil Horman 
On Sat, Apr 25, 2015 at 08:32:42AM -0400, Neil Horman wrote:
> On Fri, Apr 24, 2015 at 06:45:06PM -0700, Ravi Kerur wrote:
> > On Fri, Apr 24, 2015 at 2:24 PM, Ravi Kerur  wrote:
> > 
> > >
> > >
> > > On Fri, Apr 24, 2015 at 12:51 PM, Neil Horman 
> > > wrote:
> > >
> > >> On Fri, Apr 24, 2015 at 12:21:23PM -0700, Ravi Kerur wrote:
> > >> > On Fri, Apr 24, 2015 at 11:53 AM, Neil Horman  > >> > tuxdriver.com>
> > >> wrote:
> > >> >
> > >> > > On Fri, Apr 24, 2015 at 09:45:24AM -0700, Ravi Kerur wrote:
> > >> > > > On Fri, Apr 24, 2015 at 8:22 AM, Neil Horman  > >> > > > tuxdriver.com
> > >> >
> > >> > > wrote:
> > >> > > >
> > >> > > > > On Fri, Apr 24, 2015 at 08:14:04AM -0700, Ravi Kerur wrote:
> > >> > > > > > On Fri, Apr 24, 2015 at 6:51 AM, Neil Horman <
> > >> nhorman at tuxdriver.com>
> > >> > > > > wrote:
> > >> > > > > >
> > >> > > > > > > On Thu, Apr 23, 2015 at 02:35:31PM -0700, Ravi Kerur wrote:
> > >> > > > > > > > Changes in v7
> > >> > > > > > > > Remove _setname_ pthread calls.
> > >> > > > > > > > Use rte_gettid() API in RTE_LOG to print thread_id.
> > >> > > > > > > >
> > >> > > > > > > > Changes in v6
> > >> > > > > > > > Remove RTE_EXEC_ENV_BSDAPP from eal_common_thread.c file.
> > >> > > > > > > > Add pthread_setname_np/pthread_set_name_np for 
> > >> > > > > > > > Linux/FreeBSD
> > >> > > > > > > > respectively. Plan to use _getname_ in RTE_LOG when
> > >> available.
> > >> > > > > > > > Use existing rte_get_systid() in RTE_LOG to print 
> > >> > > > > > > > thread_id.
> > >> > > > > > > >
> > >> > > > > > > > Changes in v5
> > >> > > > > > > > Rebase to latest code.
> > >> > > > > > > >
> > >> > > > > > > > Changes in v4
> > >> > > > > > > > None
> > >> > > > > > > >
> > >> > > > > > > > Changes in v3
> > >> > > > > > > > Changed subject to be more explicit on file name inclusion.
> > >> > > > > > > >
> > >> > > > > > > > Changes in v2
> > >> > > > > > > > None
> > >> > > > > > > >
> > >> > > > > > > > Changes in v1
> > >> > > > > > > > eal_thread.c has minor differences between Linux and BSD,
> > >> move
> > >> > > > > > > > entire file into common directory.
> > >> > > > > > > > Use RTE_EXEC_ENV_BSDAPP to differentiate on minor
> > >> differences.
> > >> > > > > > > > Rename eal_thread.c to eal_common_thread.c
> > >> > > > > > > > Makefile changes to reflect file move and name change.
> > >> > > > > > > > Fix checkpatch warnings.
> > >> > > > > > > >
> > >> > > > > > > > Signed-off-by: Ravi Kerur 
> > >> > > > > > > > ---
> > >> > > > > > > >  lib/librte_eal/bsdapp/eal/Makefile|   2 +-
> > >> > > > > > > >  lib/librte_eal/bsdapp/eal/eal_thread.c| 152
> > >> > > > > > > --
> > >> > > > > > > >  lib/librte_eal/common/eal_common_thread.c | 147
> > >> > > > > > > -
> > >> > > > > > > >  lib/librte_eal/linuxapp/eal/eal_thread.c  | 152
> > >> > > > > > > +-
> > >> > > > > > > >  4 files changed, 148 insertions(+), 305 deletions(-)
> > >> > > > > > > >
> > >> > > > > > > > diff --git a/lib/librte_eal/bsdapp/eal/Makefile
> > >> > > > > > > b/lib/librte_eal/bsdapp/eal/Makefile
> > >> > > > > > > > index 2357cfa..55971b9 100644
> > >> > > > > > > > --- a/lib/librte_eal/bsdapp/eal/Makefile
> > >> > > > > > > > +++ b/lib/librte_eal/bsdapp/eal/Makefile
> > >> > > > > > > > @@ -87,7 +87,7 @@ CFLAGS_eal_common_log.o := -D_GNU_SOURCE
> > >> > > > > > > >  # workaround for a gcc bug with noreturn attribute
> > >> > > > > > > >  # http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
> > >> > > > > > > >  ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
> > >> > > > > > > > -CFLAGS_eal_thread.o += -Wno-return-type
> > >> > > > > > > > +CFLAGS_eal_common_thread.o += -Wno-return-type
> > >> > > > > > > >  CFLAGS_eal_hpet.o += -Wno-return-type
> > >> > > > > > > >  endif
> > >> > > > > > > >
> > >> > > > > > > > diff --git a/lib/librte_eal/bsdapp/eal/eal_thread.c
> > >> > > > > > > b/lib/librte_eal/bsdapp/eal/eal_thread.c
> > >> > > > > > > > index 9a03437..5714b8f 100644
> > >> > > > > > > > --- a/lib/librte_eal/bsdapp/eal/eal_thread.c
> > >> > > > > > > > +++ b/lib/librte_eal/bsdapp/eal/eal_thread.c
> > >> > > > > > > > @@ -35,163 +35,11 @@
> > >> > > > > > > >  #include 
> > >> > > > > > > >  #include 
> > >> > > > > > > >  #include 
> > >> > > > > > > > -#include 
> > >> > > > > > > > -#include 
> > >> > > > > > > > -#include 
> > >> > > > > > > > -#include 
> > >> > > > > > > >  #include 
> > >> > > > > > > >
> > >> > > > > > > > -#include 
> > >> > > > > > > > -#include 
> > >> > > > > > > > -#include 
> > >> > > > > > > > -#include 
> > >> > > > > > > > -#include 
> > >> > > > > > > > -#include 
> > >> > > > > > > > -#include 
> > >> > > > > > > > -#include 
> > >> > > > > > > > -#include 
> > >> > > > > > > > -#include 
> > >> > > > > > > > -
> > >> > > > > > > >  #include "eal_private.h"
> > >> > > > > > > >  #include "eal_thread.h"
> > >> > > > > > > >
> > >> > > > > > > > -RTE_DEFINE_PER_LCORE(unsigned, _lcore_id

[dpdk-dev] [PATCH v7 1/6] Move common functions in eal_thread.c

2015-04-25 Thread Neil Horman 
On Fri, Apr 24, 2015 at 06:45:06PM -0700, Ravi Kerur wrote:
> On Fri, Apr 24, 2015 at 2:24 PM, Ravi Kerur  wrote:
> 
> >
> >
> > On Fri, Apr 24, 2015 at 12:51 PM, Neil Horman 
> > wrote:
> >
> >> On Fri, Apr 24, 2015 at 12:21:23PM -0700, Ravi Kerur wrote:
> >> > On Fri, Apr 24, 2015 at 11:53 AM, Neil Horman 
> >> wrote:
> >> >
> >> > > On Fri, Apr 24, 2015 at 09:45:24AM -0700, Ravi Kerur wrote:
> >> > > > On Fri, Apr 24, 2015 at 8:22 AM, Neil Horman  >> > > > tuxdriver.com
> >> >
> >> > > wrote:
> >> > > >
> >> > > > > On Fri, Apr 24, 2015 at 08:14:04AM -0700, Ravi Kerur wrote:
> >> > > > > > On Fri, Apr 24, 2015 at 6:51 AM, Neil Horman <
> >> nhorman at tuxdriver.com>
> >> > > > > wrote:
> >> > > > > >
> >> > > > > > > On Thu, Apr 23, 2015 at 02:35:31PM -0700, Ravi Kerur wrote:
> >> > > > > > > > Changes in v7
> >> > > > > > > > Remove _setname_ pthread calls.
> >> > > > > > > > Use rte_gettid() API in RTE_LOG to print thread_id.
> >> > > > > > > >
> >> > > > > > > > Changes in v6
> >> > > > > > > > Remove RTE_EXEC_ENV_BSDAPP from eal_common_thread.c file.
> >> > > > > > > > Add pthread_setname_np/pthread_set_name_np for Linux/FreeBSD
> >> > > > > > > > respectively. Plan to use _getname_ in RTE_LOG when
> >> available.
> >> > > > > > > > Use existing rte_get_systid() in RTE_LOG to print thread_id.
> >> > > > > > > >
> >> > > > > > > > Changes in v5
> >> > > > > > > > Rebase to latest code.
> >> > > > > > > >
> >> > > > > > > > Changes in v4
> >> > > > > > > > None
> >> > > > > > > >
> >> > > > > > > > Changes in v3
> >> > > > > > > > Changed subject to be more explicit on file name inclusion.
> >> > > > > > > >
> >> > > > > > > > Changes in v2
> >> > > > > > > > None
> >> > > > > > > >
> >> > > > > > > > Changes in v1
> >> > > > > > > > eal_thread.c has minor differences between Linux and BSD,
> >> move
> >> > > > > > > > entire file into common directory.
> >> > > > > > > > Use RTE_EXEC_ENV_BSDAPP to differentiate on minor
> >> differences.
> >> > > > > > > > Rename eal_thread.c to eal_common_thread.c
> >> > > > > > > > Makefile changes to reflect file move and name change.
> >> > > > > > > > Fix checkpatch warnings.
> >> > > > > > > >
> >> > > > > > > > Signed-off-by: Ravi Kerur 
> >> > > > > > > > ---
> >> > > > > > > >  lib/librte_eal/bsdapp/eal/Makefile|   2 +-
> >> > > > > > > >  lib/librte_eal/bsdapp/eal/eal_thread.c| 152
> >> > > > > > > --
> >> > > > > > > >  lib/librte_eal/common/eal_common_thread.c | 147
> >> > > > > > > -
> >> > > > > > > >  lib/librte_eal/linuxapp/eal/eal_thread.c  | 152
> >> > > > > > > +-
> >> > > > > > > >  4 files changed, 148 insertions(+), 305 deletions(-)
> >> > > > > > > >
> >> > > > > > > > diff --git a/lib/librte_eal/bsdapp/eal/Makefile
> >> > > > > > > b/lib/librte_eal/bsdapp/eal/Makefile
> >> > > > > > > > index 2357cfa..55971b9 100644
> >> > > > > > > > --- a/lib/librte_eal/bsdapp/eal/Makefile
> >> > > > > > > > +++ b/lib/librte_eal/bsdapp/eal/Makefile
> >> > > > > > > > @@ -87,7 +87,7 @@ CFLAGS_eal_common_log.o := -D_GNU_SOURCE
> >> > > > > > > >  # workaround for a gcc bug with noreturn attribute
> >> > > > > > > >  # http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
> >> > > > > > > >  ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
> >> > > > > > > > -CFLAGS_eal_thread.o += -Wno-return-type
> >> > > > > > > > +CFLAGS_eal_common_thread.o += -Wno-return-type
> >> > > > > > > >  CFLAGS_eal_hpet.o += -Wno-return-type
> >> > > > > > > >  endif
> >> > > > > > > >
> >> > > > > > > > diff --git a/lib/librte_eal/bsdapp/eal/eal_thread.c
> >> > > > > > > b/lib/librte_eal/bsdapp/eal/eal_thread.c
> >> > > > > > > > index 9a03437..5714b8f 100644
> >> > > > > > > > --- a/lib/librte_eal/bsdapp/eal/eal_thread.c
> >> > > > > > > > +++ b/lib/librte_eal/bsdapp/eal/eal_thread.c
> >> > > > > > > > @@ -35,163 +35,11 @@
> >> > > > > > > >  #include 
> >> > > > > > > >  #include 
> >> > > > > > > >  #include 
> >> > > > > > > > -#include 
> >> > > > > > > > -#include 
> >> > > > > > > > -#include 
> >> > > > > > > > -#include 
> >> > > > > > > >  #include 
> >> > > > > > > >
> >> > > > > > > > -#include 
> >> > > > > > > > -#include 
> >> > > > > > > > -#include 
> >> > > > > > > > -#include 
> >> > > > > > > > -#include 
> >> > > > > > > > -#include 
> >> > > > > > > > -#include 
> >> > > > > > > > -#include 
> >> > > > > > > > -#include 
> >> > > > > > > > -#include 
> >> > > > > > > > -
> >> > > > > > > >  #include "eal_private.h"
> >> > > > > > > >  #include "eal_thread.h"
> >> > > > > > > >
> >> > > > > > > > -RTE_DEFINE_PER_LCORE(unsigned, _lcore_id) = LCORE_ID_ANY;
> >> > > > > > > NAK, these are exported symbols, you can't remove them without
> >> > > going
> >> > > > > > > through the
> >> > > > > > > deprecation process.
> >> > > > > > >
> >> > > > > > >
> >> > > > > > They are not removed/deleted, they are moved from eal_thread.c
> >> to
> >> > > > > > eal_common_thread.c file since it is

[dpdk-dev] Beyond DPDK 2.0

2015-04-25 Thread Neil Horman 
On Fri, Apr 24, 2015 at 02:55:33PM -0500, Jay Rolette wrote:
> On Fri, Apr 24, 2015 at 1:51 PM, Neil Horman  wrote:
> 
> > So, I hear your arguments, and its understandable that you might not want
> > a GPL
> > licensed product, given that the DPDK is a library (though I'm not sure
> > what the
> > aversion to LGPL would be).  Regardless, I think this conversation is a
> > bit more
> > about participation than license choice.  While you are correct, in that
> > the
> > first step to support (by which I presume you mean participation in the
> > community) is use, the goal here is to get people contributing patches and
> > helping increase the usefulness of DPDK.
> 
> 
> > Given that DPDK is primarily licensed as BSD now, whats preventing you, or
> > what
> > would encourage you to participate in the community?  I see emails from
> > infiniteio addresss in the archives asking questions and making
> > suggestions on
> > occasion, but no patches.  What would get you (or others in a simmilar
> > situation) to submit those?
> >
> 
> 36 hours in the day? :)
> 
> It's not a lot, but we've submitted a couple of small patches. It's mostly
> a matter of opportunity. We submit patches as we come across DPDK bugs or
> find useful optos.
> 
> *Patches*
> 
>- replaced O(n^2) sort in sort_by_physaddr() with qsort() from standard
>library 
>- Fixed spam from kni_allocate_mbufs() when no mbufs are free. If mbufs
>exhausted, 'out of memory' message logged at EXTREMELY high rates. Now logs
>no more than once per 10 mins 
> 
> *Reviews*
> 
>- kni: optimizing the rte_kni_rx_burst
>
>- [PATCH RFC] librte_reorder: new reorder library
>
>- [PATCH v2 09/17] i40e: clean log messages
> (several in
>that series, but I figure 1 link is plenty)
> 
> *Other*
> Not really patches or reviews, but trying to participate in the community:
> 
>- VMware Fusion + DPDK and KNI
>
>- Appropriate DPDK data structures for TCP sockets
>
>- kernel: BUG: soft lockup - CPU#1 stuck for 22s! [kni_single:1782]
>
>- segmented recv ixgbevf
>
> 
> Jay

Understand, I'm not trying to single you out here.  I see that you, and others
from infiniteio have had some participation in the project, and thats great, and
appreciated. I'm more focused on why that level of participation is not higher
(not only from you, but from the larger presumed user base in general).  As
noted at the start of this thread, one of the goals of this discussion is to
find ways to maximize participation in the project, and from you I'm hearing
that:

1) you use the dpdk because it lowers maintenence overhead
2) you don't participate more in the project because your product work schedule
doesn't allow you to do so.

Are those both accurate statements?

Can we also assume, for the sake of discussion that you have encountered
problems, or desired additions to the DPDK, for which you have implemented your
own code in the library that is not contributed back to the DPDK? 

If that is true, perhaps part of this conversation needs to revolve around the
tangible benefits of contributing that code back to the upstream project (the
aforementioned reduction of overhead) as well as the intangible (thought
leadership as the project develops).  Its been my experience, that these
situations often arise because management at a company often places a strong
bias on development of their product over participation in the open source
portion of it, treating the latter as if they are a customer of it, rather than
a participant in it, and it would be my desire to see that bias adjusted so as
to allow you greater freedom to participate in the project.

Would you agree to that assessment?  If so, how would you suggest that we, as a
community address this, and illustrate the appeal of contribution and
participation to your company and the benefits thereof?

Best
Neil