07/06/2017 19:20, Ferruh Yigit:
> On 5/11/2017 12:51 PM, Gowrishankar wrote:
> > From: Gowrishankar Muthukrishnan
> >
> > In kni_allocate_mbufs(), we attempt to add max_burst (32) count of mbuf
> > always into alloc_q, which is excessively leading too many rte_pktmbuf_
> > free() when alloc_q is
On 5/11/2017 12:51 PM, Gowrishankar wrote:
> From: Gowrishankar Muthukrishnan
>
> In kni_allocate_mbufs(), we attempt to add max_burst (32) count of mbuf
> always into alloc_q, which is excessively leading too many rte_pktmbuf_
> free() when alloc_q is contending at high packet rate (for eg 10Gig
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 0
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
On 6/1/2017 6:56 AM, gowrishankar muthukrishnan wrote:
> Hi Ferruh,
>
> On Wednesday 31 May 2017 09:51 PM, Ferruh Yigit wrote:
>
>> 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
Hi Ferruh,
On Wednesday 31 May 2017 09:51 PM, Ferruh Yigit wrote:
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
Hi Gowrishankar,
Sorry for late response.
On 5/18/2017 6:45 PM, gowrishankar muthukrishnan wrote:
> On Tuesday 16 May 2017 10:45 PM, Ferruh Yigit wrote:
>> On 5/11/2017 12:51 PM, Gowrishankar wrote:
>>> From: Gowrishankar Muthukrishnan
>>>
>>> In kni_allocate_mbufs(), we attempt to add max_burst
On Tuesday 16 May 2017 10:45 PM, Ferruh Yigit wrote:
On 5/11/2017 12:51 PM, Gowrishankar wrote:
From: Gowrishankar Muthukrishnan
In kni_allocate_mbufs(), we attempt to add max_burst (32) count of mbuf
always into alloc_q, which is excessively leading too many rte_pktmbuf_
free() when alloc_q i
On 5/11/2017 12:51 PM, Gowrishankar wrote:
> From: Gowrishankar Muthukrishnan
>
> In kni_allocate_mbufs(), we attempt to add max_burst (32) count of mbuf
> always into alloc_q, which is excessively leading too many rte_pktmbuf_
> free() when alloc_q is contending at high packet rate (for eg 10Gig
From: Gowrishankar Muthukrishnan
In kni_allocate_mbufs(), we attempt to add max_burst (32) count of mbuf
always into alloc_q, which is excessively leading too many rte_pktmbuf_
free() when alloc_q is contending at high packet rate (for eg 10Gig data).
In a situation when alloc_q fifo can only acc
10 matches
Mail list logo
