[dpdk-dev] Q on contribution to DPDK
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] [PATCH] Small fixes in rte_common.h
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] [PATCH] Fix power_of_2 macro. Avoid branching when calculating RTE_MIN and RTE_MAX.
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] Simple fix in rte_is_power_of_2 and RTE_MIN/RTE_MAX
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 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
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] Fix power_of_2 macro. Avoid branching when calculating RTE_MIN and RTE_MAX.
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 top level 'make clean'
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] 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.
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 v3] test-pmd: Fix pointer aliasing error
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] Fix linuxapp/kni makefile
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] Minor fixes in rte_common.h file.
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] Minor fixes in rte_common.h file.
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] Fix linuxapp/kni Makefile
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] Q on consolidating linuxapp/bsdapp in eal
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 consolidating linuxapp/bsdapp in eal
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 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
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
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
