From: gowrishankar muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] kni: add new mbuf in alloc_q only based on its empty slots
Date: Thu, 1 Jun 2017 11:26:14 +0530 [thread overview]
Message-ID: <d9529d95-1608-129d-a72c-1f71e4cac801@linux.vnet.ibm.com> (raw)
In-Reply-To: <82c75bc8-644a-1aa9-4a6b-60061633108d@intel.com>
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 ?).
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>
next prev parent reply other threads:[~2017-06-01 5:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-11 11:29 [dpdk-dev] [PATCH] " Gowrishankar
2017-05-11 11:51 ` [dpdk-dev] [PATCH v2] " Gowrishankar
2017-05-16 17:15 ` Ferruh Yigit
2017-05-18 17:45 ` gowrishankar muthukrishnan
2017-05-31 16:21 ` Ferruh Yigit
2017-06-01 5:56 ` gowrishankar muthukrishnan [this message]
2017-06-01 9:18 ` Ferruh Yigit
2017-06-06 14:43 ` gowrishankar muthukrishnan
2017-06-07 17:20 ` Ferruh Yigit
2017-06-07 17:20 ` Ferruh Yigit
2017-07-01 10:56 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d9529d95-1608-129d-a72c-1f71e4cac801@linux.vnet.ibm.com \
--to=gowrishankar.m@linux.vnet.ibm.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).