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

[Ferruh Yigit]

On 6/6/2017 3:43 PM, gowrishankar muthukrishnan wrote:
> Hi Ferruh,
> Just wanted to check with you on the verdict of this patch, whether we 
> are waiting for
> any objection/ack ?.

I was waiting for more comment, I will ack explicitly.

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