[dpdk-dev] Beyond DPDK 2.0

[Matthew Hall]

On Apr 25, 2015, at 5:10 AM, Neil Horman  wrote:
> I'm more focused on why that level of participation is not higher

Hi Neal,

This mail is probably way too long, but here is what I saw about participation, 
in my case I used DPDK on two projects so far:

1) proprietary project for a L4-L7 stateful replay DPI firewall performance 
tester at a large network test and measurement corporation using the old 
original 6WIND DPDK 1.X under NDA before it became available to a wider channel

2) open-source self-created threat intelligence sensor project using DPDK 
1.7.X, under development in my spare time

I think the things that making more DPDK contributions are ironically more 
technical and social in nature than legal or bureaucratic in nature as one 
would normally suspect, and as you theorized in your original mail. Let me go 
through some things and see what people think.

At the social level, there are not very many people in the world who are 
familiar and comfortable with the LKML style embedded coding workflow (heavy 
mailing list usage, sending and reviewing patches in emails, putting specific 
people in To or Cc to get patches approved and ACKed in subtrees, etc.) I 
happen to know some if not most of this tribally, because I used Linux since 
1997, but very few developers have any clue about this stuff. However I never 
participated in the actual LKML flow any further than tester / bug reporter, 
and I actually use DPDK very deliberately, to avoid fighting with the headaches 
of the linux-net code and flamewars.

This is why I was proposing that we try to find a way to allow contributions 
via Github or Bitbucket... their fork-and-pull model is much simpler for 
outsiders to comprehend and make quick patches when they find little bugs or 
issues as they integrate with the library... given we are BSD licensed, the low 
barrier to entry is the ultimate way to keep the patch velocity as high as 
possible, and keep the community going.

At the technical level, I see two or three difficulties:

1) A lot of the various performance enhancements one can use are kind of 
"magical" or "jigsaw puzzle" and not presented in a unified way, where I can 
methodically go through a checklist and enable everything my app should use 
even though I have no clue what they all are. For example, 1) let's talk about 
hashing... there is RSS hashing (symmetric or asymmetric), JHASH, CRC hash, ... 
not sure how many different ones. 2) Let's talk about CPU models... SSE, SSE4, 
SSE4.1, SSE4.2, etc. I don't know what I have myself, much less what my users 
will have, much less what I actually need or should use, without guidance from 
some processor people. 3) Let's talk about PCIe bus... there is DCA, some other 
non-DCA acceleration that's faster if you are on the same NUMA node as the PCIe 
slot, but fails to work if you aren't... etc.

A lot of the people from Intel, 6WIND, and the kernel people are just thinking 
"this stuff is obvious... we've used it since 200X and it's 2015!" That's true 
if you are a processor / kernel hacker... but if you spent your whole career on 
packet processing or network security like a lot of us app developers might 
have done, that's very orthogonal to Intel-specific and compiler-specific and 
hardware-specific performance hacks... so a lot of us have no real clue how to 
configure and test them all, much less enhance them and make some patches to 
it. We just blindly trust 6WIND and Intel to get it right, because as far as we 
can see, all the DPDK code is pretty clean and readable, and we're pretty sure 
we don't know anything better than what's already coded and put into the 
repository, if we don't have some checklists to follow to enable and test every 
combination, and find any more bugfixes to suggest.

2) A lot of the network adapters DPDK uses, especially when you begin using the 
more crazy accelerations, are either hard to obtain or expensive... for example 
from what I saw in my jobs, the 10 gigabit boards were a minimum ~$250 USD in 
manufacturing quantities. The 2-port gigabit latest-gen Intel board I got was 
$100 USD... I think a lot of higher-ed students and overseas people from less 
developed nations might have a hard time paying for some of this stuff to start 
hacking... some kind of program to get these sort of people some sample gear 
might help.

I also hit difficulties with the virtio-net driver... it doesn't work with the 
virtio-net adapter in Virtualbox... which makes it harder for me to use cool, 
convenient environments configured by the tool Vagrant, to make very simple dev 
VM environments to quickly get new hackers up to speed on my open source 
running just a command or two, and by extension harder for me to show them why 
they should use DPDK for all their cool new network ${GADGET}s.

The same difficulty comes into place if I wanted to do some performance 
patches... I don't have the money to buy the VTune profiler for my spare time 
project, that you would

[dpdk-dev] Performance regression in DPDK 1.8/2.0

[Matthew Hall]

On Apr 27, 2015, at 3:28 PM, Paul Emmerich  wrote:
> Let me know if you need any additional information.
> I'd also be interested in the configuration that resulted in the 20% speed-
> up that was mentioned in the original mbuf patch

Not sure if it's relevant or not, but there was another mail claiming PCIe 
MSI-X wasn't necessarily working in DPDK 2.x. Not sure if that could be causing 
slowdowns when there are drastic volumes of 64-byte packets causing a lot of 
PCI activity.

Also, you are mentioning some specific patches were involved... so I have to 
ask if anybody tried git bisect yet or not. Maybe easier than trying to guess 
at the answer.

Matthew.

[dpdk-dev] What to do about UIO breakage in 2.0

[Matthew Hall]

Stephen,

This mail is a bit confusing for end users of DPDK which might be why you 
didn't get many replies yet.

If I understand this mail right, you're saying that nothing works? Or it works, 
but igb_uio doesn't work, and the performance isn't good because MSI-X is not 
working? I am confused what you're saying exactly.

Previously I think we knew we needed to use igb_uio for almost all the 
non-virtual NIC PMDs, and some of the virtual NIC PMDs also, before they would 
load and get access to the PCIe BARs, etc. for the NICs. But now it sounds 
totally changed so I'm not sure what to reply.

Can you give a use case, from the perspective of the guy trying to bootstrap 
EAL / DPDK, what does this problem do to him if he tries it with DPDK 2.X?

Matthew.

On Apr 27, 2015, at 3:06 PM, Stephen Hemminger  
wrote:

> I raised the issue, but people seem to be ignoring that fact that igb_uio
> was broken by the introduction of UIO PCI generic in 2.0.
> 
> There are three options:
> 1. Remove IGB_UIO only use UIO PCI generic.
>Downside there is no MSI-X support for UIO PCI generic.
> 2. Revert UIO PCI generic support
> 3. Replace both of the above with something better.
> 
> I am working on #3 but it will not be ready for 2.0.1 and there
> is no solution for users of 2.0 and any future stable code.

[dpdk-dev] [PATCH v6 00/13] mbuf: enhancements of mbuf clones

[Thomas Monjalon]

2015-04-24 11:38, Zoltan Kiss:
> On 22/04/15 12:59, Ananyev, Konstantin wrote:
> > From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> > Sent: Wednesday, April 22, 2015 10:57 AM
> >> The first objective of this series is to fix the support of indirect
> >> mbufs when the application reserves a private area in mbufs. It also
> >> removes the limitation that rte_pktmbuf_clone() is only allowed on
> >> direct (non-cloned) mbufs. The series also contains some enhancements
> >> and fixes in the mbuf area that makes the implementation of the
> >> last patches easier.
> >
> > Acked-by: Konstantin Ananyev 
> 
> When does this series get merged?

It was acked on April 22  and your question was 2 days later on April 24.
Does it mean you are expecting it to be merged the day it is acked?
Or do you fear the merging because of a local dev you are working on?
Anyway, everybody seems happy with this version so it's going to be merged.

[dpdk-dev] [PATCH 13/18] i40e: replacement of 'i40e_debug_read_register()'

[Thomas Monjalon]

2015-04-20 16:22, Helin Zhang:
> As base driver provides 'i40e_aq_debug_read_register()', the same
> functional interface of 'i40e_debug_read_register()' can be replaced.
> 
> Signed-off-by: Helin Zhang 
> ---
>  lib/librte_pmd_i40e/i40e_ethdev.c | 22 ++
>  1 file changed, 2 insertions(+), 20 deletions(-)

It should be merged with the patch introducing the function in the base driver.
So it will be easier to check what changed.

[dpdk-dev] [PATCH 12/18] i40e: enhancements of AQ commands and common interfaces

[Thomas Monjalon]

2015-04-20 16:22, Helin Zhang:
> 'LE16_TO_CPU' was added in 'i40e_debug_aq()' to support big-endian
> and little endian correctly. Fix of determing the PF number was
> added for 'i40e_init_shared_code()', which can solve the issue of
> PF pass-through. Also enhancements were added for 'i40e_led_get()'
> and 'i40e_led_set()'. 'i40e_update_link_info()' was removed and
> replaced by 'i40e_aq_get_link_info()' directly.
> 'i40e_aq_debug_read_register()' was added for reading internal
> registers for debug purpose.

It seems there are really several patches in one.
Please split to allow good tracking.

[dpdk-dev] [PATCH 11/18] i40e: support of building both PF and VF driver together

[Thomas Monjalon]

2015-04-20 16:22, Helin Zhang:
> Macros of PF_DRIVER, VF_DRIVER and INTEGRATED_VF were defined to
> support building both PF and VF driver together. PF_DRIVER needs
> to be defined if a build is for PF only, while VF_DRIVER for VF
> only. PF_DRIVER, VF_DRIVER and INTEGRATED_VF are all needed for
> building PF and VF driver together.
> 
> Signed-off-by: Helin Zhang 

As this patch is mostly reversing the logic #?fndef to #ifdef, it
seems the title is not accurate. Is it really adding a new support
or is it only changing the compilation logic?

About title, please use i40e/base: to distinguish patches on the base driver
from the specific PMD ones.

> ---
>  lib/librte_pmd_i40e/Makefile  |  2 +-
>  lib/librte_pmd_i40e/i40e/i40e_adminq.c| 14 +++---
>  lib/librte_pmd_i40e/i40e/i40e_common.c|  6 --
>  lib/librte_pmd_i40e/i40e/i40e_prototype.h |  4 ++--
>  4 files changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/lib/librte_pmd_i40e/Makefile b/lib/librte_pmd_i40e/Makefile
> index a921bf1..22f0716 100644
> --- a/lib/librte_pmd_i40e/Makefile
> +++ b/lib/librte_pmd_i40e/Makefile
> @@ -37,7 +37,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
>  LIB = librte_pmd_i40e.a
>  
>  CFLAGS += -O3
> -CFLAGS += $(WERROR_FLAGS)
> +CFLAGS += $(WERROR_FLAGS) -DPF_DRIVER -DVF_DRIVER -DINTEGRATED_VF
>  
>  EXPORT_MAP := rte_pmd_i40e_version.map
>  
> diff --git a/lib/librte_pmd_i40e/i40e/i40e_adminq.c 
> b/lib/librte_pmd_i40e/i40e/i40e_adminq.c
> index 91b3568..8f9e870 100644
> --- a/lib/librte_pmd_i40e/i40e/i40e_adminq.c
> +++ b/lib/librte_pmd_i40e/i40e/i40e_adminq.c
> @@ -37,7 +37,7 @@ POSSIBILITY OF SUCH DAMAGE.
>  #include "i40e_adminq.h"
>  #include "i40e_prototype.h"
>  
> -#ifndef VF_DRIVER
> +#ifdef PF_DRIVER
>  /**
>   * i40e_is_nvm_update_op - return true if this is an NVM update operation
>   * @desc: API request descriptor
> @@ -48,7 +48,7 @@ STATIC INLINE bool i40e_is_nvm_update_op(struct 
> i40e_aq_desc *desc)
>   desc->opcode == CPU_TO_LE16(i40e_aqc_opc_nvm_update));
>  }
>  
> -#endif /* VF_DRIVER */
> +#endif /* PF_DRIVER */
>  /**
>   *  i40e_adminq_init_regs - Initialize AdminQ registers
>   *  @hw: pointer to the hardware structure
> @@ -559,7 +559,7 @@ enum i40e_status_code i40e_shutdown_arq(struct i40e_hw 
> *hw)
>  enum i40e_status_code i40e_init_adminq(struct i40e_hw *hw)
>  {
>   enum i40e_status_code ret_code;
> -#ifndef VF_DRIVER
> +#ifdef PF_DRIVER
>   u16 eetrack_lo, eetrack_hi;
>   int retry = 0;
>  #endif
> @@ -592,7 +592,7 @@ enum i40e_status_code i40e_init_adminq(struct i40e_hw *hw)
>   if (ret_code != I40E_SUCCESS)
>   goto init_adminq_free_asq;
>  
> -#ifndef VF_DRIVER
> +#ifdef PF_DRIVER
>  #ifdef INTEGRATED_VF
>   /* VF has no need of firmware */
>   if (i40e_is_vf(hw))
> @@ -640,13 +640,13 @@ enum i40e_status_code i40e_init_adminq(struct i40e_hw 
> *hw)
>   I40E_HMC_PROFILE_DEFAULT,
>   0,
>   NULL);
> +#endif /* PF_DRIVER */
>   ret_code = I40E_SUCCESS;
>  
> -#endif /* VF_DRIVER */
>   /* success! */
>   goto init_adminq_exit;
>  
> -#ifndef VF_DRIVER
> +#ifdef PF_DRIVER
>  init_adminq_free_arq:
>   i40e_shutdown_arq(hw);
>  #endif
> @@ -1044,7 +1044,7 @@ clean_arq_element_out:
>   *pending = (ntc > ntu ? hw->aq.arq.count : 0) + (ntu - ntc);
>   i40e_release_spinlock(&hw->aq.arq_spinlock);
>  
> -#ifndef VF_DRIVER
> +#ifdef PF_DRIVER
>   if (i40e_is_nvm_update_op(&e->desc)) {
>   if (hw->aq.nvm_release_on_done) {
>   i40e_release_nvm(hw);
> diff --git a/lib/librte_pmd_i40e/i40e/i40e_common.c 
> b/lib/librte_pmd_i40e/i40e/i40e_common.c
> index 3dd8f04..7a322f1 100644
> --- a/lib/librte_pmd_i40e/i40e/i40e_common.c
> +++ b/lib/librte_pmd_i40e/i40e/i40e_common.c
> @@ -44,7 +44,7 @@ POSSIBILITY OF SUCH DAMAGE.
>   * This function sets the mac type of the adapter based on the
>   * vendor ID and device ID stored in the hw structure.
>   **/
> -#ifdef VF_DRIVER
> +#if defined(INTEGRATED_VF) || defined(VF_DRIVER)
>  enum i40e_status_code i40e_set_mac_type(struct i40e_hw *hw)
>  #else
>  STATIC enum i40e_status_code i40e_set_mac_type(struct i40e_hw *hw)
> @@ -564,7 +564,7 @@ struct i40e_rx_ptype_decoded i40e_ptype_lookup[] = {
>   I40E_PTT_UNUSED_ENTRY(255)
>  };
>  
> -#ifndef VF_DRIVER
> +#ifdef PF_DRIVER
>  
>  /**
>   * i40e_init_shared_code - Initialize the shared code
> @@ -4771,6 +4771,8 @@ enum i40e_status_code 
> i40e_aq_configure_partition_bw(struct i40e_hw *hw,
>  
>   return status;
>  }
> +#endif /* PF_DRIVER */
> +#ifdef VF_DRIVER
>  
>  /**
>   * i40e_aq_send_msg_to_pf
> diff --git a/lib/librte_pmd_i40e/i40e/i40e_prototype.h 
> b/lib/librte_pmd_i40e/i40e/i40e_prototype.h
> index 79f4e38..d143183 100644
> --- a/lib/librte_pmd_i40e/i40e/i40e_prototype.h
> +++ b/lib/librte_pmd_i40e/i40e/i40e_p

[dpdk-dev] [PATCH 03/18] i40e: adjustment of register definitions and relevant

[Thomas Monjalon]

2015-04-20 16:22, Helin Zhang:
> More register definitions and their relevant masks are added
> publically. Also few useless macros are deleted.
> 
> Signed-off-by: Helin Zhang 
> ---
>  lib/librte_pmd_i40e/i40e/i40e_register.h | 1981 
> +-

All these values are not used in the driver, right?

> --- a/lib/librte_pmd_i40e/i40e_ethdev.c
> +++ b/lib/librte_pmd_i40e/i40e_ethdev.c
> @@ -1269,9 +1269,6 @@ i40e_dev_stats_get(struct rte_eth_dev *dev, struct 
> rte_eth_stats *stats)
>   I40E_GLPRT_BPTCL(hw->port),
>   pf->offset_loaded, &os->eth.tx_broadcast,
>   &ns->eth.tx_broadcast);
> - i40e_stat_update_32(hw, I40E_GLPRT_TDPC(hw->port),
> - pf->offset_loaded, &os->eth.tx_discards,
> - &ns->eth.tx_discards);

The relation between this deletion and the rest of the patch is weird.

[dpdk-dev] [RFC PATCH] ethdev: remove old flow director API

[Thomas Monjalon]

2015-04-20 09:45, Venky Venkatesan:
> On 04/20/2015 09:33 AM, Neil Horman wrote:
> > On Mon, Apr 20, 2015 at 04:11:43PM +0200, Thomas Monjalon wrote:
> >> It's time to remove this old API.
> >> It seems some work is still needed to rely only on eth_ctrl API.
> >> At least ixgbe, i40e and testpmd must be fixed.
> >> Jingjing, do you think it's possible to remove all these structures
> >> from rte_ethdev.h?
> >>
> >> Thanks
> >>
> > NAK.
> >
> > I'm certainly not opposed to removing the API's if they are truly no longer
> > needed.  But they have been codified as part of the ABI, so the deprecation
> > schedule needs to be followed.  Given what you've said above, it seems like 
> > that
> > might be worthwhile anyway, as it will provide the needed runway to allow 
> > users
> > to convert to the new API.
> >
> > Neil
> +1 NAK. Agree with Neil.

+1 Agree with you :)

The goal of this RFC proposal is to see how to progress on API cleanup.
There are actually 2 parts:
1/ The flow director functions of rte_ethdev.h were only used for enic in
DPDK 2.0. We could set a deprecation notice to remove them in DPDK 2.2.
2/ Some associated structures are also used for rte_eth_conf.
My question was to check how it would be relevant to remove this rte_fdir_conf.

[dpdk-dev] Performance regression in DPDK 1.8/2.0

[De Lara Guarch, Pablo]

Hi,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pavel Odintsov
> Sent: Monday, April 27, 2015 9:07 AM
> To: Paul Emmerich
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Performance regression in DPDK 1.8/2.0
> 
> Hello!
> 
> I executed deep test of Paul's toolkit and could approve performance
> degradation in 2.0.0.
> 
> On Sun, Apr 26, 2015 at 9:50 PM, Paul Emmerich 
> wrote:
> > Hi,
> >
> > I'm working on a DPDK-based packet generator [1] and I recently tried to
> > upgrade from DPDK 1.7.1 to 2.0.0.
> > However, I noticed that DPDK 1.7.1 is about 25% faster than 2.0.0 for my
> use
> > case.
> >
> > So I ran some basic performance tests on the l2fwd example with DPDK
> 1.7.1,
> > 1.8.0 and 2.0.0.
> > I used an Intel Xeon E5-2620 v3 CPU clocked down to 1.2 GHz in order to
> > ensure that the CPU and not the network bandwidth is the bottleneck.
> > I configured l2fwd to forward between two interfaces of an X540 NIC using
> > only a single CPU core (-q2) and measured the following throughput under
> > full bidirectional load:
> >
> >
> > Version  TP [Mpps] Cycles/Pkt
> > 1.7.118.84 84.925690021
> > 1.8.016.78 95.351609058
> > 2.0.016.40 97.56097561
> >
> > DPDK 1.7.1 is about 15% faster in this scenario. The obvious suspect is the
> > new mbuf structure introduced in DPDK 1.8, so I profiled L1 cache misses:
> >
> > Version   L1 miss ratio
> > 1.7.1 6.5%
> > 1.8.013.8%
> > 2.0.013.4%
> >
> >
> > FWIW the performance results with my packet generator on the same 1.2
> GHz
> > CPU core are:
> >
> > Version  TP [Mpps]  L1 cache miss ratio
> > 1.7  11.77  4.3%
> > 2.0  9.58.4%

Could you tell me how you got the L1 cache miss ratio? Perf?
> >
> >
> > The discussion about the original patch [2] which introduced the new mbuf
> > structure addresses this potential performance degradation and mentions
> that
> > it is somehow mitigated.
> > It even claims a 20% *increase* in performance in a specific scenario.
> > However, that doesn't seem to be the case for both l2fwd and my packet
> > generator.
> >
> > Any ideas how to fix this? A 25% loss in throughput prevents me from
> > upgrading to DPDK 2.0.0. I need the new lcore features and the 40 GBit
> > driver updates, so I can't stay on 1.7.1 forever.

Could you provide more information on how you run the l2fwd app,
in order to try to reproduce the issue:
- L2fwd Command line
- L2fwd initialization (to check memory/CPU/NICs)

Did you change the l2fwd app between versions? L2fwd uses simple rx on 1.7.1,
whereas it uses vector rx on 2.0 (enable IXGBE_DEBUG_INIT to check it).

Last question, I assume you use your traffic generator to get all those numbers.
Which packet format/size did you use? Does your traffic generator take into 
account the Inter-packet gap?

Thanks!

Pablo
> >
> > Paul
> >
> >
> > [1] https://github.com/emmericp/MoonGen
> > [2]
> http://comments.gmane.org/gmane.comp.networking.dpdk.devel/5155
> 
> 
> 
> --
> Sincerely yours, Pavel Odintsov

[dpdk-dev] Beyond DPDK 2.0

[Marc Sune]

On 27/04/15 15:39, Wiles, Keith wrote:
>
> On 4/27/15, 4:52 AM, "Marc Sune"  wrote:
>
>>
>> On 27/04/15 03:41, Wiles, Keith wrote:
>>> On 4/26/15, 4:56 PM, "Neil Horman"  wrote:
>>>
 On Sat, Apr 25, 2015 at 04:08:23PM +, Wiles, Keith wrote:
> 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.
 Actually, IANAL, but I think we can.  The BSD license allows us to fork
 and
 relicense the code I think, under GPL or any other license.  I'm not
 advocating
 for that mind you, just suggesting that its possible should it ever
 become
 needed.

>> 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?
>
 Agreed, this has come up before, off list unfortunately.  The volume of
 patches
 seems to be increasing at such a rate that a single maintainer has
 difficulty
 keeping up.  I proposed that the workload be split out to multiple
 subtrees,
 with prefixes being added to patch subjects on the list for local
 filtering to
 stem the tide.  Specifically I had proposed that the PMD's be split
 into a
 separate subtree, but that received pushback in favor of having each
 library
 having its own separate subtree, with a pilot program being made out of
 the I40e
 driver (which you might note sends pull requests to the list now).  I'd
 still
 like to see all PMD's come under a single subtree, but thats likely an
 argument
 for later.

 That said, Do you think that this patch latency is really a contributor
 to low
 project participation?  It definately a problem, but it seems to me
 that
 this
 sort of issue would lead to people trying to parcitipate, then giving
 up
 (i.e.
 we would see 1-2 emails from an individual, then not see them again).
 I'd need
 to look through the mailing list for such a pattern, but anecdotally
 I've
 not
 seen that happen.  The problem you describe above is definately a
 problem, but
 its one for those individuals who are participating, not for those who
 are
 simply choosing not to.  And I think we need to address both.

> 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.
>
 This is absolutely a problem.  I'd like to think, more than a tool like
 patchwork, a subtree organization to allow some modicum of parallel
 review and
 integration would really be a benefit here.
>>> Subtrees could work, but the 

[dpdk-dev] data copy in vhost-user

[Zoltan Kiss]

On 27/04/15 12:54, Nikita Kalyazin wrote:
> Hi,
>
>
> As far as I understand, DPDK vhost-user implementation requires data copy for 
> either RX or TX (rte_vhost_dequeue_burst() and rte_vhost_enqueue_burst()). It 
> means that two data copies are needed to transfer a packet from one VM to 
> another.
>
> Why is not it possible to eliminate one of the copies (e.g., 
> rte_vhost_enqueue_burst() might set up a reference at vring descriptor to 
> mbuf's data rather than copying the data)?

I'm just guessing, but in case of VM-to-VM traffic the receiving one 
could hold onto the buffer indefinitely, preventing the sender to reuse 
the buffer. That could lead to a DoS in some cases, and shutting down 
the sender would be also tricky. At least in case of Xen 
netback/netfront that's the reason. A reasonable solution for this 
problem is to make sure the buffer is swapped out with a copy after a 
finite time.

Regards,

Zoltan

[dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

[Arthas]

Hi, Olga
Yes, you are right! 

"Mellanox PMD can also be statically compiled with optimized libibverbs and 
libmlx4 that can be downloaded from dpdk.org site."

Only libibverbs tools need compile with shared!  :)
and because my environment is busybox with my custom kernel, so the kernel 
version is very important yet. 

the MLNX_OFED package contain a ofed-docs indicate it! :)



Best Regards!

Kang



 -- Original --
  From:  "Olga Shern";;
 Date:  Mon, Apr 27, 2015 04:50 PM
 To:  "Arthas"; "dev"; 

 Subject:  RE: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!




Hi Kang, 



I am glad you were able to fix the problem.

But I think there is some confusion here, it means that we need have better 
documentation J

First step to work with Mellanox NIC is to install proper MLNX_OFED and FW from 
Mellanox.com

Seems that you did it.

Then you need to run /etc/init.d/openibd restart to load the needed modules.



For DPDK,  you need to configure your card to work as Ethernet, Mellanox VPI 
cards can be either Infiniband or Ethernet.

Use  connectx_port_config to configure it, as you did 

After that you can run ibdev2netdev and ifconfig and verify that you have 
interfaces for Mellanox NIC ports.



Then you can compile DPDK with Mellanox PMD enabled. Mellanox PMD can be 
dynamically linked with the MLNX_OFED installed libibverbs and libmlx4 ? but 
the performance you get is not the best one.

Mellanox PMD can also be statically compiled with optimized libibverbs and 
libmlx4 that can be downloaded from dpdk.org site.



Let me know if it clear.

Best Regards,

Olga   



From: Arthas [mailto:kangzy1...@qq.com] 
Sent: Monday, April 27, 2015 6:07 AM
To: Arthas; Olga Shern; dev
Subject: Re: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!



Hi, Olga,


I think I have solved this problem. 


libibverbs & libmlx4 can't use dpdp.org and can't compile with static linking.


I try use libibverbs-1.1.8mlnx1-OFED.2.4.45.ga305acd.src.rpm & 
libmlx4-1.0.6mlnx1-OFED.2.4.0.1.2.src and compile with dynamic. This two 
package in MLNX_OFED version 2.4-1.0.0 source package.


and I use ofed_script  connectx_port_config  config Card with Ethernet mode .


The testpmd was started with no error! :)





Thanks a million!! :)





Best Regards!
Kang





-- Original --


From:  "Arthas";;


Date:  Mon, Apr 27, 2015 10:37 AM


To:  "Olga Shern"; "dev"; 


Subject:  Re: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!






3KS, Olga,
  My MLNX_OFED version 2.4-1.0.0 and libibverbs & libmlx4 download from 
dpdk.org. 
when i try to run ibdev2netdev , it don't output any message! :(
Here is my environment.
# uname -r
3.10.0-mlx
# lsmod 
mlx4_en 92824 0 - Live 0xa010f000 (O)
mlx4_ib 135033 0 - Live 0xa00e3000 (O)
ib_sa 24721 1 mlx4_ib, Live 0xa00d7000 (O)
ib_mad 31664 2 mlx4_ib,ib_sa, Live 0xa00ca000 (O)
mlx4_core 226516 2 mlx4_en,mlx4_ib, Live 0xa007c000 (O)
ib_uverbs 43309 0 - Live 0xa003f000 (O)
ib_core 79534 4 mlx4_ib,ib_sa,ib_mad,ib_uverbs, Live 0xa001d000 (O)
ib_addr 4273 2 ib_uverbs,ib_core, Live 0xa0017000 (O)
compat 4948 8 mlx4_en,mlx4_ib,ib_sa,ib_mad,mlx4_core,ib_uverbs,ib_core,ib_addr, 
Live 0xa0011000 (O)
# mstflint  -d 02:00.0 q
Image type:  FS2
FW Version:  2.33.5100
FW Release Date: 25.1.2015
Product Version: 02.33.51.00
Rom Info:type=PXE version=3.4.460 devid=4099
Device ID:   4099
Description: Node Port1Port2Sys image
GUIDs:   0002c90300faa480 0002c90300faa481 0002c90300faa482 
0002c90300faa483 
MACs: 0002c9faa481 0002c9faa482
VSD: 
PSID:MT_1090110019
# ibv_devices 
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
device node GUID
--  
# ibv_devinfo  -l
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
0 HCAs found:

/sys/class/infiniband_verbs # ls
abi_version  uverbs0
# find . -name "mlx4*"
./proc/irq/148/mlx4-32 at :02:00.0
./proc/irq/147/mlx4-31 at :02:00.0
./proc/irq/146/mlx4-30 at :02:00.0
./proc/irq/145/mlx4-29 at :02:00.0
./proc/irq/144/mlx4-28 at :02:00.0
./proc/irq/143/mlx4-27 at :02:00.0
./proc/irq/142/mlx4-26 at :02:00.0
./proc/irq/141/mlx4-25 at :02:00.0
./proc/irq/140/mlx4-24 at :02:00.0
./proc/irq/139/mlx4-23 at :02:00.0
./proc/irq/138/mlx4-22 at :02:00.0
./proc/irq/137/mlx4-21 at :02:00.0
./proc/

[dpdk-dev] [PATCH 00/36] Update IXGBE base codes

[Thomas Monjalon]

> > This patch set update IXGBE base codes to the version of cid-10g-shared-
> > code.2015.02.03.
> > and this patch set add 2 new device id as following:
> > #define IXGBE_DEV_ID_X550EM_X_10G_T0x15AD
> > #define IXGBE_DEV_ID_X550EM_X_1G_T 0x15AE
> > 
> > Changchun Ouyang (36):
> >   ixgbe base codes: Code cleanup and minor changes
> >   ixgbe base codes: Debug output macro
> >   ixgbe base codes: Fix bus type issue
> >   ixgbe base codes: Fix link speed issue
> >   ixgbe base codes: Fix early return
> >   ixgbe base codes: Update the CS address
> >   ixgbe base codes: Extract function for management capability
> >   ixgbe base codes: Set phy power
> >   ixgbe base codes: Use mng present function
> >   ixgbe base codes: Get host interface command status
> >   ixgbe base codes: Refine function for host interface command
> >   ixgbe base codes: Refine struct for physical information
> >   ixgbe base codes: Clear Tx pending
> >   ixgbe base codes: Use IOMEM
> >   ixgbe base codes: Update macros
> >   ixgbe base codes: New phy ID
> >   ixgbe base codes: Get bus info
> >   ixgbe base codes: Restructure host interface command
> >   ixgbe base codes: Fix mac type issue
> >   ixgbe base codes: API for setup internal phy
> >   ixgbe base codes: API for set phy power
> >   ixgbe base codes: API for read i2c combined
> >   ixgbe base codes: API for write i2c combined
> >   ixgbe base codes: Support 5G link speed
> >   ixgbe base codes: Refine branch statement
> >   ixgbe base codes: SFP probe
> >   ixgbe base codes: Set LAN ID
> >   ixgbe base codes: Calculate checksum
> >   ixgbe base codes: Command for flow director
> >   ixgbe base codes: Auto-negotiation
> >   ixgbe base codes: Bit-bang mode
> >   ixgbe base codes: Setup kx4 phy
> >   ixgbe base codes: Read/write iosf sb stat
> >   ixgbe base codes: New device id
> >   ixgbe base codes: Update readme
> >   eal: Add 2 device ids for ixgbe
> 
> Acked-by: Jijiang Liu 

Some changes were put in the wrong patch and some patches
required to be merged to improve atomicity.
As it's a long serie, I did these git changes, without impacting
the code itself.
Maybe that I'll ask you to do those changes next time :)

Applied, thanks

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

[Ravi Kerur]

On Mon, Apr 27, 2015 at 6:44 AM, Neil Horman  wrote:

> On Sat, Apr 25, 2015 at 05:09:01PM -0700, Ravi Kerur wrote:
> > 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 <
> nhorman at tuxdriver.com
> > > >
> > > > > > 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 @@
> > > > > >> >

[dpdk-dev] What to do about UIO breakage in 2.0

[Stephen Hemminger]

I raised the issue, but people seem to be ignoring that fact that igb_uio
was broken by the introduction of UIO PCI generic in 2.0.

There are three options:
 1. Remove IGB_UIO only use UIO PCI generic.
Downside there is no MSI-X support for UIO PCI generic.
 2. Revert UIO PCI generic support
 3. Replace both of the above with something better.

I am working on #3 but it will not be ready for 2.0.1 and there
is no solution for users of 2.0 and any future stable code.

[dpdk-dev] data copy in vhost-user

[Nikita Kalyazin]

Hi,


As far as I understand, DPDK vhost-user implementation requires data copy for 
either RX or TX (rte_vhost_dequeue_burst() and rte_vhost_enqueue_burst()). It 
means that two data copies are needed to transfer a packet from one VM to 
another.

Why is not it possible to eliminate one of the copies (e.g., 
rte_vhost_enqueue_burst() might set up a reference at vring descriptor to 
mbuf's data rather than copying the data)?

-- 

Best regards,

Nikita Kalyazin,
n.kalyazin at samsung.com

CE OS Group
Samsung R&D Institute Russia
Tel: +7 (495) 797-25-00 #3816
Tel: +7 (495) 797-25-03
Office #1501, 12-1, Dvintsev str.,
Moscow, 127018, Russia

[dpdk-dev] Beyond DPDK 2.0

[Wiles, Keith]

On 4/27/15, 5:29 AM, "Neil Horman"  wrote:

>On Mon, Apr 27, 2015 at 01:41:11AM +, Wiles, Keith wrote:
>> 
>> 
>> On 4/26/15, 4:56 PM, "Neil Horman"  wrote:
>> 
>> >On Sat, Apr 25, 2015 at 04:08:23PM +, Wiles, Keith wrote:
>> >> 
>> >> 
>> >> 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.
>> >Actually, IANAL, but I think we can.  The BSD license allows us to fork
>> >and
>> >relicense the code I think, under GPL or any other license.  I'm not
>> >advocating
>> >for that mind you, just suggesting that its possible should it ever
>>become
>> >needed.
>> >
>> >> >
>> >> >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?
>> >> 
>> >Agreed, this has come up before, off list unfortunately.  The volume of
>> >patches
>> >seems to be increasing at such a rate that a single maintainer has
>> >difficulty
>> >keeping up.  I proposed that the workload be split out to multiple
>> >subtrees,
>> >with prefixes being added to patch subjects on the list for local
>> >filtering to
>> >stem the tide.  Specifically I had proposed that the PMD's be split
>>into a
>> >separate subtree, but that received pushback in favor of having each
>> >library
>> >having its own separate subtree, with a pilot program being made out of
>> >the I40e
>> >driver (which you might note sends pull requests to the list now).  I'd
>> >still
>> >like to see all PMD's come under a single subtree, but thats likely an
>> >argument
>> >for later.
>> >
>> >That said, Do you think that this patch latency is really a contributor
>> >to low
>> >project participation?  It definately a problem, but it seems to me
>>that
>> >this
>> >sort of issue would lead to people trying to parcitipate, then giving
>>up
>> >(i.e.
>> >we would see 1-2 emails from an individual, then not see them again).
>> >I'd need
>> >to look through the mailing list for such a pattern, but anecdotally
>>I've
>> >not
>> >seen that happen.  The problem you describe above is definately a
>> >problem, but
>> >its one for those individuals who are participating, not for those who
>>are
>> >simply choosing not to.  And I think we need to address both.
>> >
>> >> 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.
>> >> 
>> >This is absolutely a problem.  I'd like to think, more than a tool like
>> >patchwork, a subtree organization to allow some modicum of parallel
>> >review and
>> >integration would really be a benefit here.
>> Subtrees could work, but the real problem I think is the number of
>> commit

[dpdk-dev] Beyond DPDK 2.0

[Wiles, Keith]

On 4/27/15, 4:52 AM, "Marc Sune"  wrote:

>
>
>On 27/04/15 03:41, Wiles, Keith wrote:
>>
>> On 4/26/15, 4:56 PM, "Neil Horman"  wrote:
>>
>>> On Sat, Apr 25, 2015 at 04:08:23PM +, Wiles, Keith wrote:

 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.
>>> Actually, IANAL, but I think we can.  The BSD license allows us to fork
>>> and
>>> relicense the code I think, under GPL or any other license.  I'm not
>>> advocating
>>> for that mind you, just suggesting that its possible should it ever
>>>become
>>> needed.
>>>
> 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?

>>> Agreed, this has come up before, off list unfortunately.  The volume of
>>> patches
>>> seems to be increasing at such a rate that a single maintainer has
>>> difficulty
>>> keeping up.  I proposed that the workload be split out to multiple
>>> subtrees,
>>> with prefixes being added to patch subjects on the list for local
>>> filtering to
>>> stem the tide.  Specifically I had proposed that the PMD's be split
>>>into a
>>> separate subtree, but that received pushback in favor of having each
>>> library
>>> having its own separate subtree, with a pilot program being made out of
>>> the I40e
>>> driver (which you might note sends pull requests to the list now).  I'd
>>> still
>>> like to see all PMD's come under a single subtree, but thats likely an
>>> argument
>>> for later.
>>>
>>> That said, Do you think that this patch latency is really a contributor
>>> to low
>>> project participation?  It definately a problem, but it seems to me
>>>that
>>> this
>>> sort of issue would lead to people trying to parcitipate, then giving
>>>up
>>> (i.e.
>>> we would see 1-2 emails from an individual, then not see them again).
>>> I'd need
>>> to look through the mailing list for such a pattern, but anecdotally
>>>I've
>>> not
>>> seen that happen.  The problem you describe above is definately a
>>> problem, but
>>> its one for those individuals who are participating, not for those who
>>>are
>>> simply choosing not to.  And I think we need to address both.
>>>
 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.

>>> This is absolutely a problem.  I'd like to think, more than a tool like
>>> patchwork, a subtree organization to allow some modicum of parallel
>>> review and
>>> integration would really be a benefit here.
>> Subtrees could work, but the real problem I think is the number of
>> committers must be higher then one. Something like GitHub (and I assume
>> Linux Foundation) have a method to add committers

[dpdk-dev] Beyond DPDK 2.0

[Marc Sune]

On 27/04/15 03:41, Wiles, Keith wrote:
>
> On 4/26/15, 4:56 PM, "Neil Horman"  wrote:
>
>> On Sat, Apr 25, 2015 at 04:08:23PM +, Wiles, Keith wrote:
>>>
>>> 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.
>> Actually, IANAL, but I think we can.  The BSD license allows us to fork
>> and
>> relicense the code I think, under GPL or any other license.  I'm not
>> advocating
>> for that mind you, just suggesting that its possible should it ever become
>> needed.
>>
 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?
>>>
>> Agreed, this has come up before, off list unfortunately.  The volume of
>> patches
>> seems to be increasing at such a rate that a single maintainer has
>> difficulty
>> keeping up.  I proposed that the workload be split out to multiple
>> subtrees,
>> with prefixes being added to patch subjects on the list for local
>> filtering to
>> stem the tide.  Specifically I had proposed that the PMD's be split into a
>> separate subtree, but that received pushback in favor of having each
>> library
>> having its own separate subtree, with a pilot program being made out of
>> the I40e
>> driver (which you might note sends pull requests to the list now).  I'd
>> still
>> like to see all PMD's come under a single subtree, but thats likely an
>> argument
>> for later.
>>
>> That said, Do you think that this patch latency is really a contributor
>> to low
>> project participation?  It definately a problem, but it seems to me that
>> this
>> sort of issue would lead to people trying to parcitipate, then giving up
>> (i.e.
>> we would see 1-2 emails from an individual, then not see them again).
>> I'd need
>> to look through the mailing list for such a pattern, but anecdotally I've
>> not
>> seen that happen.  The problem you describe above is definately a
>> problem, but
>> its one for those individuals who are participating, not for those who are
>> simply choosing not to.  And I think we need to address both.
>>
>>> 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.
>>>
>> This is absolutely a problem.  I'd like to think, more than a tool like
>> patchwork, a subtree organization to allow some modicum of parallel
>> review and
>> integration would really be a benefit here.
> Subtrees could work, but the real problem I think is the number of
> committers must be higher then one. Something like GitHub (and I assume
> Linux Foundation) have a method to add committers to a project. In the
> case of GitHub they just have to have a free GitHub account and they can
> become committers of the project buying the owner of the project enables
> them.
>
> On GitHub they have personal 

[dpdk-dev] Beyond DPDK 2.0

[Neil Horman]

On Mon, Apr 27, 2015 at 01:50:17PM +, Wiles, Keith wrote:
 >> >> 
> >> >This is absolutely a problem.  I'd like to think, more than a tool like
> >> >patchwork, a subtree organization to allow some modicum of parallel
> >> >review and
> >> >integration would really be a benefit here.
> >> Subtrees could work, but the real problem I think is the number of
> >> committers must be higher then one. Something like GitHub (and I assume
> >> Linux Foundation) have a method to add committers to a project. In the
> >> case of GitHub they just have to have a free GitHub account and they can
> >> become committers of the project buying the owner of the project enables
> >> them.
> >> 
> >> On GitHub they have personal accounts and organization accounts I know
> >> only about the personal accounts, but they allow for 5 private repos and
> >> any number of public repos. The organization account has a lot of extra
> >> features that seem better for a DPDK community IMO and should be the one
> >> we use if we decide it is the right direction. We can always give it a
> >> shot for while and keep the dpdk.org and use dev at dpdk.org and its repo
> >> mirrored from GitHub as a transition phase. This way we can fall back to
> >> dpdk.org or move one to something else if we like.
> >> 
> >> https://help.github.com/categories/organizations/
> >> 
> >> The developers could still send patches via email list, but creating a
> >> repo and forking dpdk is easy, then send a pull request.
> >> 
> >I'm not opposed to github per-se, but nothing described above is unique to
> >github. Theres no reason we can't allow multiple comitters to the current
> >tree
> >as hosted on the current server, we just have to configure it as such.
> >
> >And FWIW, the assumption is that, with multiple subtrees, you implicitly
> >have
> >multiple comitters, assuming that pull requests from those subtree
> >maintainers
> >are trusted by the top level tree maintainer.
> >
> >In fact I feel somewhat better about that model as it provides a nice
> >stairstep
> >integration path for new features.
> >
> >Not explicitly opposed to a movement to github, I just feel like it may
> >not
> >address the problem at hand.
> 
> As I see your concerns is creating multiple repos or splitting up the
> current repo, which can be done in a single GitHub org account and they
> all appear on the page. This way we can move the current other repos like
> Pktgen to this location and everyone sees all of the repos in a much
> easier way IMO. The org account at GitHub gives you the multiple
> committers and even teams. I see we only need one team today for DPDK repo
> and then we have something like Pktgen as a different team and so on.
> >
But again, we have, and do this now:
http://dpdk.org/browse/

There are seveal git repositories there, all related to the dpdk, hosted on the
current site.  All we need to do is expand our use of subtrees.  We don't have
to move the product to a new location to make that happen.

Neil

[dpdk-dev] Performance regression in DPDK 1.8/2.0

[Pavel Odintsov]

Hello!

I executed deep test of Paul's toolkit and could approve performance
degradation in 2.0.0.

On Sun, Apr 26, 2015 at 9:50 PM, Paul Emmerich  
wrote:
> Hi,
>
> I'm working on a DPDK-based packet generator [1] and I recently tried to
> upgrade from DPDK 1.7.1 to 2.0.0.
> However, I noticed that DPDK 1.7.1 is about 25% faster than 2.0.0 for my use
> case.
>
> So I ran some basic performance tests on the l2fwd example with DPDK 1.7.1,
> 1.8.0 and 2.0.0.
> I used an Intel Xeon E5-2620 v3 CPU clocked down to 1.2 GHz in order to
> ensure that the CPU and not the network bandwidth is the bottleneck.
> I configured l2fwd to forward between two interfaces of an X540 NIC using
> only a single CPU core (-q2) and measured the following throughput under
> full bidirectional load:
>
>
> Version  TP [Mpps] Cycles/Pkt
> 1.7.118.84 84.925690021
> 1.8.016.78 95.351609058
> 2.0.016.40 97.56097561
>
> DPDK 1.7.1 is about 15% faster in this scenario. The obvious suspect is the
> new mbuf structure introduced in DPDK 1.8, so I profiled L1 cache misses:
>
> Version   L1 miss ratio
> 1.7.1 6.5%
> 1.8.013.8%
> 2.0.013.4%
>
>
> FWIW the performance results with my packet generator on the same 1.2 GHz
> CPU core are:
>
> Version  TP [Mpps]  L1 cache miss ratio
> 1.7  11.77  4.3%
> 2.0  9.58.4%
>
>
> The discussion about the original patch [2] which introduced the new mbuf
> structure addresses this potential performance degradation and mentions that
> it is somehow mitigated.
> It even claims a 20% *increase* in performance in a specific scenario.
> However, that doesn't seem to be the case for both l2fwd and my packet
> generator.
>
> Any ideas how to fix this? A 25% loss in throughput prevents me from
> upgrading to DPDK 2.0.0. I need the new lcore features and the 40 GBit
> driver updates, so I can't stay on 1.7.1 forever.
>
> Paul
>
>
> [1] https://github.com/emmericp/MoonGen
> [2] http://comments.gmane.org/gmane.comp.networking.dpdk.devel/5155



-- 
Sincerely yours, Pavel Odintsov

[dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

[Arthas]

Hi, Olga,
 I think I have solved this problem. 
 libibverbs & libmlx4 can't use dpdp.org and can't compile with static linking.
 I try use libibverbs-1.1.8mlnx1-OFED.2.4.45.ga305acd.src.rpm & 
libmlx4-1.0.6mlnx1-OFED.2.4.0.1.2.src and compile with dynamic. This two 
package in MLNX_OFED version 2.4-1.0.0 source package.
 and I use ofed_script  connectx_port_config  config Card with Ethernet mode .
 The testpmd was started with no error! :)

  Thanks a million!! :)

 Best Regards!
Kang


 -- Original --
  From:  "Arthas";;
 Date:  Mon, Apr 27, 2015 10:37 AM
 To:  "Olga Shern"; "dev"; 

 Subject:  Re: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!



3KS, Olga,
  My MLNX_OFED version 2.4-1.0.0 and libibverbs & libmlx4 download from 
dpdk.org. 
 when i try to run ibdev2netdev , it don't output any message! :(
 Here is my environment.
 # uname -r
3.10.0-mlx
 # lsmod 
mlx4_en 92824 0 - Live 0xa010f000 (O)
mlx4_ib 135033 0 - Live 0xa00e3000 (O)
ib_sa 24721 1 mlx4_ib, Live 0xa00d7000 (O)
ib_mad 31664 2 mlx4_ib,ib_sa, Live 0xa00ca000 (O)
mlx4_core 226516 2 mlx4_en,mlx4_ib, Live 0xa007c000 (O)
ib_uverbs 43309 0 - Live 0xa003f000 (O)
ib_core 79534 4 mlx4_ib,ib_sa,ib_mad,ib_uverbs, Live 0xa001d000 (O)
ib_addr 4273 2 ib_uverbs,ib_core, Live 0xa0017000 (O)
compat 4948 8 mlx4_en,mlx4_ib,ib_sa,ib_mad,mlx4_core,ib_uverbs,ib_core,ib_addr, 
Live 0xa0011000 (O)
 # mstflint  -d 02:00.0 q
Image type:  FS2
FW Version:  2.33.5100
FW Release Date: 25.1.2015
Product Version: 02.33.51.00
Rom Info:type=PXE version=3.4.460 devid=4099
Device ID:   4099
Description: Node Port1Port2Sys image
GUIDs:   0002c90300faa480 0002c90300faa481 0002c90300faa482 
0002c90300faa483 
MACs: 0002c9faa481 0002c9faa482
VSD: 
PSID:MT_1090110019
# ibv_devices 
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
device node GUID
--  
 # ibv_devinfo  -l
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
0 HCAs found:

/sys/class/infiniband_verbs # ls
abi_version  uverbs0
 # find . -name "mlx4*"
./proc/irq/148/mlx4-32 at :02:00.0
./proc/irq/147/mlx4-31 at :02:00.0
./proc/irq/146/mlx4-30 at :02:00.0
./proc/irq/145/mlx4-29 at :02:00.0
./proc/irq/144/mlx4-28 at :02:00.0
./proc/irq/143/mlx4-27 at :02:00.0
./proc/irq/142/mlx4-26 at :02:00.0
./proc/irq/141/mlx4-25 at :02:00.0
./proc/irq/140/mlx4-24 at :02:00.0
./proc/irq/139/mlx4-23 at :02:00.0
./proc/irq/138/mlx4-22 at :02:00.0
./proc/irq/137/mlx4-21 at :02:00.0
./proc/irq/136/mlx4-20 at :02:00.0
./proc/irq/135/mlx4-19 at :02:00.0
./proc/irq/134/mlx4-18 at :02:00.0
./proc/irq/133/mlx4-17 at :02:00.0
./proc/irq/132/mlx4-16 at :02:00.0
./proc/irq/131/mlx4-15 at :02:00.0
./proc/irq/130/mlx4-14 at :02:00.0
./proc/irq/129/mlx4-13 at :02:00.0
./proc/irq/128/mlx4-12 at :02:00.0
./proc/irq/127/mlx4-11 at :02:00.0
./proc/irq/126/mlx4-10 at :02:00.0
./proc/irq/125/mlx4-9 at :02:00.0
./proc/irq/124/mlx4-8 at :02:00.0
./proc/irq/123/mlx4-7 at :02:00.0
./proc/irq/122/mlx4-6 at :02:00.0
./proc/irq/121/mlx4-5 at :02:00.0
./proc/irq/120/mlx4-4 at :02:00.0
./proc/irq/119/mlx4-3 at :02:00.0
./proc/irq/118/mlx4-2 at :02:00.0
./proc/irq/117/mlx4-1 at :02:00.0
./proc/irq/116/mlx4-async at pci::02:00.0
./proc/driver/mlx4_ib
./sys/bus/pci/drivers/mlx4_core
./sys/devices/pci:00/:00:02.0/:02:00.0/mlx4_port1_mtu
./sys/devices/pci:00/:00:02.0/:02:00.0/mlx4_port2_mtu
./sys/devices/pci:00/:00:02.0/:02:00.0/infiniband/mlx4_0
./sys/devices/pci:00/:00:02.0/:02:00.0/mlx4_port1
./sys/devices/pci:00/:00:02.0/:02:00.0/mlx4_port2
./sys/class/infiniband/mlx4_0
./sys/module/ib_sa/holders/mlx4_ib
./sys/module/compat/holders/mlx4_en
./sys/module/compat/holders/mlx4_ib
./sys/module/compat/holders/mlx4_core
./sys/module/mlx4_en
./sys/module/mlx4_ib
./sys/module/ib_mad/holders/mlx4_ib
./sys/module/ib_core/holders/mlx4_ib
./sys/module/mlx4_core
./sys/module/mlx4_core/holders/mlx4_en
./sys/module/mlx4_core/holders/mlx4_ib
./lib/modules/3.10.0-mlx/extra/mlnx-ofa_kernel/drivers/net/ethernet/mellanox/mlx4
./lib/modules/3.10.0-mlx/extra/mlnx-ofa_kernel/drivers/net/ethernet/mellanox/mlx4/mlx4_en.ko
./lib/modules/3.10.0-mlx/extra/mlnx-ofa_kernel/drivers/net/ethernet/mellanox/mlx4/mlx

[dpdk-dev] [PATCH] docs: convert from using inkscape to ImageMagick tools

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Friday, April 24, 2015 2:23 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] docs: convert from using inkscape to
> ImageMagick tools
> 
> Requiring inkscape to convert svg files to png/pdf files, while functional
> is difficult for ephemeral build environments (i.e. build systems in which
> a new build root is setup for each build), as inkscape and its
> dependencies typically totals over 128Mb of code.  Instead, lets use
> ImageMagick tools.  It gives you the same output in a much more compact
> tool suite (512k).

Hi Neil,

The patch works but the pdf output is different. See the following images for 
before and after the patch:

http://imgur.com/GgdXSnF
http://imgur.com/e9AvTza

It looks like a dpi issue but I'm not sure what exactly. Omitting the 
-units/-density options renders the images at the right size but the resolution 
looks slightly worse.

John
-- 

[dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

[Arthas]

3KS, Olga,
  My MLNX_OFED version 2.4-1.0.0 and libibverbs & libmlx4 download from 
dpdk.org. 
 when i try to run ibdev2netdev , it don't output any message! :(
 Here is my environment.
 # uname -r
3.10.0-mlx
 # lsmod 
mlx4_en 92824 0 - Live 0xa010f000 (O)
mlx4_ib 135033 0 - Live 0xa00e3000 (O)
ib_sa 24721 1 mlx4_ib, Live 0xa00d7000 (O)
ib_mad 31664 2 mlx4_ib,ib_sa, Live 0xa00ca000 (O)
mlx4_core 226516 2 mlx4_en,mlx4_ib, Live 0xa007c000 (O)
ib_uverbs 43309 0 - Live 0xa003f000 (O)
ib_core 79534 4 mlx4_ib,ib_sa,ib_mad,ib_uverbs, Live 0xa001d000 (O)
ib_addr 4273 2 ib_uverbs,ib_core, Live 0xa0017000 (O)
compat 4948 8 mlx4_en,mlx4_ib,ib_sa,ib_mad,mlx4_core,ib_uverbs,ib_core,ib_addr, 
Live 0xa0011000 (O)
 # mstflint  -d 02:00.0 q
Image type:  FS2
FW Version:  2.33.5100
FW Release Date: 25.1.2015
Product Version: 02.33.51.00
Rom Info:type=PXE version=3.4.460 devid=4099
Device ID:   4099
Description: Node Port1Port2Sys image
GUIDs:   0002c90300faa480 0002c90300faa481 0002c90300faa482 
0002c90300faa483 
MACs: 0002c9faa481 0002c9faa482
VSD: 
PSID:MT_1090110019
# ibv_devices 
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
device node GUID
--  
 # ibv_devinfo  -l
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
0 HCAs found:

/sys/class/infiniband_verbs # ls
abi_version  uverbs0
 # find . -name "mlx4*"
./proc/irq/148/mlx4-32 at :02:00.0
./proc/irq/147/mlx4-31 at :02:00.0
./proc/irq/146/mlx4-30 at :02:00.0
./proc/irq/145/mlx4-29 at :02:00.0
./proc/irq/144/mlx4-28 at :02:00.0
./proc/irq/143/mlx4-27 at :02:00.0
./proc/irq/142/mlx4-26 at :02:00.0
./proc/irq/141/mlx4-25 at :02:00.0
./proc/irq/140/mlx4-24 at :02:00.0
./proc/irq/139/mlx4-23 at :02:00.0
./proc/irq/138/mlx4-22 at :02:00.0
./proc/irq/137/mlx4-21 at :02:00.0
./proc/irq/136/mlx4-20 at :02:00.0
./proc/irq/135/mlx4-19 at :02:00.0
./proc/irq/134/mlx4-18 at :02:00.0
./proc/irq/133/mlx4-17 at :02:00.0
./proc/irq/132/mlx4-16 at :02:00.0
./proc/irq/131/mlx4-15 at :02:00.0
./proc/irq/130/mlx4-14 at :02:00.0
./proc/irq/129/mlx4-13 at :02:00.0
./proc/irq/128/mlx4-12 at :02:00.0
./proc/irq/127/mlx4-11 at :02:00.0
./proc/irq/126/mlx4-10 at :02:00.0
./proc/irq/125/mlx4-9 at :02:00.0
./proc/irq/124/mlx4-8 at :02:00.0
./proc/irq/123/mlx4-7 at :02:00.0
./proc/irq/122/mlx4-6 at :02:00.0
./proc/irq/121/mlx4-5 at :02:00.0
./proc/irq/120/mlx4-4 at :02:00.0
./proc/irq/119/mlx4-3 at :02:00.0
./proc/irq/118/mlx4-2 at :02:00.0
./proc/irq/117/mlx4-1 at :02:00.0
./proc/irq/116/mlx4-async at pci::02:00.0
./proc/driver/mlx4_ib
./sys/bus/pci/drivers/mlx4_core
./sys/devices/pci:00/:00:02.0/:02:00.0/mlx4_port1_mtu
./sys/devices/pci:00/:00:02.0/:02:00.0/mlx4_port2_mtu
./sys/devices/pci:00/:00:02.0/:02:00.0/infiniband/mlx4_0
./sys/devices/pci:00/:00:02.0/:02:00.0/mlx4_port1
./sys/devices/pci:00/:00:02.0/:02:00.0/mlx4_port2
./sys/class/infiniband/mlx4_0
./sys/module/ib_sa/holders/mlx4_ib
./sys/module/compat/holders/mlx4_en
./sys/module/compat/holders/mlx4_ib
./sys/module/compat/holders/mlx4_core
./sys/module/mlx4_en
./sys/module/mlx4_ib
./sys/module/ib_mad/holders/mlx4_ib
./sys/module/ib_core/holders/mlx4_ib
./sys/module/mlx4_core
./sys/module/mlx4_core/holders/mlx4_en
./sys/module/mlx4_core/holders/mlx4_ib
./lib/modules/3.10.0-mlx/extra/mlnx-ofa_kernel/drivers/net/ethernet/mellanox/mlx4
./lib/modules/3.10.0-mlx/extra/mlnx-ofa_kernel/drivers/net/ethernet/mellanox/mlx4/mlx4_en.ko
./lib/modules/3.10.0-mlx/extra/mlnx-ofa_kernel/drivers/net/ethernet/mellanox/mlx4/mlx4_core.ko
./lib/modules/3.10.0-mlx/extra/mlnx-ofa_kernel/drivers/infiniband/hw/mlx4
./lib/modules/3.10.0-mlx/extra/mlnx-ofa_kernel/drivers/infiniband/hw/mlx4/mlx4_ib.ko
./sdd/tmp/mlx4.driver
./sdd/tmp/mlx4
./sdd/tmp/mlx4/mlx4.hw
./sdd/tmp/mlx4/mlx4.config
./sdd/tmp/mlx4/mlx4.img.2.10.700
./sdd/tmp/etc/modprobe.d/mlx4.conf
./etc/libibverbs.d/mlx4.driver
./etc/modprobe.d/mlx4.conf




 -- Original --
  From:  "Olga Shern";;
 Date:  Sun, Apr 26, 2015 03:28 PM
 To:  "Arthas"; "dev"; 

 Subject:  RE: RE: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!




Hi Kang, 



Sorry for the late response. 

ConnectX-3 VPI card that you have is supported. So there 

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

[Neil Horman]

On Sat, Apr 25, 2015 at 05:09:01PM -0700, Ravi Kerur wrote:
> 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  > > > > tuxdriver.com
> > >
> > > > > 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 
> > > > >> > 

[dpdk-dev] Beyond DPDK 2.0

[Neil Horman]

On Mon, Apr 27, 2015 at 08:38:48AM -0400, Dave Neary wrote:
> Hi,
> 
> On 04/26/2015 05:56 PM, Neil Horman wrote:
> > On Sat, Apr 25, 2015 at 04:08:23PM +, Wiles, Keith wrote:
> >> 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.
> >>
> > I think a group meeting is going to be way too much overhead to manage 
> > properly.
> > You'll get different people every week with agenda that may not line up with
> > code quality, which is really what the review is meant to provide.  I think
> > perhaps a better approach would be to require that that code owners from the
> > maintainer file provide and ACK/NAK on their patches within 3-4 days, and
> > require a corresponding tree maintainer to apply the patch within 7 or so.  
> > That
> > would cap our patch latency.  Likewise, if a patch slips in creating a
> > regression, the author needs to be alerted and given a time window in which 
> > to
> > fix the problem before the offending patch is reverted during the QE cycle.
> 
> What Keith is describing is very similar to a change management/change
> control board you might find for production/IT processes:
> http://en.wikipedia.org/wiki/Change_control_board
> 
> An efficient change management board approves "low overhead" changes
> automatically/very quickly, and focusses on the 10% of changes which
> could be disruptive (and what disruptive means changes from one
> environment to another) - for code it would be any patches that
> potentially conflict, anything that could cause regressions, add
> instability or uncertainty, and any feature which can be implemented
> multiple ways.
> 
> Not saying this would work - I have never seen an open source project
> implement a change management process for handling patches, and
> instinctively I agree with you Neil that it would be a lot of overhead,
> but it's an interesting thought exercise to think how it might work.
> 

I take you're meaning Dave, and it is an interesting thought experiment.  how
would such a change control board mesh with a public review list however?  That
is to say, would such a voting board not insulate decision makers from community
participation?  Perhaps I'm mistaken there, but it seems like allowing a small
group of maintainers make acceptance decisions in a private meeting would
insulate them from individual accountability on a list.

Neil

> Thanks,
> Dave.
> 
> -- 
> Dave Neary - NFV/SDN Community Strategy
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +1-978-399-2182 / Cell: +1-978-799-3338
> 

[dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

[Olga Shern]

OK, great it is clear :)

From: Arthas [mailto:kangzy1...@qq.com]
Sent: Monday, April 27, 2015 12:17 PM
To: Olga Shern; dev
Subject: Re: RE: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

Hi, Olga
Yes, you are right!
"Mellanox PMD can also be statically compiled with optimized libibverbs and 
libmlx4 that can be downloaded from dpdk.org site."
Only libibverbs tools need compile with shared!  :)
and because my environment is busybox with my custom kernel, so the kernel 
version is very important yet.
the MLNX_OFED package contain a ofed-docs indicate it! :)

Best Regards!
Kang

-- Original --
From:  "Olga Shern";mailto:ol...@mellanox.com>>;
Date:  Mon, Apr 27, 2015 04:50 PM
To:  "Arthas"mailto:kangzy1982 at qq.com>>; "dev"mailto:dev at dpdk.org>>;
Subject:  RE: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

Hi Kang,

I am glad you were able to fix the problem.
But I think there is some confusion here, it means that we need have better 
documentation :)
First step to work with Mellanox NIC is to install proper MLNX_OFED and FW from 
Mellanox.com
Seems that you did it.
Then you need to run /etc/init.d/openibd restart to load the needed modules.

For DPDK,  you need to configure your card to work as Ethernet, Mellanox VPI 
cards can be either Infiniband or Ethernet.
Use  connectx_port_config to configure it, as you did
After that you can run ibdev2netdev and ifconfig and verify that you have 
interfaces for Mellanox NIC ports.

Then you can compile DPDK with Mellanox PMD enabled. Mellanox PMD can be 
dynamically linked with the MLNX_OFED installed libibverbs and libmlx4 - but 
the performance you get is not the best one.
Mellanox PMD can also be statically compiled with optimized libibverbs and 
libmlx4 that can be downloaded from dpdk.org site.

Let me know if it clear.
Best Regards,
Olga

From: Arthas [mailto:kangzy1...@qq.com]
Sent: Monday, April 27, 2015 6:07 AM
To: Arthas; Olga Shern; dev
Subject: Re: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

Hi, Olga,
I think I have solved this problem.
libibverbs & libmlx4 can't use dpdp.org and can't compile with static linking.
I try use libibverbs-1.1.8mlnx1-OFED.2.4.45.ga305acd.src.rpm & 
libmlx4-1.0.6mlnx1-OFED.2.4.0.1.2.src and compile with dynamic. This two 
package in MLNX_OFED version 2.4-1.0.0 source package.
and I use ofed_script  connectx_port_config  config Card with Ethernet mode .
The testpmd was started with no error! :)

Thanks a million!! :)

Best Regards!
Kang

-- Original --
From:  "Arthas";mailto:kangzy1...@qq.com>>;
Date:  Mon, Apr 27, 2015 10:37 AM
To:  "Olga Shern"mailto:olgas at mellanox.com>>; 
"dev"mailto:dev at dpdk.org>>;
Subject:  Re: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

3KS, Olga,
  My MLNX_OFED version 2.4-1.0.0 and libibverbs & libmlx4 download from 
dpdk.org.
when i try to run ibdev2netdev , it don't output any message! :(
Here is my environment.
# uname -r
3.10.0-mlx
# lsmod
mlx4_en 92824 0 - Live 0xa010f000 (O)
mlx4_ib 135033 0 - Live 0xa00e3000 (O)
ib_sa 24721 1 mlx4_ib, Live 0xa00d7000 (O)
ib_mad 31664 2 mlx4_ib,ib_sa, Live 0xa00ca000 (O)
mlx4_core 226516 2 mlx4_en,mlx4_ib, Live 0xa007c000 (O)
ib_uverbs 43309 0 - Live 0xa003f000 (O)
ib_core 79534 4 mlx4_ib,ib_sa,ib_mad,ib_uverbs, Live 0xa001d000 (O)
ib_addr 4273 2 ib_uverbs,ib_core, Live 0xa0017000 (O)
compat 4948 8 mlx4_en,mlx4_ib,ib_sa,ib_mad,mlx4_core,ib_uverbs,ib_core,ib_addr, 
Live 0xa0011000 (O)
# mstflint  -d 02:00.0 q
Image type:  FS2
FW Version:  2.33.5100
FW Release Date: 25.1.2015
Product Version: 02.33.51.00
Rom Info:type=PXE version=3.4.460 devid=4099
Device ID:   4099
Description: Node Port1Port2Sys image
GUIDs:   0002c90300faa480 0002c90300faa481 0002c90300faa482 
0002c90300faa483
MACs: 0002c9faa481 0002c9faa482
VSD:
PSID:MT_1090110019
# ibv_devices
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
device node GUID
--  
# ibv_devinfo  -l
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
0 HCAs found:

/sys/class/infiniband_verbs # ls
abi_version  uverbs0
# find . -name "mlx4*"
./proc/irq/148/mlx4-32 at :02:00.0
./proc/irq/147/mlx4-31 at :02:00.0
./proc/irq/146/mlx4-30 at :02:00.0

[dpdk-dev] Beyond DPDK 2.0

[Stephen Hemminger]

On Mon, 27 Apr 2015 08:38:48 -0400
Dave Neary  wrote:

> What Keith is describing is very similar to a change management/change
> control board you might find for production/IT processes:
> http://en.wikipedia.org/wiki/Change_control_board
> 
> An efficient change management board approves "low overhead" changes
> automatically/very quickly, and focusses on the 10% of changes which
> could be disruptive (and what disruptive means changes from one
> environment to another) - for code it would be any patches that
> potentially conflict, anything that could cause regressions, add
> instability or uncertainty, and any feature which can be implemented
> multiple ways.
> 
> Not saying this would work - I have never seen an open source project
> implement a change management process for handling patches, and
> instinctively I agree with you Neil that it would be a lot of overhead,
> but it's an interesting thought exercise to think how it might work

ZMQ has a community process with a simple review process
and a "default YES" policy.
 http://rfc.zeromq.org/spec:22

[dpdk-dev] Beyond DPDK 2.0

[Neil Horman]

On Sun, Apr 26, 2015 at 09:29:13PM -0500, Jim Thompson wrote:
> 
> > On Apr 26, 2015, at 4:56 PM, Neil Horman  wrote:
> > 
> > On Sat, Apr 25, 2015 at 04:08:23PM +, Wiles, Keith wrote:
> >> 
> >> 
> >> 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.
> > Actually, IANAL, but I think we can.  The BSD license allows us to fork and
> > relicense the code I think, under GPL or any other license.  I'm not 
> > advocating
> > for that mind you, just suggesting that its possible should it ever become
> > needed.
> 
> I, on the other hand, am fairly certain that you can not ?relicense BSD 
> licensed code under the GPL (or any other license).
> 
> Were this true at law, then the opposite would also be possible.  (?Don?t 
> like the license?  Just fork!?)
> 
Isn't that in effect, exactly what most of the end users of the DPDK do however?

The 3 clause BSD license states that:
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its contributors
may be used to endorse or promote products derived from this software without
specific prior written permission.

If you build a product based on the DPDK, and statically link it, I presume
there are at least some vendors that are redistributing DPDK binary code using a
non-BSD license?  It may be a de-facto rather than a de-jure relicensing, but
the end result is the same.  The only thing that the BSD license says is that
you have to reproduce this copyright notice if you distribute BSD code.  Theres
nothing that says you can't add further copyright to derivations on that code
that you make.  IANAL, but it seems like this is done quite often.

Regardless, the canonical way to relicense code of course is have all the
copyright holder agree to relicense it under some other license.  Currently as
it stands a quick git scan indicates that 118 individuals are responsible for
the most recent change to every line of code in the dpdk (using git blame on
every file).  Of those 118 fully half belong to intel, or 6wind.  It wouldn't be
hard to hold a meeting and generate an agreement to relicense.

Of course, that won't happen.  BSD licensing is the desired solution here.
Neil

[dpdk-dev] Beyond DPDK 2.0

[Stephen Hemminger]

On Sun, 26 Apr 2015 21:29:13 -0500
Jim Thompson  wrote:

> I, on the other hand, am fairly certain that you can not ?relicense BSD 
> licensed code under the GPL (or any other license).
> 
> Were this true at law, then the opposite would also be possible.  (?Don?t 
> like the license?  Just fork!?)


IANAL but it is possible to go from BSD to GPL and it is done all the time.
The other way is not possible. You only have to see the OpenOffice -> 
LibreOffice
as an example.  LibreOffice can freely take anything out of OpenOffice but
OpenOffice can not take from LibrOffice.

[dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

[Olga Shern]

Hi Kang,

I am glad you were able to fix the problem.
But I think there is some confusion here, it means that we need have better 
documentation ?
First step to work with Mellanox NIC is to install proper MLNX_OFED and FW from 
Mellanox.com
Seems that you did it.
Then you need to run /etc/init.d/openibd restart to load the needed modules.

For DPDK,  you need to configure your card to work as Ethernet, Mellanox VPI 
cards can be either Infiniband or Ethernet.
Use  connectx_port_config to configure it, as you did
After that you can run ibdev2netdev and ifconfig and verify that you have 
interfaces for Mellanox NIC ports.

Then you can compile DPDK with Mellanox PMD enabled. Mellanox PMD can be 
dynamically linked with the MLNX_OFED installed libibverbs and libmlx4 ? but 
the performance you get is not the best one.
Mellanox PMD can also be statically compiled with optimized libibverbs and 
libmlx4 that can be downloaded from dpdk.org site.

Let me know if it clear.
Best Regards,
Olga

From: Arthas [mailto:kangzy1...@qq.com]
Sent: Monday, April 27, 2015 6:07 AM
To: Arthas; Olga Shern; dev
Subject: Re: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

Hi, Olga,
I think I have solved this problem.
libibverbs & libmlx4 can't use dpdp.org and can't compile with static linking.
I try use libibverbs-1.1.8mlnx1-OFED.2.4.45.ga305acd.src.rpm & 
libmlx4-1.0.6mlnx1-OFED.2.4.0.1.2.src and compile with dynamic. This two 
package in MLNX_OFED version 2.4-1.0.0 source package.
and I use ofed_script  connectx_port_config  config Card with Ethernet mode .
The testpmd was started with no error! :)

Thanks a million!! :)

Best Regards!
Kang

-- Original --
From:  "Arthas";mailto:kangzy1...@qq.com>>;
Date:  Mon, Apr 27, 2015 10:37 AM
To:  "Olga Shern"mailto:olgas at mellanox.com>>; 
"dev"mailto:dev at dpdk.org>>;
Subject:  Re: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

3KS, Olga,
  My MLNX_OFED version 2.4-1.0.0 and libibverbs & libmlx4 download from 
dpdk.org.
 when i try to run ibdev2netdev , it don't output any message! :(
 Here is my environment.
 # uname -r
3.10.0-mlx
 # lsmod
mlx4_en 92824 0 - Live 0xa010f000 (O)
mlx4_ib 135033 0 - Live 0xa00e3000 (O)
ib_sa 24721 1 mlx4_ib, Live 0xa00d7000 (O)
ib_mad 31664 2 mlx4_ib,ib_sa, Live 0xa00ca000 (O)
mlx4_core 226516 2 mlx4_en,mlx4_ib, Live 0xa007c000 (O)
ib_uverbs 43309 0 - Live 0xa003f000 (O)
ib_core 79534 4 mlx4_ib,ib_sa,ib_mad,ib_uverbs, Live 0xa001d000 (O)
ib_addr 4273 2 ib_uverbs,ib_core, Live 0xa0017000 (O)
compat 4948 8 mlx4_en,mlx4_ib,ib_sa,ib_mad,mlx4_core,ib_uverbs,ib_core,ib_addr, 
Live 0xa0011000 (O)
 # mstflint  -d 02:00.0 q
Image type:  FS2
FW Version:  2.33.5100
FW Release Date: 25.1.2015
Product Version: 02.33.51.00
Rom Info:type=PXE version=3.4.460 devid=4099
Device ID:   4099
Description: Node Port1Port2Sys image
GUIDs:   0002c90300faa480 0002c90300faa481 0002c90300faa482 
0002c90300faa483
MACs: 0002c9faa481 0002c9faa482
VSD:
PSID:MT_1090110019
# ibv_devices
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
device node GUID
--  
 # ibv_devinfo  -l
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
0 HCAs found:

/sys/class/infiniband_verbs # ls
abi_version  uverbs0
 # find . -name "mlx4*"
./proc/irq/148/mlx4-32 at :02:00.0
./proc/irq/147/mlx4-31 at :02:00.0
./proc/irq/146/mlx4-30 at :02:00.0
./proc/irq/145/mlx4-29 at :02:00.0
./proc/irq/144/mlx4-28 at :02:00.0
./proc/irq/143/mlx4-27 at :02:00.0
./proc/irq/142/mlx4-26 at :02:00.0
./proc/irq/141/mlx4-25 at :02:00.0
./proc/irq/140/mlx4-24 at :02:00.0
./proc/irq/139/mlx4-23 at :02:00.0
./proc/irq/138/mlx4-22 at :02:00.0
./proc/irq/137/mlx4-21 at :02:00.0
./proc/irq/136/mlx4-20 at :02:00.0

[dpdk-dev] Beyond DPDK 2.0

[Jay Rolette]

On Sat, Apr 25, 2015 at 7:10 AM, Neil Horman  wrote:

> 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.
> >
>


>
> 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?
>

(1) was just my response to Luke about what would motivate a company to
submit patches if the license didn't require it (GPL vs BSD discussion).
Maint overhead had little to do with why we decided to use DPDK.

(2) is certainly true enough, but not really all that big of a factor in
the reasons why our participation isn't at some higher level. I'd say there
are two primary factors:

*New Contributors*
Dropping a major patch on a project where we have no history would be
foolish and frustrating. Every open source project has a vibe to it and its
own way of operating. It normally takes some time to figure that out, but
for major contributions, it generally involves a level of trust.

Major code drops or patches aren't generally well received unless it is
from someone that is known and trusted by the community. Building up that
trust ("street cred") normally involves participating in smaller, less
risky ways. Answering questions where you can, small patches to fix bugs,
possibly reviewing code (although this can be iffy as well), etc.

This facilitates understanding the process, who the players are and what
sort of toes you are likely to step on.

It also gives you time to ramp up on the internals of the code and
philosophy/goals of the project better. With DPDK, performance is obviously
more important than portability. Until recently, very little care was given
to API stability or the impact that has on DPDK apps. Both of those are
very different approaches than typical and it affects what you might do
when approaching submitting a patch.

If you want to build up the number of folks contributing, expect them to
start small and make sure it actually GOES somewhere.

The first patch I submitted in mid-December had some quick responses and
questions back-and-forth, but then stalled on a couple of undocumented
minor stylistic things (comment style and use of #ifdefs). I never heard
anything back and 4.5 months later, a simple startup opto is still sitting
there.

The second patch I submitted (also mid-December) got no response at all for
4 months. I've replied to the feedback that came eventually, but once
again, no subsequent answers.

Neither of the patches were important, but the process doesn't exactly
inspire a strong desire to contribute more.

*Different Goals*
I see at least two different sets of people on the mailing list. The heavy
hitters generally have a product reason for their high level of involvement
with DPDK. For Intel and 6Wind, the reasons are pretty obvious. Same deal
with NIC vendors. For large companies, sometimes the reasons are less
obvious, but supporting certain open source projects can be strategic for
them for several reasons.

For this group, improving DPDK itself is important enough to dedicate
resources to. It's a goal in and of itself, even if it isn't the main goal.

The other group are what I'd call "DPDK users". They picked

[dpdk-dev] how to dump rte_mbuf in gdb

[Tim Deng]

Hi,


When I tried to dump a rte_mbuf, gdb complianed "Attempt to resolve a 
variably-sized type which appears in the interior of a structure type", and 
rte_mbuf indeed includes some variably-sized type like MARKER.


Could anyone share a workaround?


Thanks,
Tim

[dpdk-dev] Beyond DPDK 2.0

[Dave Neary]

Hi,

On 04/26/2015 05:56 PM, Neil Horman wrote:
> On Sat, Apr 25, 2015 at 04:08:23PM +, Wiles, Keith wrote:
>> 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.
>>
> I think a group meeting is going to be way too much overhead to manage 
> properly.
> You'll get different people every week with agenda that may not line up with
> code quality, which is really what the review is meant to provide.  I think
> perhaps a better approach would be to require that that code owners from the
> maintainer file provide and ACK/NAK on their patches within 3-4 days, and
> require a corresponding tree maintainer to apply the patch within 7 or so.  
> That
> would cap our patch latency.  Likewise, if a patch slips in creating a
> regression, the author needs to be alerted and given a time window in which to
> fix the problem before the offending patch is reverted during the QE cycle.

What Keith is describing is very similar to a change management/change
control board you might find for production/IT processes:
http://en.wikipedia.org/wiki/Change_control_board

An efficient change management board approves "low overhead" changes
automatically/very quickly, and focusses on the 10% of changes which
could be disruptive (and what disruptive means changes from one
environment to another) - for code it would be any patches that
potentially conflict, anything that could cause regressions, add
instability or uncertainty, and any feature which can be implemented
multiple ways.

Not saying this would work - I have never seen an open source project
implement a change management process for handling patches, and
instinctively I agree with you Neil that it would be a lot of overhead,
but it's an interesting thought exercise to think how it might work.

Thanks,
Dave.

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

[dpdk-dev] Beyond DPDK 2.0

[Neil Horman]

On Mon, Apr 27, 2015 at 01:41:11AM +, Wiles, Keith wrote:
> 
> 
> On 4/26/15, 4:56 PM, "Neil Horman"  wrote:
> 
> >On Sat, Apr 25, 2015 at 04:08:23PM +, Wiles, Keith wrote:
> >> 
> >> 
> >> 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.
> >Actually, IANAL, but I think we can.  The BSD license allows us to fork
> >and
> >relicense the code I think, under GPL or any other license.  I'm not
> >advocating
> >for that mind you, just suggesting that its possible should it ever become
> >needed.
> >
> >> >
> >> >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?
> >> 
> >Agreed, this has come up before, off list unfortunately.  The volume of
> >patches
> >seems to be increasing at such a rate that a single maintainer has
> >difficulty
> >keeping up.  I proposed that the workload be split out to multiple
> >subtrees,
> >with prefixes being added to patch subjects on the list for local
> >filtering to
> >stem the tide.  Specifically I had proposed that the PMD's be split into a
> >separate subtree, but that received pushback in favor of having each
> >library
> >having its own separate subtree, with a pilot program being made out of
> >the I40e
> >driver (which you might note sends pull requests to the list now).  I'd
> >still
> >like to see all PMD's come under a single subtree, but thats likely an
> >argument
> >for later.
> >
> >That said, Do you think that this patch latency is really a contributor
> >to low
> >project participation?  It definately a problem, but it seems to me that
> >this
> >sort of issue would lead to people trying to parcitipate, then giving up
> >(i.e.
> >we would see 1-2 emails from an individual, then not see them again).
> >I'd need
> >to look through the mailing list for such a pattern, but anecdotally I've
> >not
> >seen that happen.  The problem you describe above is definately a
> >problem, but
> >its one for those individuals who are participating, not for those who are
> >simply choosing not to.  And I think we need to address both.
> >
> >> 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.
> >> 
> >This is absolutely a problem.  I'd like to think, more than a tool like
> >patchwork, a subtree organization to allow some modicum of parallel
> >review and
> >integration would really be a benefit here.
> Subtrees could work, but the real problem I think is the number of
> committers must be higher then one. Something like GitHub (and I assume
> Linux Foundation) have a method to add committers to a project. In the
> case of GitHub they just have to have a free GitHub account a

[dpdk-dev] Beyond DPDK 2.0

[Wiles, Keith]

On 4/26/15, 4:56 PM, "Neil Horman"  wrote:

>On Sat, Apr 25, 2015 at 04:08:23PM +, Wiles, Keith wrote:
>> 
>> 
>> 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.
>Actually, IANAL, but I think we can.  The BSD license allows us to fork
>and
>relicense the code I think, under GPL or any other license.  I'm not
>advocating
>for that mind you, just suggesting that its possible should it ever become
>needed.
>
>> >
>> >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?
>> 
>Agreed, this has come up before, off list unfortunately.  The volume of
>patches
>seems to be increasing at such a rate that a single maintainer has
>difficulty
>keeping up.  I proposed that the workload be split out to multiple
>subtrees,
>with prefixes being added to patch subjects on the list for local
>filtering to
>stem the tide.  Specifically I had proposed that the PMD's be split into a
>separate subtree, but that received pushback in favor of having each
>library
>having its own separate subtree, with a pilot program being made out of
>the I40e
>driver (which you might note sends pull requests to the list now).  I'd
>still
>like to see all PMD's come under a single subtree, but thats likely an
>argument
>for later.
>
>That said, Do you think that this patch latency is really a contributor
>to low
>project participation?  It definately a problem, but it seems to me that
>this
>sort of issue would lead to people trying to parcitipate, then giving up
>(i.e.
>we would see 1-2 emails from an individual, then not see them again).
>I'd need
>to look through the mailing list for such a pattern, but anecdotally I've
>not
>seen that happen.  The problem you describe above is definately a
>problem, but
>its one for those individuals who are participating, not for those who are
>simply choosing not to.  And I think we need to address both.
>
>> 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.
>> 
>This is absolutely a problem.  I'd like to think, more than a tool like
>patchwork, a subtree organization to allow some modicum of parallel
>review and
>integration would really be a benefit here.
Subtrees could work, but the real problem I think is the number of
committers must be higher then one. Something like GitHub (and I assume
Linux Foundation) have a method to add committers to a project. In the
case of GitHub they just have to have a free GitHub account and they can
become committers of the project buying the owner of the project enables
them.

On GitHub they have personal accounts and organization accounts I know
only about the personal accounts, but they allow for 5 private repos and
any number of public repos. The organization account has a lot o