[dpdk-dev] [PATCH] Fix linuxapp/kni Makefile

2014-12-12 Thread r k 
Subject: [PATCH] Fix linuxapp/kni Makefile

When "make clean" is performed following message is seen
tr: missing operand after '.-'
Two strings must be given when translating.
Try 'tr --help' for more information

due to 'comma' not defined. Include appropriate .mk file.

Signed-off-by: Ravi Kerur 
---
 lib/librte_eal/linuxapp/kni/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_eal/linuxapp/kni/Makefile
b/lib/librte_eal/linuxapp/kni/Makefile
index fb673d9..02ed5da 100644
--- a/lib/librte_eal/linuxapp/kni/Makefile
+++ b/lib/librte_eal/linuxapp/kni/Makefile
@@ -29,6 +29,7 @@
 #   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 #   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

+include $(RTE_SDK)/mk/internal/rte.build-pre.mk
 include $(RTE_SDK)/mk/rte.vars.mk

 #
--
1.9.1

[dpdk-dev] [PATCH] Minor fixes in rte_common.h file.

2014-12-12 Thread r k 
Subject: [PATCH] Minor fixes in rte_common.h file.

Fix rte_is_power_of_2 since 0 is not.
Avoid branching instructions in RTE_MAX and RTE_MIN.

Signed-off-by: Ravi Kerur 
---
 lib/librte_eal/common/include/rte_common.h | 6 +++---
 lib/librte_pmd_e1000/igb_pf.c  | 4 ++--
 lib/librte_pmd_ixgbe/ixgbe_pf.c| 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_common.h
b/lib/librte_eal/common/include/rte_common.h
index 921b91f..e163f35 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -203,7 +203,7 @@ extern int RTE_BUILD_BUG_ON_detected_error;  static
inline int  rte_is_power_of_2(uint32_t n)  {
-   return ((n-1) & n) == 0;
+   return n && !(n & (n - 1));
 }

 /**
@@ -259,7 +259,7 @@ rte_align64pow2(uint64_t v)  #define RTE_MIN(a, b) ({ \
typeof (a) _a = (a); \
typeof (b) _b = (b); \
-   _a < _b ? _a : _b; \
+_b ^ ((_a ^ _b) & -(_a < _b)); \
})

 /**
@@ -268,7 +268,7 @@ rte_align64pow2(uint64_t v)  #define RTE_MAX(a, b) ({ \
typeof (a) _a = (a); \
typeof (b) _b = (b); \
-   _a > _b ? _a : _b; \
+   _a ^ ((_a ^ _b) & -(_a < _b)); \
})

 /*** Other general functions / macros / diff --git
a/lib/librte_pmd_e1000/igb_pf.c b/lib/librte_pmd_e1000/igb_pf.c index
bc3816a..546499c 100644
--- a/lib/librte_pmd_e1000/igb_pf.c
+++ b/lib/librte_pmd_e1000/igb_pf.c
@@ -321,11 +321,11 @@ igb_vf_set_mac_addr(struct rte_eth_dev *dev, uint32_t
vf, uint32_t *msgbuf)  static int  igb_vf_set_multicast(struct rte_eth_dev
*dev, __rte_unused uint32_t vf, uint32_t *msgbuf)  {
-   int i;
+   int16_t i;
uint32_t vector_bit;
uint32_t vector_reg;
uint32_t mta_reg;
-   int entries = (msgbuf[0] & E1000_VT_MSGINFO_MASK) >>
+   int32_t entries = (msgbuf[0] & E1000_VT_MSGINFO_MASK) >>
E1000_VT_MSGINFO_SHIFT;
uint16_t *hash_list = (uint16_t *)&msgbuf[1];
struct e1000_hw *hw =
E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
diff --git a/lib/librte_pmd_ixgbe/ixgbe_pf.c
b/lib/librte_pmd_ixgbe/ixgbe_pf.c index 51da1fd..426caf9 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_pf.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_pf.c
@@ -390,7 +390,7 @@ ixgbe_vf_set_multicast(struct rte_eth_dev *dev,
__rte_unused uint32_t vf, uint32
struct ixgbe_hw *hw =
IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct ixgbe_vf_info *vfinfo =
*(IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private));
-   int nb_entries = (msgbuf[0] & IXGBE_VT_MSGINFO_MASK) >>
+   int32_t nb_entries = (msgbuf[0] & IXGBE_VT_MSGINFO_MASK) >>
IXGBE_VT_MSGINFO_SHIFT;
uint16_t *hash_list = (uint16_t *)&msgbuf[1];
uint32_t mta_idx;
@@ -399,7 +399,7 @@ ixgbe_vf_set_multicast(struct rte_eth_dev *dev,
__rte_unused uint32_t vf, uint32
const uint32_t IXGBE_MTA_BIT_SHIFT = 5;
const uint32_t IXGBE_MTA_BIT_MASK = (0x1 << IXGBE_MTA_BIT_SHIFT) -
1;
uint32_t reg_val;
-   int i;
+   int16_t i;

/* only so many hash values supported */
nb_entries = RTE_MIN(nb_entries, IXGBE_MAX_VF_MC_ENTRIES);
--
1.9.1

[dpdk-dev] [PATCH] Minor fixes in rte_common.h file.

2014-12-12 Thread r k 
Ravi Kerur (1):
  Minor fixes in rte_common.h file.

 lib/librte_eal/common/include/rte_common.h | 6 +++---
 lib/librte_pmd_e1000/igb_pf.c  | 4 ++--
 lib/librte_pmd_ixgbe/ixgbe_pf.c| 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

--
1.9.1

[dpdk-dev] [PATCH] Fix linuxapp/kni makefile

2014-12-12 Thread r k 
Re-sending as per guidelines.

Subject: [PATCH] Fix linuxapp/kni makefile

*** BLURB HERE ***

Ravi Kerur (1):
  Fix linuxapp/kni Makefile

 lib/librte_eal/linuxapp/kni/Makefile | 1 +
 1 file changed, 1 insertion(+)

--
1.9.1

[dpdk-dev] [PATCH v3] test-pmd: Fix pointer aliasing error

2014-12-11 Thread r k 
Thomas, Michael,

Wouldn't it cause unaligned memory access (new changes as well as the
previous code)? Wondering if get_unaligned/put_unaligned macros similar to
the ones used in kernel be ported to user-space?

Thanks,
Ravi

On Wed, Dec 10, 2014 at 4:54 PM, Thomas Monjalon 
wrote:
>
> > > app/test-pmd/csumonly.c: In function 'get_psd_sum':
> > > build/include/rte_ip.h:161: error: dereferencing pointer 'u16'
> > > does break strict-aliasing rules
> > > build/include/rte_ip.h:157: note: initialized from here
> > > ...
> > >
> > > The root cause is that, compile enable strict aliasing by default,
> > > while in function rte_raw_cksum() try to convert 'const char *'
> > > to 'const uint16_t *'.
> > >
> > > This patch is one workaround fix.
> > >
> > > Signed-off-by: Michael Qiu 
> > > ---
> > > v3 --> v2:
> > > use uintptr_t instead of unsigned long to
> > > save pointer.
> > >
> > > v2 --> v1:
> > > Workaround solution instead of shut off the
> > > gcc params.
> >
> > This workaround is to solve the compile issue of GCC strict-aliasing(Two
> > different type pointers should not be point to the same memory address).
> >
> > For GCC 4.4.7 it will definitely occurs if  flags "-fstrict-aliasing"
> > and "-Wall" used.
>
> Acked-by: Thomas Monjalon >
>
> Applied with a comment in the code.
>
> Thanks
> --
> Thomas
>

[dpdk-dev] [PATCH] When "make clean" is executed following error msg is thrown == Clean lib/librte_eal/linuxapp/kni tr: missing operand after '.-' Two strings must be given when translating.

2014-12-10 Thread r k 
Subject: [PATCH] When "make clean" is executed following error msg is
thrown == Clean lib/librte_eal/linuxapp/kni tr: missing operand after '.-'
Two strings must be given when translating.

due to missing "comma" definition in Makefile.

Signed-off-by: Ravi Kerur 
---
 lib/librte_eal/linuxapp/kni/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_eal/linuxapp/kni/Makefile
b/lib/librte_eal/linuxapp/kni/Makefile
index fb673d9..02ed5da 100644
--- a/lib/librte_eal/linuxapp/kni/Makefile
+++ b/lib/librte_eal/linuxapp/kni/Makefile
@@ -29,6 +29,7 @@
 #   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 #   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

+include $(RTE_SDK)/mk/internal/rte.build-pre.mk
 include $(RTE_SDK)/mk/rte.vars.mk

 #
--
1.9.1

[dpdk-dev] [PATCH] Fix top level 'make clean'

2014-12-10 Thread r k 
When 'make clean' is executed, following message is thrown on console due
to missing 'comma' definition.
tr: missing operand after '.-'
Two strings must be given when translating.

Ravi Kerur (1):
  When "make clean" is executed following msg is thrown
 ==Clean lib/librte_eal/linuxapp/kni tr: missing operand after '.-'
Two strings must be given when translating.

 lib/librte_eal/linuxapp/kni/Makefile | 1 +
 1 file changed, 1 insertion(+)

--
1.9.1

[dpdk-dev] [PATCH] Fix power_of_2 macro. Avoid branching when calculating RTE_MIN and RTE_MAX.

2014-12-10 Thread r k 
Just sent another patch explaining the fix and signed-off.

Thanks,
Ravi

On Wed, Dec 10, 2014 at 4:58 AM, Thomas Monjalon
 wrote:
> 2014-12-09 13:05, r k:
>> Subject: [PATCH] Fix power_of_2 macro. Avoid branching when
>> calculating RTE_MIN and RTE_MAX.
>
> Please could you add more explanations about the problem you are solving?
>
> You should also add a Signed-off like explained in this page:
> http://dpdk.org/dev#send
>
> Thanks
> --
> Thomas

[dpdk-dev] [PATCH] Fix rte_is_power_of_2() function since it returns true for zero and zero is not a power of 2. Avoid branching in RTE_MIN and RTE_MAX when calculating minimum and maximum of two numb

2014-12-10 Thread r k 
Subject: [PATCH] Fix rte_is_power_of_2() function since it returns
true for zero and zero is not a power of 2. Avoid branching in RTE_MIN
and RTE_MAX when calculating minimum and maximum of two numbers.

Signed-off-by: Ravi Kerur 
---
 lib/librte_eal/common/include/rte_common.h | 6 +++---
 lib/librte_pmd_e1000/igb_pf.c  | 4 ++--
 lib/librte_pmd_ixgbe/ixgbe_pf.c| 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_common.h
b/lib/librte_eal/common/include/rte_common.h
index 921b91f..21b17ad 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -203,7 +203,7 @@ extern int RTE_BUILD_BUG_ON_detected_error;
static inline int  rte_is_power_of_2(uint32_t n)  {
-   return ((n-1) & n) == 0;
+   return n && !(n & (n - 1));
 }

 /**
@@ -259,7 +259,7 @@ rte_align64pow2(uint64_t v)  #define RTE_MIN(a, b) ({ \
typeof (a) _a = (a); \
typeof (b) _b = (b); \
-   _a < _b ? _a : _b; \
+_b ^ ((_a ^ _b) & -(_a < _b)); \
})

 /**
@@ -268,7 +268,7 @@ rte_align64pow2(uint64_t v)  #define RTE_MAX(a, b) ({ \
typeof (a) _a = (a); \
typeof (b) _b = (b); \
-   _a > _b ? _a : _b; \
+_a ^ ((_a ^ _b) & -(_a < _b)); \
})

 /*** Other general functions / macros / diff --git
a/lib/librte_pmd_e1000/igb_pf.c b/lib/librte_pmd_e1000/igb_pf.c index
bc3816a..546499c 100644
--- a/lib/librte_pmd_e1000/igb_pf.c
+++ b/lib/librte_pmd_e1000/igb_pf.c
@@ -321,11 +321,11 @@ igb_vf_set_mac_addr(struct rte_eth_dev *dev,
uint32_t vf, uint32_t *msgbuf)  static int
igb_vf_set_multicast(struct rte_eth_dev *dev, __rte_unused uint32_t
vf, uint32_t *msgbuf)  {
-   int i;
+   int16_t i;
uint32_t vector_bit;
uint32_t vector_reg;
uint32_t mta_reg;
-   int entries = (msgbuf[0] & E1000_VT_MSGINFO_MASK) >>
+   int32_t entries = (msgbuf[0] & E1000_VT_MSGINFO_MASK) >>
E1000_VT_MSGINFO_SHIFT;
uint16_t *hash_list = (uint16_t *)&msgbuf[1];
struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
diff --git a/lib/librte_pmd_ixgbe/ixgbe_pf.c
b/lib/librte_pmd_ixgbe/ixgbe_pf.c index 51da1fd..426caf9 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_pf.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_pf.c
@@ -390,7 +390,7 @@ ixgbe_vf_set_multicast(struct rte_eth_dev *dev,
__rte_unused uint32_t vf, uint32
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct ixgbe_vf_info *vfinfo =
*(IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private));
-   int nb_entries = (msgbuf[0] & IXGBE_VT_MSGINFO_MASK) >>
+   int32_t nb_entries = (msgbuf[0] & IXGBE_VT_MSGINFO_MASK) >>
IXGBE_VT_MSGINFO_SHIFT;
uint16_t *hash_list = (uint16_t *)&msgbuf[1];
uint32_t mta_idx;
@@ -399,7 +399,7 @@ ixgbe_vf_set_multicast(struct rte_eth_dev *dev,
__rte_unused uint32_t vf, uint32
const uint32_t IXGBE_MTA_BIT_SHIFT = 5;
const uint32_t IXGBE_MTA_BIT_MASK = (0x1 << IXGBE_MTA_BIT_SHIFT) - 1;
uint32_t reg_val;
-   int i;
+   int16_t i;

/* only so many hash values supported */
nb_entries = RTE_MIN(nb_entries, IXGBE_MAX_VF_MC_ENTRIES);
--
1.9.1

[dpdk-dev] [PATCH] Simple fix in rte_is_power_of_2 and RTE_MIN/RTE_MAX

2014-12-10 Thread r k 
Subject: [PATCH] Simple fix in rte_is_power_of_2 and RTE_MIN/RTE_MAX

Number 0 is not a power_of_2, fix it in rte_is_power_of_2 function.
Avoid code which generates branching when calculating min and max.

Ravi Kerur (1):
  Fix rte_is_power_of_2() function since it returns true for zero and
 zero is not a power of 2. Avoid branching in RTE_MIN and
RTE_MAX when calculating minimum and maximum of two numbers.

 lib/librte_eal/common/include/rte_common.h | 6 +++---
 lib/librte_pmd_e1000/igb_pf.c  | 4 ++--
 lib/librte_pmd_ixgbe/ixgbe_pf.c| 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

--
1.9.1

[dpdk-dev] [PATCH] Fix power_of_2 macro. Avoid branching when calculating RTE_MIN and RTE_MAX.

2014-12-09 Thread r k 
Subject: [PATCH] Fix power_of_2 macro. Avoid branching when
calculating RTE_MIN and RTE_MAX.

---
 lib/librte_eal/common/include/rte_common.h | 6 +++---
 lib/librte_pmd_e1000/igb_pf.c  | 4 ++--
 lib/librte_pmd_ixgbe/ixgbe_pf.c| 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_common.h
b/lib/librte_eal/common/include/rte_common.h
index 921b91f..21b17ad 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -203,7 +203,7 @@ extern int RTE_BUILD_BUG_ON_detected_error;
static inline int  rte_is_power_of_2(uint32_t n)  {
-   return ((n-1) & n) == 0;
+   return n && !(n & (n - 1));
 }

 /**
@@ -259,7 +259,7 @@ rte_align64pow2(uint64_t v)  #define RTE_MIN(a, b) ({ \
typeof (a) _a = (a); \
typeof (b) _b = (b); \
-   _a < _b ? _a : _b; \
+_b ^ ((_a ^ _b) & -(_a < _b)); \
})

 /**
@@ -268,7 +268,7 @@ rte_align64pow2(uint64_t v)  #define RTE_MAX(a, b) ({ \
typeof (a) _a = (a); \
typeof (b) _b = (b); \
-   _a > _b ? _a : _b; \
+_a ^ ((_a ^ _b) & -(_a < _b)); \
})

 /*** Other general functions / macros / diff --git
a/lib/librte_pmd_e1000/igb_pf.c b/lib/librte_pmd_e1000/igb_pf.c index
bc3816a..546499c 100644
--- a/lib/librte_pmd_e1000/igb_pf.c
+++ b/lib/librte_pmd_e1000/igb_pf.c
@@ -321,11 +321,11 @@ igb_vf_set_mac_addr(struct rte_eth_dev *dev,
uint32_t vf, uint32_t *msgbuf)  static int
igb_vf_set_multicast(struct rte_eth_dev *dev, __rte_unused uint32_t
vf, uint32_t *msgbuf)  {
-   int i;
+   int16_t i;
uint32_t vector_bit;
uint32_t vector_reg;
uint32_t mta_reg;
-   int entries = (msgbuf[0] & E1000_VT_MSGINFO_MASK) >>
+   int32_t entries = (msgbuf[0] & E1000_VT_MSGINFO_MASK) >>
E1000_VT_MSGINFO_SHIFT;
uint16_t *hash_list = (uint16_t *)&msgbuf[1];
struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
diff --git a/lib/librte_pmd_ixgbe/ixgbe_pf.c
b/lib/librte_pmd_ixgbe/ixgbe_pf.c index 51da1fd..426caf9 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_pf.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_pf.c
@@ -390,7 +390,7 @@ ixgbe_vf_set_multicast(struct rte_eth_dev *dev,
__rte_unused uint32_t vf, uint32
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct ixgbe_vf_info *vfinfo =
*(IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private));
-   int nb_entries = (msgbuf[0] & IXGBE_VT_MSGINFO_MASK) >>
+   int32_t nb_entries = (msgbuf[0] & IXGBE_VT_MSGINFO_MASK) >>
IXGBE_VT_MSGINFO_SHIFT;
uint16_t *hash_list = (uint16_t *)&msgbuf[1];
uint32_t mta_idx;
@@ -399,7 +399,7 @@ ixgbe_vf_set_multicast(struct rte_eth_dev *dev,
__rte_unused uint32_t vf, uint32
const uint32_t IXGBE_MTA_BIT_SHIFT = 5;
const uint32_t IXGBE_MTA_BIT_MASK = (0x1 << IXGBE_MTA_BIT_SHIFT) - 1;
uint32_t reg_val;
-   int i;
+   int16_t i;

/* only so many hash values supported */
nb_entries = RTE_MIN(nb_entries, IXGBE_MAX_VF_MC_ENTRIES);
--
1.9.1

[dpdk-dev] [PATCH] Small fixes in rte_common.h

2014-12-09 Thread r k 
Subject: [PATCH] Small fixes in rte_common.h

Fix a bug in power_of_2 since zero is not.
Avoid branching in RTE_MIN and RTE_MAX macros.

Ravi Kerur (1):
  Fix power_of_2 macro.
  Avoid branching when calculating RTE_MIN and RTE_MAX.

 lib/librte_eal/common/include/rte_common.h | 6 +++---
 lib/librte_pmd_e1000/igb_pf.c  | 4 ++--
 lib/librte_pmd_ixgbe/ixgbe_pf.c| 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

--
1.9.1

[dpdk-dev] Q on consolidating linuxapp/bsdapp in eal

2014-11-21 Thread r k 
Sure will wait for your patchset. If there is anything other than
cleanup that needs to be looked at please let me know. I can start on
that.

Thanks,
Ravi

On Fri, Nov 21, 2014 at 10:23 AM, Thomas Monjalon
 wrote:
> 2014-11-21 10:13, r k:
>> Thanks to Thomas for providing some inputs on this.
>>
>> I am looking at consolidating common code in linuxapp/bsdapp in
>> librte_eal. I have started with header files and had some questions
>> related to it.
>
> Sorry, I didn't know you already start working on it.
> I'm going to send a patchset with such cleanup because it's needed to
> integrate some new options (from old pending patches).
>
> Please wait my patchset to see what remains to clean-up.
>
> Thanks
> --
> Thomas

[dpdk-dev] Q on consolidating linuxapp/bsdapp in eal

2014-11-21 Thread r k 
Hi,

Thanks to Thomas for providing some inputs on this.

I am looking at consolidating common code in linuxapp/bsdapp in
librte_eal. I have started with header files and had some questions
related to it.

1. For some header files for e.g. eal_internal_cfg.h, there are very
minor differences between linux and bsd. In these cases is it ok to
separate out code in header files using
RTE_EXEC_ENV_BSDAPP/RTE_EXEC_ENV_LINUXAPP after moving to common
directory?

2. Files with same names for e.g. rte_lcore.h/rte_per_lcore.h are
present in multiple directories
in librte_eal/common/include
in librte_eal/[linuxapp/bsdapp]/eal/include/exec-env
 Not sure which one is the latest and should be referenced.

Inputs appreciated.

Thanks,
Ravi

[dpdk-dev] Q on contribution to DPDK

2014-11-04 Thread r k 
Hi,

Sure I can start with Clean-up as I need to familiarize with the code
first and then follow-up with Patch reviews.

Thanks,
Ravi

On Sun, Nov 2, 2014 at 1:32 PM, Thomas Monjalon
 wrote:
> Hi,
>
> There are many ways of contributing to DPDK.
> Apart features and fixes, I'd suggest these 4 activities:
> - Bug reporting is critical to satisfy all use cases
> - Patch reviews are very important and help to accelerate their integration
> - Clean-up (e.g. remove doxygen warnings, merge linux and bsd eal, etc)
> - Documentation
>
> Welcome :)
>
> PS: inline replies are preferred in general
>
> --
> Thomas
>
>
> 2014-10-31 15:53, r k:
>> Hi Jim,
>>
>> Thanks for your response. I did check DPDK roadmap and it wasn't clear
>> to me what's available to be implemented. In addition, roadmap lists
>> features but doesn't give description as to what needs to be done. It
>> might be no brainer for original developers but it will definitely
>> help outsiders if some information is provided. Also I was thinking if
>> I can start-off with bug fixing initially to get acquainted with the
>> code and then start off with more things. Please let me know your
>> inputs.
>>
>> Thanks,
>> Ravi
>>
>>
>> On Fri, Oct 31, 2014 at 3:16 PM, St Leger, Jim  
>> wrote:
>> > Ravi:
>> >
>> > DPDK is an open source community project. Anyone and everyone are welcome 
>> > and encouraged to contribute patches. There should not be any concern 
>> > about individual contributors versus company affiliation. What matters is 
>> > useful code.
>> > Please review the Development page on the site for guidance: 
>> > http://dpdk.org/dev
>> >
>> > If you have particular areas of interest or expertise just share that with 
>> > the list.
>> >
>> > I look forward to your contributions.
>> >
>> > Jim
>> >
>> > -Original Message-
>> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of r k
>> > Sent: Friday, October 31, 2014 2:39 PM
>> > To: dev at dpdk.org
>> > Subject: [dpdk-dev] Q on contribution to DPDK
>> >
>> > Hello DPDK development team,
>> >
>> > I am interested in contributing to DPDK and wanted to know a way of 
>> > contributing to it. Some questions
>> >
>> > 1. Will DPDK accept patches from community? I will be individual 
>> > contributor with no affiliation to any company.
>> >
>> > 2. If answer is "Yes" to previous question, should I look at DPDK 
>> > development roadmap and pick one from that?
>> >
>> > Inputs appreciated.
>> >
>> > Thanks,
>> > Ravi
>

[dpdk-dev] Q on contribution to DPDK

2014-10-31 Thread r k 
Hi Jim,

Thanks for your response. I did check DPDK roadmap and it wasn't clear
to me what's available to be implemented. In addition, roadmap lists
features but doesn't give description as to what needs to be done. It
might be no brainer for original developers but it will definitely
help outsiders if some information is provided. Also I was thinking if
I can start-off with bug fixing initially to get acquainted with the
code and then start off with more things. Please let me know your
inputs.

Thanks,
Ravi


On Fri, Oct 31, 2014 at 3:16 PM, St Leger, Jim  
wrote:
> Ravi:
>
> DPDK is an open source community project. Anyone and everyone are welcome and 
> encouraged to contribute patches. There should not be any concern about 
> individual contributors versus company affiliation. What matters is useful 
> code.
> Please review the Development page on the site for guidance: 
> http://dpdk.org/dev
>
> If you have particular areas of interest or expertise just share that with 
> the list.
>
> I look forward to your contributions.
>
> Jim
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of r k
> Sent: Friday, October 31, 2014 2:39 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Q on contribution to DPDK
>
> Hello DPDK development team,
>
> I am interested in contributing to DPDK and wanted to know a way of 
> contributing to it. Some questions
>
> 1. Will DPDK accept patches from community? I will be individual contributor 
> with no affiliation to any company.
>
> 2. If answer is "Yes" to previous question, should I look at DPDK development 
> roadmap and pick one from that?
>
> Inputs appreciated.
>
> Thanks,
> Ravi

[dpdk-dev] Q on code contribution to DPDK

2014-10-31 Thread r k 
Hello DPDK development team,

This is the 3rd email i am sending but it never shows up. I am
subscribed to the list though.

I am interested in contributing to DPDK and wanted to know a way of
contributing to it. Some questions

1. Will DPDK accept patches from community? I will be individual
contributor with no affiliation to any company.

2. If answer is "Yes" to previous question, should I look at DPDK
development roadmap and pick one from that?

Inputs appreciated.

Thanks,
Ravi

[dpdk-dev] Q on contribution to DPDK

2014-10-31 Thread r k 
Hello DPDK development team,

I am interested in contributing to DPDK and wanted to know a way of
contributing to it. Some questions

1. Will DPDK accept patches from community? I will be individual
contributor with no affiliation to any company.

2. If answer is "Yes" to previous question, should I look at DPDK
development roadmap and pick one from that?

Inputs appreciated.

Thanks,
Ravi