Hi Ferruh,
Just wanted to check with you on the verdict of this patch, whether we 
are waiting for
any objection/ack ?.

Thanks,
Gowrishankar

On Thursday 01 June 2017 02:48 PM, Ferruh Yigit wrote:

On 6/1/2017 6:56 AM, gowrishankar muthukrishnan wrote:

quoted

Hi Ferruh,

On Wednesday 31 May 2017 09:51 PM, Ferruh Yigit wrote:
<cut>

quoted

I have sampled below data in x86_64 for KNI on ixgbe pmd. iperf server

quoted

runs on
remote interface connecting PMD and iperf client runs on KNI interface,
so as to
create more egress from KNI into DPDK (w/o and with this patch) for 1MB and
100MB data. rx and tx stats are from kni app (USR1).

100MB w/o patch 1.28Gbps
rx      tx        alloc_call  alloc_call_mt1tx freembuf_call
3933 72464 51042      42472              1560540

Some math:

alloc called 51042 times with allocating 32 mbufs each time,
51042 * 32 = 1633344

freed mbufs: 1560540

used mbufs: 1633344 - 1560540 = 72804

72804 =~ 72464, so looks correct.

Which means rte_kni_rx_burst() called 51042 times and 72464 buffers
received.

As you already mentioned, for each call kernel able to put only 1-2
packets into the fifo. This number is close to 3 for my test with KNI PMD.

And for this case, agree your patch looks reasonable.

But what if kni has more egress traffic, that able to put >= 32 packets
between each rte_kni_rx_burst()?
For that case this patch introduces extra cost to get allocq_free count.

Are there case(s) we see kernel thread writing txq faster at a rate
higher than kni application
could dequeue it ?. In my understanding, KNI is suppose to be a slow
path as it puts
packets back into network stack (control plane ?).

Kernel thread doesn't need to be faster than what app can dequeue,  it
is enough if kernel thread can put 32 or more packets for this case, but
I see this goes to same place.

And for kernel multi-thread mode, each kernel thread has more time to
enqueue packets, although I don't have the numbers.

quoted

Regards,
Gowrishankar

quoted

Overall I am not disagree with patch, but I have concern if this would
cause performance loss some cases while making better for this one. That
would help a lot if KNI users test and comment.

For me, applying patch didn't give any difference in final performance
numbers, but if there is no objection, I am OK to get this patch.

<cut>