[dpdk-dev] [PATCH 1/2 v3] kni: fix inverted function comments

[dpdk-dev] [PATCH 1/2 v3] kni: fix inverted function comments

[Alex Wang]

From: Alex Wang <alex@awakenetworks.com>

The 'mbufs' alloc/free descriptions for
'rte_kni_tx_burst()' and 'rte_kni_rx_burst()'
should be inverted.

Fixes: 3fc5ca2 (kni: initial import)

Signed-off-by: Alex Wang <alex@awakenetworks.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
 lib/librte_kni/rte_kni.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/librte_kni/rte_kni.h b/lib/librte_kni/rte_kni.h
index ef9faa9..25fa45e 100644
--- a/lib/librte_kni/rte_kni.h
+++ b/lib/librte_kni/rte_kni.h
@@ -161,8 +161,8 @@ extern int rte_kni_handle_request(struct rte_kni *kni);
 /**
  * Retrieve a burst of packets from a KNI interface. The retrieved packets are
  * stored in rte_mbuf structures whose pointers are supplied in the array of
- * mbufs, and the maximum number is indicated by num. It handles the freeing of
- * the mbufs in the free queue of KNI interface.
+ * mbufs, and the maximum number is indicated by num. It handles allocating
+ * the mbufs for KNI interface alloc queue.
  *
  * @param kni
  *  The KNI interface context.
@@ -180,8 +180,8 @@ extern unsigned rte_kni_rx_burst(struct rte_kni *kni,
 /**
  * Send a burst of packets to a KNI interface. The packets to be sent out are
  * stored in rte_mbuf structures whose pointers are supplied in the array of
- * mbufs, and the maximum number is indicated by num. It handles allocating
- * the mbufs for KNI interface alloc queue.
+ * mbufs, and the maximum number is indicated by num. It handles the freeing of
+ * the mbufs in the free queue of KNI interface.
  *
  * @param kni
  *  The KNI interface context.
-- 
2.1.4

[dpdk-dev] [PATCH 2/2 v3] kni: add documentation for the mempool capacity

[Alex Wang]

From: Alex Wang <alex@awakenetworks.com>

Function like 'rte_kni_rx_burst()' keeps
allocating 'MAX_MBUF_BURST_NUM' mbufs to
kni fifo queue unless the queue's capacity
('KNI_FIFO_COUNT_MAX') is reached.  So, if
the mempool is under-provisioned, user may
run into "Out of Memory" logs from KNI code.
This commit documents the need to provision
mempool capacity of more than
"2 x KNI_FIFO_COUNT_MAX" for each KNI interface.

Signed-off-by: Alex Wang <alex@awakenetworks.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
 lib/librte_kni/rte_kni.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/librte_kni/rte_kni.h b/lib/librte_kni/rte_kni.h
index 25fa45e..ac11148 100644
--- a/lib/librte_kni/rte_kni.h
+++ b/lib/librte_kni/rte_kni.h
@@ -113,6 +113,9 @@ extern void rte_kni_init(unsigned int max_kni_ifaces);
  * The rte_kni_alloc shall not be called before rte_kni_init() has been
  * called. rte_kni_alloc is thread safe.
  *
+ * The mempool should have capacity of more than "2 x KNI_FIFO_COUNT_MAX"
+ * elements for each KNI interface allocated.
+ *
  * @param pktmbuf_pool
  *  The mempool for allocting mbufs for packets.
  * @param conf
-- 
2.1.4

Re: [dpdk-dev] [PATCH 2/2 v3] kni: add documentation for the mempool capacity

[Mcnamara, John]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Alex Wang
> Sent: Saturday, May 21, 2016 8:59 AM
> To: dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Alex Wang
> <alex@awakenetworks.com>
> Subject: [dpdk-dev] [PATCH 2/2 v3] kni: add documentation for the mempool
> capacity
> 
> From: Alex Wang <alex@awakenetworks.com>
> 
> Function like 'rte_kni_rx_burst()' keeps allocating 'MAX_MBUF_BURST_NUM'
> mbufs to kni fifo queue unless the queue's capacity
> ('KNI_FIFO_COUNT_MAX') is reached.  So, if the mempool is under-
> provisioned, user may run into "Out of Memory" logs from KNI code.
> This commit documents the need to provision mempool capacity of more than
> "2 x KNI_FIFO_COUNT_MAX" for each KNI interface.
> 
> Signed-off-by: Alex Wang <alex@awakenetworks.com>
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Acked-by: John McNamara <john.mcnamara@intel.com>

Re: [dpdk-dev] [PATCH 2/2 v3] kni: add documentation for the mempool capacity

[Alex Wang]

Just to confirm, should I do anything before it gets merged?

On Thu, Jun 9, 2016 at 5:03 AM, Mcnamara, John <john.mcnamara@intel.com>
wrote:

> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Alex Wang
> > Sent: Saturday, May 21, 2016 8:59 AM
> > To: dev@dpdk.org
> > Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Alex Wang
> > <alex@awakenetworks.com>
> > Subject: [dpdk-dev] [PATCH 2/2 v3] kni: add documentation for the mempool
> > capacity
> >
> > From: Alex Wang <alex@awakenetworks.com>
> >
> > Function like 'rte_kni_rx_burst()' keeps allocating 'MAX_MBUF_BURST_NUM'
> > mbufs to kni fifo queue unless the queue's capacity
> > ('KNI_FIFO_COUNT_MAX') is reached.  So, if the mempool is under-
> > provisioned, user may run into "Out of Memory" logs from KNI code.
> > This commit documents the need to provision mempool capacity of more than
> > "2 x KNI_FIFO_COUNT_MAX" for each KNI interface.
> >
> > Signed-off-by: Alex Wang <alex@awakenetworks.com>
> > Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
>
>

Re: [dpdk-dev] [PATCH 2/2 v3] kni: add documentation for the mempool capacity

[Mcnamara, John]

> Just to confirm, should I do anything before it gets merged?

No. Looks good to me. Now you just need to wait. :-)

John.

Re: [dpdk-dev] [PATCH 2/2 v3] kni: add documentation for the mempool capacity

[Thomas Monjalon]

> > From: Alex Wang <alex@awakenetworks.com>
> > 
> > Function like 'rte_kni_rx_burst()' keeps allocating 'MAX_MBUF_BURST_NUM'
> > mbufs to kni fifo queue unless the queue's capacity
> > ('KNI_FIFO_COUNT_MAX') is reached.  So, if the mempool is under-
> > provisioned, user may run into "Out of Memory" logs from KNI code.
> > This commit documents the need to provision mempool capacity of more than
> > "2 x KNI_FIFO_COUNT_MAX" for each KNI interface.
> > 
> > Signed-off-by: Alex Wang <alex@awakenetworks.com>
> > Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
> 
> Acked-by: John McNamara <john.mcnamara@intel.com>

Applied, thanks