DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@linux.intel.com>
To: dheemanth <dheemanthm@vmware.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v1 2/2] linux/kni: Added support for KNI multiple fifos
Date: Wed, 30 Jun 2021 13:23:48 +0100	[thread overview]
Message-ID: <4a427759-55cd-b06b-85a9-a7e8f1506cfc@linux.intel.com> (raw)
In-Reply-To: <1607642153-24347-1-git-send-email-dheemanthm@vmware.com>

On 12/10/2020 11:15 PM, dheemanth wrote:
> In order to improve performance, the KNI is made to
> support multiple fifos, So that multiple threads pinned
> to multiple cores can process packets in parallel.
> 

Hi Dheemanth,

As far as I know, in KNI the bottle neck is in the kernel thread. In this patch
FIFO between userspace and kernelspace converted into multiple FIFOs but in
kernel side still same thread process all FIFOs, so only userspace can scale to
more cores, I wonder how this imporves the performance, can you please share use
case and some numbers?

Also FIFOs seems converted from simple single producer, single consumer to multi
producer and multi consumer. What is the performance impact of this? And why
this is needed? In the dpdk application, is there N-N relation between cores and
fifos, again can you please clarifiy your usecase?

In the kernel to userspace transfer, packets distributed to multiple FIFOs based
on packet hash, this should be additional load to the kernel thread.

The sample application and unit test (also kni pmd) is not using this new
feature but they only use single fifo. They also should be updated to use this
feature, that helps as sample and helps to demonstrade the usecase.

Btw, can you please clarify why 'queues_num' is used? Is it expected to be same
with 'fifos_num'?

Also documentation needs to be updated, but before more change I think the
benefit of the work needs to be clarified to decide to proceed or not with the set.

> Signed-off-by: dheemanth <dheemanthm@vmware.com>
> ---
>  app/test/test_kni.c             |   4 +-
>  drivers/net/kni/rte_eth_kni.c   |   5 +-
>  examples/kni/main.c             |   4 +-
>  kernel/linux/kni/kni_dev.h      |  11 +-
>  kernel/linux/kni/kni_fifo.h     | 190 ++++++++++++++++++++++++++++++-----
>  kernel/linux/kni/kni_misc.c     | 189 +++++++++++++++++++++--------------
>  kernel/linux/kni/kni_net.c      |  88 ++++++++++------
>  lib/librte_kni/rte_kni.c        | 216 ++++++++++++++++++++++++++--------------
>  lib/librte_kni/rte_kni.h        |  11 +-
>  lib/librte_kni/rte_kni_common.h |  10 +-
>  lib/librte_port/rte_port_kni.c  |  12 +--
>  11 files changed, 514 insertions(+), 226 deletions(-)
> 

<...>

> @@ -292,51 +292,69 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
>  {
>  	struct kni_net *knet = net_generic(net, kni_net_id);
>  	int ret;
> -	struct rte_kni_device_info dev_info;
> +	unsigned int i, tx_queues_num;
> +	struct rte_kni_device_info *dev_info;
>  	struct net_device *net_dev = NULL;
>  	struct kni_dev *kni, *dev, *n;
>  
>  	pr_info("Creating kni...\n");
> +
> +	/* allocate dev_info from stack to avoid Wframe-larger-than=1024
> +	 * compile error.
> +	 */

s/stack/heap

> +	dev_info = kzalloc(sizeof(struct rte_kni_device_info), GFP_KERNEL);
> +	if (!dev_info)
> +		return -ENOMEM;
> +

<...>

  parent reply	other threads:[~2021-06-30 12:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10 23:15 dheemanth
2021-01-17 22:02 ` Thomas Monjalon
2021-01-19 17:41   ` Dheemanth Mallikarjun
2021-06-28 16:58 ` Ferruh Yigit
2021-06-30 12:23 ` Ferruh Yigit [this message]
2023-06-13 16:21 ` Stephen Hemminger
  -- strict thread matches above, loose matches on Subject: below --
2020-12-09  1:47 dheemanth
2020-12-07 20:03 dheemanth

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=4a427759-55cd-b06b-85a9-a7e8f1506cfc@linux.intel.com \
    --to=ferruh.yigit@linux.intel.com \
    --cc=dev@dpdk.org \
    --cc=dheemanthm@vmware.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).