[dpdk-dev] [PATCH] examples: new txburst application

[Wiles, Keith]

On 1/30/15, 1:45 PM, "Wiles, Keith"  wrote:

>
>
>Sent from my iPhone
>
>On Jan 30, 2015, at 9:49 AM, Bhavesh Davda  wrote:
>
>>> Did you know pktgen-dpdk?
>>> http://dpdk.org/browse/apps/pktgen-dpdk/tree/README.md
>>> 
>>> Do you think it could replace your application?
>> 
>> [Bhavesh Davda] Yes, I regularly use pktgen-dpdk, and love the app
>>(thanks Keith!) but I couldn't quite get it to do this simplistic job of
>>generating a stream of X-byte UDP packets in burst of Y spread apart by
>>Z microseconds.
>
>Hmmm, sounds like an enhancement request to pktgen is needed here. I will
>look at adding it to pktgen and it is up to everyone if the example is
>reasonable to have. For me it does seem reasonable to include as it maybe
>simpler to setup, but if and when I can add that support to pktgen it may
>no longer be needed.
>
>Let me have a look at adding the support and will let you guys know next
>week.

Looking at the txburst code and your description needing to send a burst
of 220 byte UDP packets with an interval of 50us is mostly doable via
Pktgen. In Pktgen you can setup a packet 220+UDP+other parameters already
in single packet mode or sequence mode. You can set the rate at a given
percentage per second of packets, but you can not set the interval rate
between burst easily. The number of packets in a burst is also adjustable
via the burst command ?set  burst '.

Did I describe the problem here correctly?

The current percentage rate is in whole numbers in Pktgen may not be fine
enough gain rate for some tests. I do have in Pktgen a way to adjust the
time between burst of packets using a debug command to fine tune the
number of clock ticks (HPET) to a given number ?set  tx_cycles
', would that command be useful and solve your given test case?

The tx_cycles option is not listed in the help text :-) Maybe I should
make it not hidden.

>
>Thanks Keith

[dpdk-dev] Making DPDK.org more vendor neutral

[Thomas Monjalon]

Hi Stephen,

2015-01-31 20:47, Stephen Hemminger:
> I think that DPDK.org should be as neutral in all public communications.

I agree and thought it was already OK.

> This bothers me:
> "If you need some specific drivers or networking stacks, you should contact a 
> company that provides such extensions."
> 
> This tag line is a link to page describing 6wind and other vendors leaves a 
> biased taint
> on the initial impression. It would be best to only put in historical data
> about the contributing companies and a vague reference to commercial support 
> being
> available.

Maybe that these words leave a biased taint, as you say.
The goal is to show that DPDK ecosystem can offer some services and support
if needed. It's an important information when choosing to use a software.
We can try to reword it as you suggest.

> It is not like kernel.org has links to SUSE and RHEL. We need to make DPDK.org
> independent.

Linux is very well known and its ecosystem is really huge.
I hope that one day, everybody will be confident enough to not hesitate
choosing DPDK. We made huge progress for 2 years by opening the development
process but I feel it's too early to be compared with kernel.org ;)

Thank you for your report, we'll try to fix it at best.
-- 
Thomas

[dpdk-dev] [PATCH 10/10] ixgbe: spelling fixes

[Stephen Hemminger]

From: Stephen Hemminger 

Signed-off-by: Stephen Hemminger 

---
This file comes from common code and probably has to be fixed upstream.
---
 lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h 
b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h
index c67d462..8aa956e 100644
--- a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h
+++ b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h
@@ -46,7 +46,7 @@ POSSIBILITY OF SUCH DAMAGE.
  *
  * - IXGBE_ERROR_POLLING
  * This category is for errors related to polling/timeout issues and should be
- * used in any case where the timeout occured, or a failure to obtain a lock, 
or
+ * used in any case where the timeout occurred, or a failure to obtain a lock, 
or
  * failure to receive data within the time limit.
  *
  * - IXGBE_ERROR_CAUTION
@@ -1911,7 +1911,7 @@ enum {
 #define IXGBE_MACC_FS  0x0004
 #define IXGBE_MAC_RX2TX_LPBK   0x0002

-/* Veto Bit definiton */
+/* Veto Bit definition */
 #define IXGBE_MMNGC_MNG_VETO   0x0001

 /* LINKS Bit Masks */
-- 
2.1.4

[dpdk-dev] [PATCH 09/10] ring: fix spelling error

[Stephen Hemminger]

From: Stephen Hemminger 

Signed-off-by: Stephen Hemminger 
---
 lib/librte_pmd_ring/rte_eth_ring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_pmd_ring/rte_eth_ring.c 
b/lib/librte_pmd_ring/rte_eth_ring.c
index f685f08..9e76c6b 100644
--- a/lib/librte_pmd_ring/rte_eth_ring.c
+++ b/lib/librte_pmd_ring/rte_eth_ring.c
@@ -421,7 +421,7 @@ static int parse_kvlist (const char *key __rte_unused, 
const char *value, void *
ret = -EINVAL;

if (!name) {
-   RTE_LOG(WARNING, PMD, "command line paramter is empty for ring 
pmd!\n");
+   RTE_LOG(WARNING, PMD, "command line parameter is empty for ring 
pmd!\n");
goto out;
}

-- 
2.1.4

[dpdk-dev] [PATCH 08/10] malloc: spelling fix

[Stephen Hemminger]

From: Stephen Hemminger 

Signed-off-by: Stephen Hemminger 
---
 lib/librte_malloc/rte_malloc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_malloc/rte_malloc.h b/lib/librte_malloc/rte_malloc.h
index 74bb78c..ba9080c 100644
--- a/lib/librte_malloc/rte_malloc.h
+++ b/lib/librte_malloc/rte_malloc.h
@@ -327,7 +327,7 @@ rte_malloc_set_limit(const char *type, size_t max);
  * rte_malloc
  *
  * @param addr
- *   Adress obtained from a previous rte_malloc call
+ *   Address obtained from a previous rte_malloc call
  * @return
  *   NULL on error
  *   otherwise return physical address of the buffer
-- 
2.1.4

[dpdk-dev] [PATCH 07/10] vhost: fix spelling errors

[Stephen Hemminger]

From: Stephen Hemminger 

More codespell

Signed-off-by: Stephen Hemminger 
---
 lib/librte_vhost/eventfd_link/eventfd_link.h | 2 +-
 lib/librte_vhost/rte_virtio_net.h| 2 +-
 lib/librte_vhost/vhost_rxtx.c| 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/librte_vhost/eventfd_link/eventfd_link.h 
b/lib/librte_vhost/eventfd_link/eventfd_link.h
index ea619ec..0711403 100644
--- a/lib/librte_vhost/eventfd_link/eventfd_link.h
+++ b/lib/librte_vhost/eventfd_link/eventfd_link.h
@@ -66,7 +66,7 @@
 #define EVENTFD_COPY 1

 /*
- * arguements for the EVENTFD_COPY ioctl
+ * arguments for the EVENTFD_COPY ioctl
  */
 struct eventfd_copy {
unsigned target_fd; /* fd in the target pid */
diff --git a/lib/librte_vhost/rte_virtio_net.h 
b/lib/librte_vhost/rte_virtio_net.h
index 0bf07c7..f4ebb07 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -188,7 +188,7 @@ int rte_vhost_driver_session_start(void);
 /**
  * This function adds buffers to the virtio devices RX virtqueue. Buffers can
  * be received from the physical port or from another virtual device. A packet
- * count is returned to indicate the number of packets that were succesfully
+ * count is returned to indicate the number of packets that were successfully
  * added to the RX queue.
  * @param queue_id
  *  virtio queue index in mq case
diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index ccfd82f..7a2e935 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -45,7 +45,7 @@
 /**
  * This function adds buffers to the virtio devices RX virtqueue. Buffers can
  * be received from the physical port or from another virtio device. A packet
- * count is returned to indicate the number of packets that are succesfully
+ * count is returned to indicate the number of packets that are successfully
  * added to the RX queue. This function works when mergeable is disabled.
  */
 static inline uint32_t __attribute__((always_inline))
@@ -662,7 +662,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t 
queue_id,
if (seg_avail == 0) {
/*
 * The current segment hasn't
-* room to accomodate more
+* room to accommodate more
 * data.
 */
cur->data_len = seg_offset;
-- 
2.1.4

[dpdk-dev] [PATCH 06/10] examples: fix spelling errors

[Stephen Hemminger]

From: Stephen Hemminger 

Run codespell over examples

Signed-off-by: Stephen Hemminger 
---
 examples/dpdk_qat/crypto.c |  2 +-
 examples/l3fwd-power/main.c|  2 +-
 examples/l3fwd/main.c  |  2 +-
 examples/multi_process/l2fwd_fork/flib.h   |  2 +-
 examples/netmap_compat/lib/compat_netmap.c |  2 +-
 examples/vhost/main.c  | 12 ++--
 examples/vhost_xen/main.c  |  2 +-
 examples/vhost_xen/xenstore_parse.c|  4 ++--
 8 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/examples/dpdk_qat/crypto.c b/examples/dpdk_qat/crypto.c
index f0471e0..b3955f7 100644
--- a/examples/dpdk_qat/crypto.c
+++ b/examples/dpdk_qat/crypto.c
@@ -720,7 +720,7 @@ per_core_crypto_init(uint32_t lcore_id)
}

/*
-* Set the address translation callback for virtual to physcial address
+* Set the address translation callback for virtual to physical address
 * mapping. This will be called by the QAT driver during initialisation 
only.
 */
status = cpaCySetAddressTranslation(qaCoreConf[lcore_id].instanceHandle,
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index f6b55b9..cc8bc1e 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -935,7 +935,7 @@ main_loop(__attribute__((unused)) void *dummy)
 */
rte_delay_us(lcore_idle_hint);
else
-   /* long sleep force runing thread to suspend */
+   /* long sleep force running thread to suspend */
usleep(lcore_idle_hint);

stats[lcore_id].sleep_time += lcore_idle_hint;
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 6f7d7d4..b06f0ba 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -1256,7 +1256,7 @@ processx4_step3(struct rte_mbuf *pkt[FWDSTEP], uint16_t 
dst_port[FWDSTEP])
  * Suppose we have array of destionation ports:
  * dst_port[] = {a, b, c, d,, e, ... }
  * dp1 should contain: , dp2: .
- * We doing 4 comparisions at once and the result is 4 bit mask.
+ * We doing 4 comparsions at once and the result is 4 bit mask.
  * This mask is used as an index into prebuild array of pnum values.
  */
 static inline uint16_t *
diff --git a/examples/multi_process/l2fwd_fork/flib.h 
b/examples/multi_process/l2fwd_fork/flib.h
index 711e3b6..1064c9b 100644
--- a/examples/multi_process/l2fwd_fork/flib.h
+++ b/examples/multi_process/l2fwd_fork/flib.h
@@ -120,7 +120,7 @@ int flib_register_slave_exit_notify(unsigned slave_id,
 /**
  * Assign a lcore ID to non-slave thread.  Non-slave thread refers to thread 
that
  * not created by function rte_eal_remote_launch or rte_eal_mp_remote_launch.
- * These threads can either bind lcore or float among differnt lcores.
+ * These threads can either bind lcore or float among different lcores.
  * This lcore ID will be unique in multi-thread or multi-process DPDK running
  * environment, then it can benefit from using the cache mechanism provided in
  * mempool library.
diff --git a/examples/netmap_compat/lib/compat_netmap.c 
b/examples/netmap_compat/lib/compat_netmap.c
index 1d86ef0..0e8e838 100644
--- a/examples/netmap_compat/lib/compat_netmap.c
+++ b/examples/netmap_compat/lib/compat_netmap.c
@@ -160,7 +160,7 @@ mbuf_to_slot(struct rte_mbuf *mbuf, struct netmap_ring *r, 
uint32_t index)
 /**
  * Given a Netmap ring and a slot index for that ring, construct a dpdk mbuf
  * from the data held in the buffer associated with the slot.
- * Allocation/deallocation of the dpdk mbuf are the responsability of the
+ * Allocation/deallocation of the dpdk mbuf are the responsibility of the
  * caller.
  * Note that mbuf chains are not supported.
  */
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index 3a35359..c42c9d1 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -1326,7 +1326,7 @@ switch_worker(__attribute__((unused)) void *arg)

 /*
  * This function gets available ring number for zero copy rx.
- * Only one thread will call this funciton for a paticular virtio device,
+ * Only one thread will call this funciton for a particular virtio device,
  * so, it is designed as non-thread-safe function.
  */
 static inline uint32_t __attribute__((always_inline))
@@ -1342,7 +1342,7 @@ get_available_ring_num_zcp(struct virtio_net *dev)
 /*
  * This function gets available ring index for zero copy rx,
  * it will retry 'burst_rx_retry_num' times till it get enough ring index.
- * Only one thread will call this funciton for a paticular virtio device,
+ * Only one thread will call this funciton for a particular virtio device,
  * so, it is designed as non-thread-safe function.
  */
 static inline uint32_t __attribute__((always_inline))
@@ -2413,8 +2413,8 @@ destroy_device 

[dpdk-dev] [PATCH 05/10] app: fix spelling errors

[Stephen Hemminger]

From: Stephen Hemminger 

Errors from codespell

Signed-off-by: Stephen Hemminger 
---
 app/test/test_cmdline_cirbuf.c  |  2 +-
 app/test/test_distributor.c |  2 +-
 app/test/test_eal_flags.c   |  4 ++--
 app/test/test_func_reentrancy.c |  4 ++--
 app/test/test_hash.c| 18 +-
 app/test/test_interrupts.c  |  6 +++---
 app/test/test_ivshmem.c |  2 +-
 app/test/test_link_bonding.c|  2 +-
 app/test/test_malloc.c  |  2 +-
 app/test/test_mbuf.c|  2 +-
 app/test/test_spinlock.c|  2 +-
 11 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/app/test/test_cmdline_cirbuf.c b/app/test/test_cmdline_cirbuf.c
index 87f83cc..2c32145 100644
--- a/app/test/test_cmdline_cirbuf.c
+++ b/app/test/test_cmdline_cirbuf.c
@@ -45,7 +45,7 @@
 #define CIRBUF_STR_HEAD " HEAD"
 #define CIRBUF_STR_TAIL "TAIL"

-/* miscelaneous tests - they make bullseye happy */
+/* miscellaneous tests - they make bullseye happy */
 static int
 test_cirbuf_string_misc(void)
 {
diff --git a/app/test/test_distributor.c b/app/test/test_distributor.c
index 9e8c06d..5c22f84 100644
--- a/app/test/test_distributor.c
+++ b/app/test/test_distributor.c
@@ -96,7 +96,7 @@ handle_work(void *arg)
 /* do basic sanity testing of the distributor. This test tests the following:
  * - send 32 packets through distributor with the same tag and ensure they
  *   all go to the one worker
- * - send 32 packets throught the distributor with two different tags and
+ * - send 32 packets through the distributor with two different tags and
  *   verify that they go equally to two different workers.
  * - send 32 packets with different tags through the distributors and
  *   just verify we get all packets back.
diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
index 0a8269c..738bbe4 100644
--- a/app/test/test_eal_flags.c
+++ b/app/test/test_eal_flags.c
@@ -747,7 +747,7 @@ test_dom0_misc_flags(void)

/* check that some general flags don't prevent things from working.
 * All cases, apart from the first, app should run.
-* No futher testing of output done.
+* No further testing of output done.
 */
/* sanity check - failure with invalid option */
const char *argv0[] = {prgname, prefix, mp_flag, "-c", "1", 
"--invalid-opt"};
@@ -855,7 +855,7 @@ test_misc_flags(void)

/* check that some general flags don't prevent things from working.
 * All cases, apart from the first, app should run.
-* No futher testing of output done.
+* No further testing of output done.
 */
/* sanity check - failure with invalid option */
const char *argv0[] = {prgname, prefix, mp_flag, "-c", "1", 
"--invalid-opt"};
diff --git a/app/test/test_func_reentrancy.c b/app/test/test_func_reentrancy.c
index 45928fa..87121da 100644
--- a/app/test/test_func_reentrancy.c
+++ b/app/test/test_func_reentrancy.c
@@ -137,7 +137,7 @@ ring_create_lookup(__attribute__((unused)) void *arg)
return -1;
}

-   /* verify all ring created sucessful */
+   /* verify all ring created successful */
for (i = 0; i < MAX_ITER_TIMES; i++) {
snprintf(ring_name, sizeof(ring_name), "fr_test_%d_%d", 
lcore_self, i);
if (rte_ring_lookup(ring_name) == NULL)
@@ -191,7 +191,7 @@ mempool_create_lookup(__attribute__((unused)) void *arg)
return -1;
}

-   /* verify all ring created sucessful */
+   /* verify all ring created successful */
for (i = 0; i < MAX_ITER_TIMES; i++) {
snprintf(mempool_name, sizeof(mempool_name), "fr_test_%d_%d", 
lcore_self, i);
if (rte_mempool_lookup(mempool_name) == NULL)
diff --git a/app/test/test_hash.c b/app/test/test_hash.c
index 178ec3f..ce7c533 100644
--- a/app/test/test_hash.c
+++ b/app/test/test_hash.c
@@ -953,7 +953,7 @@ static int test_hash_creation_with_bad_parameters(void)
handle = rte_hash_create(NULL);
if (handle != NULL) {
rte_hash_free(handle);
-   printf("Impossible creating hash sucessfully without any 
parameter\n");
+   printf("Impossible creating hash successfully without any 
parameter\n");
return -1;
}

@@ -963,7 +963,7 @@ static int test_hash_creation_with_bad_parameters(void)
handle = rte_hash_create();
if (handle != NULL) {
rte_hash_free(handle);
-   printf("Impossible creating hash sucessfully with entries in 
parameter exceeded\n");
+   printf("Impossible creating hash successfully with entries in 
parameter exceeded\n");
return -1;
}

@@ -973,7 +973,7 @@ static int test_hash_creation_with_bad_parameters(void)
handle = rte_hash_create();
if (handle != NULL) {
rte_hash_free(handle);
-   printf("Impossible 

[dpdk-dev] [PATCH 04/10] ip_frag: fix spelling errors

[Stephen Hemminger]

From: Stephen Hemminger 

Signed-off-by: Stephen Hemminger 
---
 lib/librte_ip_frag/rte_ip_frag.h | 4 ++--
 lib/librte_ip_frag/rte_ipv4_reassembly.c | 2 +-
 lib/librte_ip_frag/rte_ipv6_reassembly.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/librte_ip_frag/rte_ip_frag.h b/lib/librte_ip_frag/rte_ip_frag.h
index 1083d44..6a8f215 100644
--- a/lib/librte_ip_frag/rte_ip_frag.h
+++ b/lib/librte_ip_frag/rte_ip_frag.h
@@ -229,7 +229,7 @@ rte_ipv6_fragment_packet(struct rte_mbuf *pkt_in,
  *   Pointer to the IPv6 fragment extension header.
  * @return
  *   Pointer to mbuf for reassembled packet, or NULL if:
- *   - an error occured.
+ *   - an error occurred.
  *   - not all fragments of the packet are collected yet.
  */
 struct rte_mbuf *rte_ipv6_frag_reassemble_packet(struct rte_ip_frag_tbl *tbl,
@@ -305,7 +305,7 @@ int32_t rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
  *   Pointer to the IPV4 header inside the fragment.
  * @return
  *   Pointer to mbuf for reassebled packet, or NULL if:
- *   - an error occured.
+ *   - an error occurred.
  *   - not all fragments of the packet are collected yet.
  */
 struct rte_mbuf * rte_ipv4_frag_reassemble_packet(struct rte_ip_frag_tbl *tbl,
diff --git a/lib/librte_ip_frag/rte_ipv4_reassembly.c 
b/lib/librte_ip_frag/rte_ipv4_reassembly.c
index 0b8ceeb..fe1d5c6 100644
--- a/lib/librte_ip_frag/rte_ipv4_reassembly.c
+++ b/lib/librte_ip_frag/rte_ipv4_reassembly.c
@@ -111,7 +111,7 @@ ipv4_frag_reassemble(const struct ip_frag_pkt *fp)
  *   Pointer to the IPV4 header inside the fragment.
  * @return
  *   Pointer to mbuf for reassebled packet, or NULL if:
- *   - an error occured.
+ *   - an error occurred.
  *   - not all fragments of the packet are collected yet.
  */
 struct rte_mbuf *
diff --git a/lib/librte_ip_frag/rte_ipv6_reassembly.c 
b/lib/librte_ip_frag/rte_ipv6_reassembly.c
index 71cf721..0b80dce 100644
--- a/lib/librte_ip_frag/rte_ipv6_reassembly.c
+++ b/lib/librte_ip_frag/rte_ipv6_reassembly.c
@@ -147,7 +147,7 @@ ipv6_frag_reassemble(const struct ip_frag_pkt *fp)
  *   Pointer to the IPV6 fragment extension header.
  * @return
  *   Pointer to mbuf for reassembled packet, or NULL if:
- *   - an error occured.
+ *   - an error occurred.
  *   - not all fragments of the packet are collected yet.
  */
 #define MORE_FRAGS(x) (((x) & 0x100) >> 8)
-- 
2.1.4

[dpdk-dev] [PATCH 03/10] eal: fix spelling error

[Stephen Hemminger]

From: Stephen Hemminger 

Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/common/include/rte_alarm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_eal/common/include/rte_alarm.h 
b/lib/librte_eal/common/include/rte_alarm.h
index 4012cd6..c275be1 100644
--- a/lib/librte_eal/common/include/rte_alarm.h
+++ b/lib/librte_eal/common/include/rte_alarm.h
@@ -91,7 +91,7 @@ int rte_eal_alarm_set(uint64_t us, rte_eal_alarm_callback cb, 
void *cb_arg);
  *  the number of canceled alarm callback functions
  *- value greater or equal 0 and rte_errno set to EINPROGRESS, at least one
  *  alarm could not be canceled because cancellation was requested from 
alarm
- *  callback context. Returned value is the number of succesfuly canceled
+ *  callback context. Returned value is the number of successfully canceled
  *  alarm callbacks
  *-  0 and rte_errno set to ENOENT - no alarm found
  *- -1 and rte_errno set to EINVAL - invalid parameter (NULL callback)
-- 
2.1.4

[dpdk-dev] [PATCH 02/10] bond: fix spelling errors

[Stephen Hemminger]

From: Stephen Hemminger 

Bad spelling in comments found by codespell

Signed-off-by: Stephen Hemminger 
---
 lib/librte_pmd_bond/rte_eth_bond_8023ad.c  | 2 +-
 lib/librte_pmd_bond/rte_eth_bond_private.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_pmd_bond/rte_eth_bond_8023ad.c 
b/lib/librte_pmd_bond/rte_eth_bond_8023ad.c
index f1cf81a..dbffc30 100644
--- a/lib/librte_pmd_bond/rte_eth_bond_8023ad.c
+++ b/lib/librte_pmd_bond/rte_eth_bond_8023ad.c
@@ -896,7 +896,7 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev 
*bond_dev, uint8_t slave_id)
sizeof(struct rte_pktmbuf_pool_private), rte_pktmbuf_pool_init,
NULL, rte_pktmbuf_init, NULL, socket_id, MEMPOOL_F_NO_SPREAD);

-   /* Any memory allocation failure in initalization is critical because
+   /* Any memory allocation failure in initialization is critical because
 * resources can't be free, so reinitialization is impossible. */
if (port->mbuf_pool == NULL) {
rte_panic("Slave %u: Failed to create memory pool '%s': %s\n",
diff --git a/lib/librte_pmd_bond/rte_eth_bond_private.h 
b/lib/librte_pmd_bond/rte_eth_bond_private.h
index e01e66b..b47c9a6 100644
--- a/lib/librte_pmd_bond/rte_eth_bond_private.h
+++ b/lib/librte_pmd_bond/rte_eth_bond_private.h
@@ -165,7 +165,7 @@ extern struct eth_dev_ops default_dev_ops;
 int
 valid_bonded_ethdev(struct rte_eth_dev *eth_dev);

-/* Search given slave array to find possition of given id.
+/* Search given slave array to find position of given id.
  * Return slave pos or slaves_count if not found. */
 static inline uint8_t
 find_slave_by_id(uint8_t *slaves, uint8_t slaves_count, uint8_t slave_id) {
-- 
2.1.4

[dpdk-dev] [PATCH 01/10] i40e: spellin fixes

[Stephen Hemminger]

From: Stephen Hemminger 

Spelling errors found with code spell.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_pmd_i40e/i40e_ethdev.c | 8 
 lib/librte_pmd_i40e/i40e_ethdev.h | 2 +-
 lib/librte_pmd_i40e/i40e_rxtx.c   | 6 +++---
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index b47a3d2..07efca5 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -3810,16 +3810,16 @@ i40e_dev_handle_vfr_event(struct rte_eth_dev *dev)
index = abs_vf_id / I40E_UINT32_BIT_SIZE;
offset = abs_vf_id % I40E_UINT32_BIT_SIZE;
val = I40E_READ_REG(hw, I40E_GLGEN_VFLRSTAT(index));
-   /* VFR event occured */
+   /* VFR event occurred */
if (val & (0x1 << offset)) {
int ret;

/* Clear the event first */
I40E_WRITE_REG(hw, I40E_GLGEN_VFLRSTAT(index),
(0x1 << offset));
-   PMD_DRV_LOG(INFO, "VF %u reset occured", abs_vf_id);
+   PMD_DRV_LOG(INFO, "VF %u reset occurred", abs_vf_id);
/**
-* Only notify a VF reset event occured,
+* Only notify a VF reset event occurred,
 * don't trigger another SW reset
 */
ret = i40e_pf_host_vf_reset(>vfs[i], 0);
@@ -5007,7 +5007,7 @@ i40e_pf_config_rss(struct i40e_pf *pf)

/*
 * If both VMDQ and RSS enabled, not all of PF queues are configured.
-* It's necessary to calulate the actual PF queues that are configured.
+* It's necessary to calculate the actual PF queues that are configured.
 */
if (pf->dev_data->dev_conf.rxmode.mq_mode & ETH_MQ_RX_VMDQ_FLAG) {
num = i40e_pf_calc_configured_queues_num(pf);
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.h 
b/lib/librte_pmd_i40e/i40e_ethdev.h
index f913ea9..dc870d2 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.h
+++ b/lib/librte_pmd_i40e/i40e_ethdev.h
@@ -273,7 +273,7 @@ enum I40E_VF_STATE {
 struct i40e_pf_vf {
struct i40e_pf *pf;
struct i40e_vsi *vsi;
-   enum I40E_VF_STATE state; /* The number of queue pairs availiable */
+   enum I40E_VF_STATE state; /* The number of queue pairs available */
uint16_t vf_idx; /* VF index in pf->vfs */
uint16_t lan_nb_qps; /* Actual queues allocated */
uint16_t reset_cnt; /* Total vf reset times */
diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pmd_i40e/i40e_rxtx.c
index 2beae3c..56125cf 100644
--- a/lib/librte_pmd_i40e/i40e_rxtx.c
+++ b/lib/librte_pmd_i40e/i40e_rxtx.c
@@ -1637,7 +1637,7 @@ i40e_dev_rx_queue_stop(struct rte_eth_dev *dev, uint16_t 
rx_queue_id)
rxq = dev->data->rx_queues[rx_queue_id];

/*
-   * rx_queue_id is queue id aplication refers to, while
+   * rx_queue_id is queue id application refers to, while
* rxq->reg_idx is the real queue index.
*/
err = i40e_switch_rx_queue(hw, rxq->reg_idx, FALSE);
@@ -1667,7 +1667,7 @@ i40e_dev_tx_queue_start(struct rte_eth_dev *dev, uint16_t 
tx_queue_id)
txq = dev->data->tx_queues[tx_queue_id];

/*
-   * tx_queue_id is queue id aplication refers to, while
+   * tx_queue_id is queue id application refers to, while
* rxq->reg_idx is the real queue index.
*/
err = i40e_switch_tx_queue(hw, txq->reg_idx, TRUE);
@@ -1690,7 +1690,7 @@ i40e_dev_tx_queue_stop(struct rte_eth_dev *dev, uint16_t 
tx_queue_id)
txq = dev->data->tx_queues[tx_queue_id];

/*
-   * tx_queue_id is queue id aplication refers to, while
+   * tx_queue_id is queue id application refers to, while
* txq->reg_idx is the real queue index.
*/
err = i40e_switch_tx_queue(hw, txq->reg_idx, FALSE);
-- 
2.1.4

[dpdk-dev] Making DPDK.org more vendor neutral

[Stephen Hemminger]

I think that DPDK.org should be as neutral in all public communications.

This bothers me:
"If you need some specific drivers or networking stacks, you should contact a 
company that provides such extensions."

This tag line is a link to page describing 6wind and other vendors leaves a 
biased taint
on the initial impression. It would be best to only put in historical data
about the contributing companies and a vague reference to commercial support 
being
available.

It is not like kernel.org has links to SUSE and RHEL. We need to make DPDK.org
independent.

[dpdk-dev] [PATCH 16/18] fm10k: add PF and VF interrupt handling function

[Neil Horman]

On Fri, Jan 30, 2015 at 01:07:32PM +0800, Chen Jing D(Mark) wrote:
> From: Jeff Shaw 
> 
> 1. Add 2 interrupt handling functions, one for PF and one for VF.
> 2. Enable interrupt after completing initialization of NIC.
> 
This seems to do way more than enable interrupt handling.  Can you be a bit more
desriptive here?
Neil

> Signed-off-by: Jeff Shaw 
> Signed-off-by: Chen Jing D(Mark) 
> ---
>  lib/librte_pmd_fm10k/fm10k_ethdev.c |  268 
> +++
>  1 files changed, 268 insertions(+), 0 deletions(-)
> 
> diff --git a/lib/librte_pmd_fm10k/fm10k_ethdev.c 
> b/lib/librte_pmd_fm10k/fm10k_ethdev.c
> index 40e3a2b..685fa8f 100644
> --- a/lib/librte_pmd_fm10k/fm10k_ethdev.c
> +++ b/lib/librte_pmd_fm10k/fm10k_ethdev.c
> @@ -1325,6 +1325,256 @@ fm10k_rss_hash_conf_get(struct rte_eth_dev *dev,
>   return 0;
>  }
>  
> +static void
> +fm10k_dev_enable_intr_pf(struct rte_eth_dev *dev)
> +{
> + struct fm10k_hw *hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + uint32_t int_map = FM10K_INT_MAP_IMMEDIATE;
> +
> + /* Bind all local non-queue interrupt to vector 0 */
> + int_map |= 0;
> +
> + FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_Mailbox), int_map);
> + FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_PCIeFault), int_map);
> + FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_SwitchUpDown), int_map);
> + FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_SwitchEvent), int_map);
> + FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_SRAM), int_map);
> + FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_VFLR), int_map);
> +
> + /* Enable misc causes */
> + FM10K_WRITE_REG(hw, FM10K_EIMR, FM10K_EIMR_ENABLE(PCA_FAULT) |
> + FM10K_EIMR_ENABLE(THI_FAULT) |
> + FM10K_EIMR_ENABLE(FUM_FAULT) |
> + FM10K_EIMR_ENABLE(MAILBOX) |
> + FM10K_EIMR_ENABLE(SWITCHREADY) |
> + FM10K_EIMR_ENABLE(SWITCHNOTREADY) |
> + FM10K_EIMR_ENABLE(SRAMERROR) |
> + FM10K_EIMR_ENABLE(VFLR));
> +
> + /* Enable ITR 0 */
> + FM10K_WRITE_REG(hw, FM10K_ITR(0), FM10K_ITR_AUTOMASK |
> + FM10K_ITR_MASK_CLEAR);
> + FM10K_WRITE_FLUSH(hw);
> +}
> +
> +static void
> +fm10k_dev_enable_intr_vf(struct rte_eth_dev *dev)
> +{
> + struct fm10k_hw *hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + uint32_t int_map = FM10K_INT_MAP_IMMEDIATE;
> +
> + /* Bind all local non-queue interrupt to vector 0 */
> + int_map |= 0;
> +
> + /* Only INT 0 availiable, other 15 are reserved. */
> + FM10K_WRITE_REG(hw, FM10K_VFINT_MAP, int_map);
> +
> + /* Enable ITR 0 */
> + FM10K_WRITE_REG(hw, FM10K_VFITR(0), FM10K_ITR_AUTOMASK |
> + FM10K_ITR_MASK_CLEAR);
> + FM10K_WRITE_FLUSH(hw);
> +}
> +
> +static int
> +fm10k_dev_handle_fault(struct fm10k_hw *hw, uint32_t eicr)
> +{
> + struct fm10k_fault fault;
> + int err;
> + const char *estr = "Unknown error";
> +
> + /* Process PCA fault */
> + if (eicr & FM10K_EIMR_PCA_FAULT) {
> + err = fm10k_get_fault(hw, FM10K_PCA_FAULT, );
> + if (err)
> + goto error;
> + switch (fault.type) {
> + case PCA_NO_FAULT:
> + estr = "PCA_NO_FAULT"; break;
> + case PCA_UNMAPPED_ADDR:
> + estr = "PCA_UNMAPPED_ADDR"; break;
> + case PCA_BAD_QACCESS_PF:
> + estr = "PCA_BAD_QACCESS_PF"; break;
> + case PCA_BAD_QACCESS_VF:
> + estr = "PCA_BAD_QACCESS_VF"; break;
> + case PCA_MALICIOUS_REQ:
> + estr = "PCA_MALICIOUS_REQ"; break;
> + case PCA_POISONED_TLP:
> + estr = "PCA_POISONED_TLP"; break;
> + case PCA_TLP_ABORT:
> + estr = "PCA_TLP_ABORT"; break;
> + default:
> + goto error;
> + }
> + PMD_LOG(ERR, "%s: %s(%d) Addr:0x%"PRIu64" Spec: 0x%x",
> + estr, fault.func ? "VF" : "PF", fault.func,
> + fault.address, fault.specinfo);
> + }
> +
> + /* Process THI fault */
> + if (eicr & FM10K_EIMR_THI_FAULT) {
> + err = fm10k_get_fault(hw, FM10K_THI_FAULT, );
> + if (err)
> + goto error;
> + switch (fault.type) {
> + case THI_NO_FAULT:
> + estr = "THI_NO_FAULT"; break;
> + case THI_MAL_DIS_Q_FAULT:
> + estr = "THI_MAL_DIS_Q_FAULT"; break;
> + default:
> + goto error;
> + }
> + PMD_LOG(ERR, "%s: %s(%d) Addr:0x%"PRIu64" Spec: 0x%x",
> + estr, fault.func ? "VF" : "PF", fault.func,
> + 

[dpdk-dev] [PATCH 12/18] fm10k: add PF RSS support

[Neil Horman]

On Fri, Jan 30, 2015 at 01:07:28PM +0800, Chen Jing D(Mark) wrote:
> From: Jeff Shaw 
> 
> 1. Configure RSS in fm10k_dev_rx_init function.
> 2. Add fm10k_rss_hash_update and fm10k_rss_hash_conf_get to get
>and inquery RSS configuration.
> 
> Signed-off-by: Jeff Shaw 
> Signed-off-by: Chen Jing D(Mark) 
> ---
>  lib/librte_pmd_fm10k/fm10k_ethdev.c |  156 
> +++
>  1 files changed, 156 insertions(+), 0 deletions(-)
> 
> diff --git a/lib/librte_pmd_fm10k/fm10k_ethdev.c 
> b/lib/librte_pmd_fm10k/fm10k_ethdev.c
> index 9907906..4711047 100644
> --- a/lib/librte_pmd_fm10k/fm10k_ethdev.c
> +++ b/lib/librte_pmd_fm10k/fm10k_ethdev.c
> @@ -269,6 +269,78 @@ fm10k_dev_configure(struct rte_eth_dev *dev)
>   return 0;
>  }
>  
> +static void
> +fm10k_dev_mq_rx_configure(struct rte_eth_dev *dev)
> +{
> + struct fm10k_hw *hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + struct rte_eth_conf *dev_conf = >data->dev_conf;
> + uint32_t mrqc, *key, i, reta, j;
> + uint64_t hf;
> +
> +#define RSS_KEY_SIZE 40
> + static uint8_t rss_intel_key[RSS_KEY_SIZE] = {
> + 0x6D, 0x5A, 0x56, 0xDA, 0x25, 0x5B, 0x0E, 0xC2,
> + 0x41, 0x67, 0x25, 0x3D, 0x43, 0xA3, 0x8F, 0xB0,
> + 0xD0, 0xCA, 0x2B, 0xCB, 0xAE, 0x7B, 0x30, 0xB4,
> + 0x77, 0xCB, 0x2D, 0xA3, 0x80, 0x30, 0xF2, 0x0C,
> + 0x6A, 0x42, 0xB7, 0x3B, 0xBE, 0xAC, 0x01, 0xFA,
> + };
> +
> + if (dev->data->nb_rx_queues == 1 ||
> + dev_conf->rxmode.mq_mode != ETH_MQ_RX_RSS ||
> + dev_conf->rx_adv_conf.rss_conf.rss_hf == 0)
> + return;
> +
> + /* random key is rss_intel_key (default) or user provided (rss_key) */
> + if (dev_conf->rx_adv_conf.rss_conf.rss_key == NULL)
> + key = (uint32_t *)rss_intel_key;
Its not really random if its statically allocated and assigned.  The kernel has
started randomizing these default keys, it seems like a sensible thing to do
here as well, as this is the init path and not performance sensitive

Neil

[dpdk-dev] [PATCH 04/18] fm10k: add fm10k device id

[David Marchand]

On Sat, Jan 31, 2015 at 5:32 PM, Neil Horman  wrote:

> On Sat, Jan 31, 2015 at 05:07:28PM +0100, David Marchand wrote:
> > In the end, we miss something to have dpdk work automatically like it
> used
> > to be, before the pci devices ids were stripped out of igb_uio.
> >
> > I can see two solutions :
> > - all pmds export the pci device ids they support (this sounds like
> > modalias :-)) or they register into the eal that exports this information
> > for use by application, but to me the application should not bother with
> > this ...
> > - the pmd handles this automatically (like binding/unbinding on a kernel
> > driver), with a _runtime_ option to enable this behavior (default being
> "no
> > automatic bind")
> >
> > Comments ? Ideas ?
> >
> I like the modalias idea, as it transports a table for uio/vfio to
> identify with
> the binary that needs it, preventing a possible discrepancy in what the
> core
> dpdk library identifies as supported devices and what the pmd DSO's
> actually do
> support.
>

Yes, but if a pmd can do this itself alone, there is no discrepancy either.

Thinking aloud ...
As long as the pmd does all the magic bindings, the dpdk core does not need
to know about it.
And if the dpdk core really needs to know about this (I can see no use case
here, just want to avoid being blocked later) a dynamic register system
would be fine too.



> To implement it we would either provide our own linker script or have to
> do some
> other make trickery.  The linker script is a bit more labor intensive, but
> might
> provide some future benefit (if you see a need for non-standard sections
> that
> you would like to suck into a given DSO in the future).  Make trickery
> would be
> more straightforward, but requires that we add some additional make
> targets to
> build out the dynamic table to be readable by outside utilities.  Maybe we
> could
> use objcopy to add in a separate section after the dso link.  Not sure yet
>

Not sure either, I just think we may reinvent the wheel :-)


-- 
David Marchand

[dpdk-dev] [PATCH 04/18] fm10k: add fm10k device id

[David Marchand]

On Sat, Jan 31, 2015 at 3:19 PM, Neil Horman  wrote:

> On Fri, Jan 30, 2015 at 01:07:20PM +0800, Chen Jing D(Mark) wrote:
> > From: Jeff Shaw 
> >
> > Add fm10k device ID list into rte_pci_dev_ids.h.
> >
> > Signed-off-by: Jeff Shaw 
> > Signed-off-by: Chen Jing D(Mark) 
> > ---
> >  lib/librte_eal/common/include/rte_pci_dev_ids.h |   22
> ++
> >  1 files changed, 22 insertions(+), 0 deletions(-)
> >
> > diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
> b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > index c922de9..f54800e 100644
> > --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > +++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > @@ -132,6 +132,14 @@
> >  #define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
> >  #endif
> >
> > +#ifndef RTE_PCI_DEV_ID_DECL_FM10K
> > +#define RTE_PCI_DEV_ID_DECL_FM10K(vend, dev)
> > +#endif
> > +
> > +#ifndef RTE_PCI_DEV_ID_DECL_FM10KVF
> > +#define RTE_PCI_DEV_ID_DECL_FM10KVF(vend, dev)
> > +#endif
> > +
> I know this isn't the job of this patch series, but I don't really
> understand
> why we bother with this pattern for filling out pci id tables.  A PMD
> supports
> specific hardware, we might as well use the generic RTE_PCI_DEVICE macro
> in the
> driver rather than creating a FM10K specific wrapper, only to have to do
> some
> ifdef trickery in the rte_cpi_dev_ids file and some include magic to fill
> it
> out.
>

+1


> I'd suggest that you just use RTE_PCI_DEVICE macro here, and make your own
> table
> (keep the specific device id values in the common file.  Then we can clean
> out
> the macro maggic in a later update.
>

If we are going that way, my only concern is that this makes it hard to
"discover" the pci devices that need to be bound to igb_uio/vfio/whatever
kernel driver, and so we must rely either on a global list (like this
rte_pci_dev_ids.h) or on scripts with hardcoded pci device ids in them ...

In the end, we miss something to have dpdk work automatically like it used
to be, before the pci devices ids were stripped out of igb_uio.

I can see two solutions :
- all pmds export the pci device ids they support (this sounds like
modalias :-)) or they register into the eal that exports this information
for use by application, but to me the application should not bother with
this ...
- the pmd handles this automatically (like binding/unbinding on a kernel
driver), with a _runtime_ option to enable this behavior (default being "no
automatic bind")

Comments ? Ideas ?

-- 
David Marchand

[dpdk-dev] [PATCH 01/10] i40e: spellin fixes

[Neil Horman]

On Sat, Jan 31, 2015 at 08:51:53PM +, Stephen Hemminger wrote:
> From: Stephen Hemminger 
> 
> Spelling errors found with code spell.
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  lib/librte_pmd_i40e/i40e_ethdev.c | 8 
>  lib/librte_pmd_i40e/i40e_ethdev.h | 2 +-
>  lib/librte_pmd_i40e/i40e_rxtx.c   | 6 +++---
>  3 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
> b/lib/librte_pmd_i40e/i40e_ethdev.c
> index b47a3d2..07efca5 100644
> --- a/lib/librte_pmd_i40e/i40e_ethdev.c
> +++ b/lib/librte_pmd_i40e/i40e_ethdev.c
> @@ -3810,16 +3810,16 @@ i40e_dev_handle_vfr_event(struct rte_eth_dev *dev)
>   index = abs_vf_id / I40E_UINT32_BIT_SIZE;
>   offset = abs_vf_id % I40E_UINT32_BIT_SIZE;
>   val = I40E_READ_REG(hw, I40E_GLGEN_VFLRSTAT(index));
> - /* VFR event occured */
> + /* VFR event occurred */
>   if (val & (0x1 << offset)) {
>   int ret;
>  
>   /* Clear the event first */
>   I40E_WRITE_REG(hw, I40E_GLGEN_VFLRSTAT(index),
>   (0x1 << offset));
> - PMD_DRV_LOG(INFO, "VF %u reset occured", abs_vf_id);
> + PMD_DRV_LOG(INFO, "VF %u reset occurred", abs_vf_id);
>   /**
> -  * Only notify a VF reset event occured,
> +  * Only notify a VF reset event occurred,
>* don't trigger another SW reset
>*/
>   ret = i40e_pf_host_vf_reset(>vfs[i], 0);
> @@ -5007,7 +5007,7 @@ i40e_pf_config_rss(struct i40e_pf *pf)
>  
>   /*
>* If both VMDQ and RSS enabled, not all of PF queues are configured.
> -  * It's necessary to calulate the actual PF queues that are configured.
> +  * It's necessary to calculate the actual PF queues that are configured.
>*/
>   if (pf->dev_data->dev_conf.rxmode.mq_mode & ETH_MQ_RX_VMDQ_FLAG) {
>   num = i40e_pf_calc_configured_queues_num(pf);
> diff --git a/lib/librte_pmd_i40e/i40e_ethdev.h 
> b/lib/librte_pmd_i40e/i40e_ethdev.h
> index f913ea9..dc870d2 100644
> --- a/lib/librte_pmd_i40e/i40e_ethdev.h
> +++ b/lib/librte_pmd_i40e/i40e_ethdev.h
> @@ -273,7 +273,7 @@ enum I40E_VF_STATE {
>  struct i40e_pf_vf {
>   struct i40e_pf *pf;
>   struct i40e_vsi *vsi;
> - enum I40E_VF_STATE state; /* The number of queue pairs availiable */
> + enum I40E_VF_STATE state; /* The number of queue pairs available */
>   uint16_t vf_idx; /* VF index in pf->vfs */
>   uint16_t lan_nb_qps; /* Actual queues allocated */
>   uint16_t reset_cnt; /* Total vf reset times */
> diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pmd_i40e/i40e_rxtx.c
> index 2beae3c..56125cf 100644
> --- a/lib/librte_pmd_i40e/i40e_rxtx.c
> +++ b/lib/librte_pmd_i40e/i40e_rxtx.c
> @@ -1637,7 +1637,7 @@ i40e_dev_rx_queue_stop(struct rte_eth_dev *dev, 
> uint16_t rx_queue_id)
>   rxq = dev->data->rx_queues[rx_queue_id];
>  
>   /*
> - * rx_queue_id is queue id aplication refers to, while
> + * rx_queue_id is queue id application refers to, while
>   * rxq->reg_idx is the real queue index.
>   */
>   err = i40e_switch_rx_queue(hw, rxq->reg_idx, FALSE);
> @@ -1667,7 +1667,7 @@ i40e_dev_tx_queue_start(struct rte_eth_dev *dev, 
> uint16_t tx_queue_id)
>   txq = dev->data->tx_queues[tx_queue_id];
>  
>   /*
> - * tx_queue_id is queue id aplication refers to, while
> + * tx_queue_id is queue id application refers to, while
>   * rxq->reg_idx is the real queue index.
>   */
>   err = i40e_switch_tx_queue(hw, txq->reg_idx, TRUE);
> @@ -1690,7 +1690,7 @@ i40e_dev_tx_queue_stop(struct rte_eth_dev *dev, 
> uint16_t tx_queue_id)
>   txq = dev->data->tx_queues[tx_queue_id];
>  
>   /*
> - * tx_queue_id is queue id aplication refers to, while
> + * tx_queue_id is queue id application refers to, while
>   * txq->reg_idx is the real queue index.
>   */
>   err = i40e_switch_tx_queue(hw, txq->reg_idx, FALSE);
> -- 
> 2.1.4
> 
> 
For the series
Acked-by: Neil Horman 

[dpdk-dev] Making DPDK.org more vendor neutral

[Neil Horman]

On Sat, Jan 31, 2015 at 08:47:10PM +, Stephen Hemminger wrote:
> I think that DPDK.org should be as neutral in all public communications.
> 
> This bothers me:
> "If you need some specific drivers or networking stacks, you should contact a 
> company that provides such extensions."
> 
> This tag line is a link to page describing 6wind and other vendors leaves a 
> biased taint
> on the initial impression. It would be best to only put in historical data
> about the contributing companies and a vague reference to commercial support 
> being
> available.
> 
> It is not like kernel.org has links to SUSE and RHEL. We need to make DPDK.org
> independent.
> 

I agree.  Aspirations to greater neutrality can do nothing but bring in
additional developers.
Neil

[dpdk-dev] [RFC PATCH v2 01/14] enable VIRTIO_NET_F_CTRL_RX VIRTIO_NET_F_CTRL_RX is dependant on VIRTIO_NET_F_CTRL_VQ. Observed that virtio-net driver in guest would crash with only CTRL_RX enabled.

[Xie, Huawei]

> 
> Hi,Xie
> 
> If don't have features VIRTIO_NET_F_CTRL_VQ and  VIRTIO_NET_F_CTRL_RX
> what would happen?
> Why add the two features?

If virtio-net driver doesn't require those two features, it will work fine.

Changchun cced added these two features for control queue support and 
broadcast/multicast support.

> --
> Regards,
> Haifeng

[dpdk-dev] [PATCH 05/12] lib/librte_vhost: copy host_memory_map from virtio-net.c to a new file virtio-net-cdev.c

[Xie, Huawei]

> > + * map it to our address space.
> > + */
> > +static int
> > +host_memory_map(struct virtio_net *dev, struct virtio_memory *mem,
> > +   pid_t pid, uint64_t addr)
> > +{
> 
> Hi Xie,
> 
> This patch only copy host_memory_map() to a new file.
> And actually the original function is removed at below patch.
> - "[PATCH 07/12] lib/librte_vhost: split set_memory_table into two parts"
> 
> Is it difficult to remove and copy the function in this patch?

The purpose of splitting into several patches is to be reviewer friendly.
You could easily check the changes between each commit.
> 
> Thanks,
> Tetsuya
> 

[dpdk-dev] [PATCH 01/12] lib/librte_vhost: enable VIRTIO_NET_F_CTRL_RX

[Xie, Huawei]

 > @@ -73,7 +73,8 @@ static struct virtio_net_config_ll *ll_root;
> >
> >  /* Features supported by this lib. */
> >  #define VHOST_SUPPORTED_FEATURES ((1ULL <<
> VIRTIO_NET_F_MRG_RXBUF) | \
> > - (1ULL << VIRTIO_NET_F_CTRL_RX))
> > +   (1ULL << VIRTIO_NET_F_CTRL_VQ) | \
> > +   (1ULL << VIRTIO_NET_F_CTRL_RX))
> >  static uint64_t VHOST_FEATURES = VHOST_SUPPORTED_FEATURES;
> >
> >  /* Line size for reading maps file. */
> 
> Hi Xie,
> 
> Could you please check below code?
> 
> -
> examples/vhost/main.c
> -
> case 'P':
> promiscuous = 1;
> vmdq_conf_default.rx_adv_conf.vmdq_rx_conf.rx_mode =
> ETH_VMDQ_ACCEPT_BROADCAST |
> ETH_VMDQ_ACCEPT_MULTICAST;
> rte_vhost_feature_enable(1ULL <<
> VIRTIO_NET_F_CTRL_RX);
> 
> 
> VIRTIO_NET_F_CTRL_RX is always enabled by this patch.
> So if 'P' isn't specified in vhost example, does it need to be disabled?

Sounds reasonable.
I find that the subject shoud be "enable CTRL_VQ".
So issue with CTRL_RX should be fixed in other patch rather than in  this 
patchset.

Besides, even CTRL_VQ is a little weird, as we don't do anything with 
multiple enabling in vhost library.

> 
> Thanks,
> Tetsuya

[dpdk-dev] [PATCH 04/18] fm10k: add fm10k device id

[Neil Horman]

On Sat, Jan 31, 2015 at 05:55:07PM +0100, David Marchand wrote:
> On Sat, Jan 31, 2015 at 5:32 PM, Neil Horman  wrote:
> 
> > On Sat, Jan 31, 2015 at 05:07:28PM +0100, David Marchand wrote:
> > > In the end, we miss something to have dpdk work automatically like it
> > used
> > > to be, before the pci devices ids were stripped out of igb_uio.
> > >
> > > I can see two solutions :
> > > - all pmds export the pci device ids they support (this sounds like
> > > modalias :-)) or they register into the eal that exports this information
> > > for use by application, but to me the application should not bother with
> > > this ...
> > > - the pmd handles this automatically (like binding/unbinding on a kernel
> > > driver), with a _runtime_ option to enable this behavior (default being
> > "no
> > > automatic bind")
> > >
> > > Comments ? Ideas ?
> > >
> > I like the modalias idea, as it transports a table for uio/vfio to
> > identify with
> > the binary that needs it, preventing a possible discrepancy in what the
> > core
> > dpdk library identifies as supported devices and what the pmd DSO's
> > actually do
> > support.
> >
> 
> Yes, but if a pmd can do this itself alone, there is no discrepancy either.
> 
Yes, absolutely, but it needs to be done in a way that an external binary can
inspect the object independently of its being loaded, and preferably in a
non-programatic context (since the uio bind/unbind utilities are separate
scripts).

The modinfo method involves putting info into a special data section that gets
processed as part of the kernel modpost build stage.  There, the additional
section gets translated into a C file, and built into its own object thats
attached to the final binary module.  We can so the same thing here if you like

We could do something simpler, too.  For instance we could add a field to the
struct that gets registered as part of the RTE_REGISTER_PMD macro, and export it
via a new ethdev library call.  That would be very straightforward, but the
implication there is that you would need a programatic method to interrogate
that information (a binary to call into the dpdk), which is not part of how the
bind/unbind scripts work today.

> Thinking aloud ...
> As long as the pmd does all the magic bindings, the dpdk core does not need
> to know about it.
Yes, I'm not suggesting anything other than the pmd be responsible for codifying
its binding information.  Its how that information is exported to other
utilities that potentially increases the complexity of this operation.

> And if the dpdk core really needs to know about this (I can see no use case
> here, just want to avoid being blocked later) a dynamic register system
> would be fine too.
Sure, I don't see a problem with that. If we properly macro-wrap this, we can
likely add a dynamic registration mechanism without having to change the pmds
later

Neil

> 
> 
> 
> > To implement it we would either provide our own linker script or have to
> > do some
> > other make trickery.  The linker script is a bit more labor intensive, but
> > might
> > provide some future benefit (if you see a need for non-standard sections
> > that
> > you would like to suck into a given DSO in the future).  Make trickery
> > would be
> > more straightforward, but requires that we add some additional make
> > targets to
> > build out the dynamic table to be readable by outside utilities.  Maybe we
> > could
> > use objcopy to add in a separate section after the dso link.  Not sure yet
> >
> 
> Not sure either, I just think we may reinvent the wheel :-)
> 
> 
> -- 
> David Marchand

[dpdk-dev] [PATCH 04/18] fm10k: add fm10k device id

[Neil Horman]

On Sat, Jan 31, 2015 at 05:07:28PM +0100, David Marchand wrote:
> On Sat, Jan 31, 2015 at 3:19 PM, Neil Horman  wrote:
> 
> > On Fri, Jan 30, 2015 at 01:07:20PM +0800, Chen Jing D(Mark) wrote:
> > > From: Jeff Shaw 
> > >
> > > Add fm10k device ID list into rte_pci_dev_ids.h.
> > >
> > > Signed-off-by: Jeff Shaw 
> > > Signed-off-by: Chen Jing D(Mark) 
> > > ---
> > >  lib/librte_eal/common/include/rte_pci_dev_ids.h |   22
> > ++
> > >  1 files changed, 22 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > > index c922de9..f54800e 100644
> > > --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > > +++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > > @@ -132,6 +132,14 @@
> > >  #define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
> > >  #endif
> > >
> > > +#ifndef RTE_PCI_DEV_ID_DECL_FM10K
> > > +#define RTE_PCI_DEV_ID_DECL_FM10K(vend, dev)
> > > +#endif
> > > +
> > > +#ifndef RTE_PCI_DEV_ID_DECL_FM10KVF
> > > +#define RTE_PCI_DEV_ID_DECL_FM10KVF(vend, dev)
> > > +#endif
> > > +
> > I know this isn't the job of this patch series, but I don't really
> > understand
> > why we bother with this pattern for filling out pci id tables.  A PMD
> > supports
> > specific hardware, we might as well use the generic RTE_PCI_DEVICE macro
> > in the
> > driver rather than creating a FM10K specific wrapper, only to have to do
> > some
> > ifdef trickery in the rte_cpi_dev_ids file and some include magic to fill
> > it
> > out.
> >
> 
> +1
> 
> 
> > I'd suggest that you just use RTE_PCI_DEVICE macro here, and make your own
> > table
> > (keep the specific device id values in the common file.  Then we can clean
> > out
> > the macro maggic in a later update.
> >
> 
> If we are going that way, my only concern is that this makes it hard to
> "discover" the pci devices that need to be bound to igb_uio/vfio/whatever
> kernel driver, and so we must rely either on a global list (like this
> rte_pci_dev_ids.h) or on scripts with hardcoded pci device ids in them ...
> 
> In the end, we miss something to have dpdk work automatically like it used
> to be, before the pci devices ids were stripped out of igb_uio.
> 
> I can see two solutions :
> - all pmds export the pci device ids they support (this sounds like
> modalias :-)) or they register into the eal that exports this information
> for use by application, but to me the application should not bother with
> this ...
> - the pmd handles this automatically (like binding/unbinding on a kernel
> driver), with a _runtime_ option to enable this behavior (default being "no
> automatic bind")
> 
> Comments ? Ideas ?
> 
I like the modalias idea, as it transports a table for uio/vfio to identify with
the binary that needs it, preventing a possible discrepancy in what the core
dpdk library identifies as supported devices and what the pmd DSO's actually do
support.

To implement it we would either provide our own linker script or have to do some
other make trickery.  The linker script is a bit more labor intensive, but might
provide some future benefit (if you see a need for non-standard sections that
you would like to suck into a given DSO in the future).  Make trickery would be
more straightforward, but requires that we add some additional make targets to
build out the dynamic table to be readable by outside utilities.  Maybe we could
use objcopy to add in a separate section after the dso link.  Not sure yet
Neil

> -- 
> David Marchand

[dpdk-dev] [PATCH 04/18] fm10k: add fm10k device id

[Neil Horman]

On Fri, Jan 30, 2015 at 01:07:20PM +0800, Chen Jing D(Mark) wrote:
> From: Jeff Shaw 
> 
> Add fm10k device ID list into rte_pci_dev_ids.h.
> 
> Signed-off-by: Jeff Shaw 
> Signed-off-by: Chen Jing D(Mark) 
> ---
>  lib/librte_eal/common/include/rte_pci_dev_ids.h |   22 ++
>  1 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h 
> b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> index c922de9..f54800e 100644
> --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
> +++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> @@ -132,6 +132,14 @@
>  #define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
>  #endif
>  
> +#ifndef RTE_PCI_DEV_ID_DECL_FM10K
> +#define RTE_PCI_DEV_ID_DECL_FM10K(vend, dev)
> +#endif
> +
> +#ifndef RTE_PCI_DEV_ID_DECL_FM10KVF
> +#define RTE_PCI_DEV_ID_DECL_FM10KVF(vend, dev)
> +#endif
> +
I know this isn't the job of this patch series, but I don't really understand
why we bother with this pattern for filling out pci id tables.  A PMD supports
specific hardware, we might as well use the generic RTE_PCI_DEVICE macro in the
driver rather than creating a FM10K specific wrapper, only to have to do some
ifdef trickery in the rte_cpi_dev_ids file and some include magic to fill it
out.

I'd suggest that you just use RTE_PCI_DEVICE macro here, and make your own table
(keep the specific device id values in the common file.  Then we can clean out
the macro maggic in a later update.
Neil

[dpdk-dev] [DISCUSSION] : ERROR while running vhost example in dpdk-1.8

[Linhaifeng]

On 2015/1/30 14:01, Srinivasreddy R wrote:
> hi,
> 
> May be I am missing something regarding hugetlbfs .
> I performed below steps for hugetlbfs .
> I am running on Ubuntu 14.04.1 LTS.
> 
> cat /proc/cmdline
> BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic
> root=UUID=628ff32b-dede-4b47-bd13-893c13c18d00 ro quiet splash
> hugepagesz=2M hugepages=512 default_hugepagesz=1G hugepagesz=1G hugepages=8
> vt.handoff=7
> 
> mount -t hugetlbfs nodev /mnt/huge
> 
> echo 512 > /sys/kernel/mm/hugepages/hugepages-2048kB/ nr_hugepages
> mount -t hugetlbfs nodev /mnt/huge -o pagesize=2M
> 

mount /mnt/huge twice?

> thanks ,
> Srinivas.
> 
> 
> 
> On Fri, Jan 30, 2015 at 11:19 AM, Srinivasreddy R <
> srinivasreddy4390 at gmail.com> wrote:
> 
>> thanks for your reply . even I face the same issue .any pointers to
>> proceed ..
>>
>>
>> ./build/app/vhost-switch -c f -n 4  -- -p 0x1   --dev-basename usvhost-1
>> --stats 2
>> EAL: Detected lcore 0 as core 0 on socket 0
>> EAL: Detected lcore 1 as core 1 on socket 0
>> EAL: Detected lcore 2 as core 2 on socket 0
>> EAL: Detected lcore 3 as core 3 on socket 0
>> EAL: Detected lcore 4 as core 0 on socket 0
>> EAL: Detected lcore 5 as core 1 on socket 0
>> EAL: Detected lcore 6 as core 2 on socket 0
>> EAL: Detected lcore 7 as core 3 on socket 0
>> EAL: Support maximum 128 logical core(s) by configuration.
>> EAL: Detected 8 lcore(s)
>> EAL:   cannot open VFIO container, error 2 (No such file or directory)
>> EAL: VFIO support could not be initialized
>> EAL: Setting up memory...
>> EAL: Ask a virtual area of 0x2 bytes
>> EAL: Virtual area found at 0x7fb6c000 (size = 0x2)
>> EAL: Ask a virtual area of 0x1a0 bytes
>> EAL: Virtual area found at 0x7fb8f560 (size = 0x1a0)
>> EAL: Ask a virtual area of 0x20 bytes
>> EAL: Virtual area found at 0x7fb8f520 (size = 0x20)
>> EAL: Ask a virtual area of 0x20 bytes
>> EAL: Virtual area found at 0x7fb8f4e0 (size = 0x20)
>> EAL: Ask a virtual area of 0x6c0 bytes
>> EAL: Virtual area found at 0x7fb8ee00 (size = 0x6c0)
>> EAL: Ask a virtual area of 0x20 bytes
>> EAL: Virtual area found at 0x7fb8edc0 (size = 0x20)
>> EAL: Ask a virtual area of 0x20 bytes
>> EAL: Virtual area found at 0x7fb8ed80 (size = 0x20)
>> EAL: Ask a virtual area of 0x20 bytes
>> EAL: Virtual area found at 0x7fb8ed40 (size = 0x20)
>> EAL: Ask a virtual area of 0x9e0 bytes
>> EAL: Virtual area found at 0x7fb8e340 (size = 0x9e0)
>> EAL: Ask a virtual area of 0x1900 bytes
>> EAL: Virtual area found at 0x7fb8ca20 (size = 0x1900)
>> EAL: Ask a virtual area of 0x20 bytes
>> EAL: Virtual area found at 0x7fb8c9e0 (size = 0x20)
>> EAL: Ask a virtual area of 0x20 bytes
>> EAL: Virtual area found at 0x7fb8c9a0 (size = 0x20)
>> EAL: Ask a virtual area of 0x1000 bytes
>> EAL: Virtual area found at 0x7fb6afe0 (size = 0x1000)
>> EAL: Ask a virtual area of 0x3c0 bytes
>> EAL: Virtual area found at 0x7fb8c5c0 (size = 0x3c0)
>> EAL: Ask a virtual area of 0x20 bytes
>> EAL: Virtual area found at 0x7fb8c580 (size = 0x20)
>> EAL: Requesting 8 pages of size 1024MB from socket 0
>> EAL: Requesting 512 pages of size 2MB from socket 0
>> EAL: TSC frequency is ~3092840 KHz
>> EAL: Master core 0 is ready (tid=f83c0880)
>> PMD: ENICPMD trace: rte_enic_pmd_init
>> EAL: Core 3 is ready (tid=c3ded700)
>> EAL: Core 2 is ready (tid=c45ee700)
>> EAL: Core 1 is ready (tid=c4def700)
>> EAL: PCI device :01:00.0 on NUMA socket -1
>> EAL:   probe driver: 8086:1521 rte_igb_pmd
>> EAL:   PCI memory mapped at 0x7fb8f700
>> EAL:   PCI memory mapped at 0x7fb8f710
>> PMD: eth_igb_dev_init(): port_id 0 vendorID=0x8086 deviceID=0x1521
>> EAL: PCI device :01:00.1 on NUMA socket -1
>> EAL:   probe driver: 8086:1521 rte_igb_pmd
>> EAL:   :01:00.1 not managed by UIO driver, skipping
>> EAL: PCI device :03:00.0 on NUMA socket -1
>> EAL:   probe driver: 8086:10d3 rte_em_pmd
>> EAL:   :03:00.0 not managed by UIO driver, skipping
>> EAL: PCI device :04:00.0 on NUMA socket -1
>> EAL:   probe driver: 8086:10d3 rte_em_pmd
>> EAL:   :04:00.0 not managed by UIO driver, skipping
>> pf queue num: 0, configured vmdq pool num: 8, each vmdq pool has 1 queues
>> PMD: eth_igb_rx_queue_setup(): sw_ring=0x7fb8f60f7e00
>> hw_ring=0x7fb8f5228580 dma_addr=0x36628580
>> PMD: eth_igb_rx_queue_setup(): sw_ring=0x7fb8f60f5d00
>> hw_ring=0x7fb8f5238580 dma_addr=0x36638580
>> PMD: eth_igb_rx_queue_setup(): sw_ring=0x7fb8f60f3c00
>> hw_ring=0x7fb8f5248580 dma_addr=0x36648580
>> PMD: eth_igb_rx_queue_setup(): sw_ring=0x7fb8f60f1b00
>> hw_ring=0x7fb8f5258580 dma_addr=0x36658580
>> PMD: eth_igb_rx_queue_setup(): sw_ring=0x7fb8f60efa00
>> hw_ring=0x7fb8f5268580 dma_addr=0x36668580
>> PMD: eth_igb_rx_queue_setup(): sw_ring=0x7fb8f60ed900
>> hw_ring=0x7fb8f5278580 dma_addr=0x36678580
>> PMD: eth_igb_rx_queue_setup(): sw_ring=0x7fb8f60eb800

[dpdk-dev] [PATCH 03/18] fm10k: Add empty fm10k files

[Neil Horman]

On Fri, Jan 30, 2015 at 01:07:19PM +0800, Chen Jing D(Mark) wrote:
> From: Jeff Shaw 
> 
> Define macros and basic data structure.
> Define rte_log wrapper functions.
> 
> Signed-off-by: Jeff Shaw 
> Signed-off-by: Chen Jing D(Mark) 
> ---
>  lib/librte_pmd_fm10k/Makefile |   96 
>  lib/librte_pmd_fm10k/fm10k.h  |  224 
> +
>  lib/librte_pmd_fm10k/fm10k_logs.h |   66 +++
>  3 files changed, 386 insertions(+), 0 deletions(-)
>  create mode 100644 lib/librte_pmd_fm10k/Makefile
>  create mode 100644 lib/librte_pmd_fm10k/fm10k.h
>  create mode 100644 lib/librte_pmd_fm10k/fm10k_ethdev.c
>  create mode 100644 lib/librte_pmd_fm10k/fm10k_logs.h
>  create mode 100644 lib/librte_pmd_fm10k/fm10k_rxtx.c
> 
Why are you adding empty files?

Neil