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

[gowrishankar muthukrishnan]

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:
>> 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>
>>