DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: "JP M." <jpm.dpdk@gmail.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] KNI with multiple kthreads per port
Date: Sat, 28 Feb 2015 19:46:28 -0500	[thread overview]
Message-ID: <20150301004627.GA29693@neilslaptop.think-freely.org> (raw)
In-Reply-To: <CABy-zJJDXG10Af-60zYK-4iBWUXHrCJDd-21=9=3PipRZCx+NQ@mail.gmail.com>

On Sat, Feb 28, 2015 at 02:39:40PM -0800, JP M. wrote:
> Howdy! First time posting; please be gentle. :-)
> 
> Environment:
>  * DPDK 1.8.0 release
>  * Linux kernel 3.0.3x-ish
>  * 32-bit (yes, KNI works fine, after a few tweaks hugepage init strategy)
> 
> I'm trying to use the KNI example app with a configuration where multiple
> kthreads are created for a physical port. Per the user guide and code, the
> first such kthread is the "master", any the only one configurable; I'll
> refer to the additional kthread(s) as "slaves", although their relationship
> to the master kthread isn't discussed anywhere that I've looked thus far.
> 
> # insmod rte_kni.ko kthread_mode=multiple
> # kni [....] --config="(0,0,1,2,3)"
> # ifconfig vEth0_0 10.0.0.1 netmask 255.255.255.0
> 
> From the above: PMD-bound physical port0. Rx/Tx on cores 0 and 1,
> respectively. Master thread on core 2, one slave kthread on core 3.  Upon
> startup, KNI devices vEth0_0 (master) and vEth0_1 (slave) are created.
> After ifconfig, vEth0_0 works fine; by design, vEth0_1 cannot be configured.
> 
> The problem I'm encountering is that the subset of packets hitting vEth0_1
> are being dropped... somewhere.  They're definitely getting as far as the
> call to netif_rx(skb).  I'll try on a newer system for comparison.  But
> before I go too much further, I'd like to establish the correct set-up and
> expectations.
> 
> Should I be bonding vEth0_0 and vEth0_1?  Because I tried doing so (via
> sysfs); however, attempts to add either as slaves to bond0 were ignored.
> 
> Any ideas appreciated. (Though it may end up being a moot point, with the
> other work this past week on KNI performance.)
> 
Start by using dropwatch.  If you know that you're getting as far as netif_rx,
then you know you're getting into the kernel networking stack.  Dropwatch will
tell you exactly where you're loosing frames, and you can work backwards from
there to figure out the why behind the event.

Neil

  reply	other threads:[~2015-03-01  0:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-28 22:39 JP M.
2015-03-01  0:46 ` Neil Horman [this message]
2015-03-05  5:40 ` Zhang, Helin
2015-03-05  7:33   ` JP M.

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=20150301004627.GA29693@neilslaptop.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=jpm.dpdk@gmail.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).