Re: [dpdk-dev] [PATCH v2] kni: add new mbuf in alloc_q only based on its empty slots

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 6/1/2017 6:56 AM, gowrishankar muthukrishnan wrote:
> Hi Ferruh,
> 
> On Wednesday 31 May 2017 09:51 PM, Ferruh Yigit wrote:
> <cut>
>> I have sampled below data in x86_64 for KNI on ixgbe pmd. iperf server
>>> 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.

> 
> Regards,
> Gowrishankar
> 
>> 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>
>