DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Varghese, Vipin" <vipin.varghese@intel.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>
Cc: "Loftus, Ciara" <ciara.loftus@intel.com>,
	'Stephen Hemminger' <stephen@networkplumber.org>,
	"'dev@dpdk.org'" <dev@dpdk.org>,
	"Ye, Xiaolong" <xiaolong.ye@intel.com>,
	"Laatz, Kevin" <kevin.laatz@intel.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2 2/3] net/af_xdp: support pinning of IRQs
Date: Mon, 21 Oct 2019 13:11:39 +0000	[thread overview]
Message-ID: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D3DCFC2@BGSMSX101.gar.corp.intel.com> (raw)
In-Reply-To: <20191021130416.GB942@bricha3-MOBL.ger.corp.intel.com>

Hi Bruce,

snipped
> > >
> > > For the no-pinning case, all IRQs are landing on the default core 0,
> > > which results in very poor scaling versus the pinned case where scaling is
> linear.
> >
> > Thanks for the information, but a question here `Is the reason for
> > landing all IRQ on core '0' is because the Kernel CMD line 'isol or no
> > interupts' is done for all expect core 0?`
> >
> > If the cores are not isolated and no interrupts are redirected; normally `cat
> /proc/interrupts` shows IRQ mask to cores. Depending upon FDIR (intel X522
> and X710) this could be core 0 or 'n-1'?
> >
> Yes, the interrupt pinning default is somewhat dependent on the exact setup,
> but the fact remains that in just about any setup the interrupts for an AF_XDP
> queue are unlikely to end up on the exactly the one core that the user wants
> them on. This is what makes this patch so necessary, both from a usability and
> performance point of view.
> 
> In the absense of alternatives, I really think this patch should be merged, since
> with more than one point the difference between having correctly or
> incorrectly pinned interrupts is huge. I'd also point out that in my testing the
> interrupts need to be pinned each and every time an app is run - it's not a set
> once and forget thing.
Yes, I agree with you as in my testing with XDP and FDIR we had to do this in each test run.

 This ability to have the driver pin the interrupts for the
> user would be a big timesaver for developers too, who may be constantly re-
> running apps when testing.
Here my understanding, user can not or should not pass DPDK cores for interrupt pinning. So should we ask the driver to fetch `rte_eal_configuration` and ensure the same?

> 
> Regards,
> /Bruce

  reply	other threads:[~2019-10-21 13:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-30 16:42 [dpdk-dev] [PATCH v2 0/3] AF_XDP tx halt fix, IRQ pinning and unaligned chunks Ciara Loftus
2019-09-30 16:42 ` [dpdk-dev] [PATCH v2 1/3] net/af_xdp: fix Tx halt when no recv packets Ciara Loftus
2019-10-22  5:32   ` Ye Xiaolong
2019-09-30 16:42 ` [dpdk-dev] [PATCH v2 2/3] net/af_xdp: support pinning of IRQs Ciara Loftus
2019-09-30 17:11   ` Stephen Hemminger
2019-10-03 13:23     ` Loftus, Ciara
2019-10-14 14:43       ` Bruce Richardson
2019-10-21 15:24         ` Ferruh Yigit
2019-10-21 15:54           ` Bruce Richardson
2019-10-21 16:02             ` Ferruh Yigit
2019-10-21 16:14               ` Bruce Richardson
2019-10-15 11:14       ` Ray Kinsella
2019-10-21 10:04       ` Loftus, Ciara
2019-10-21 12:52         ` Varghese, Vipin
2019-10-21 13:04           ` Bruce Richardson
2019-10-21 13:11             ` Varghese, Vipin [this message]
2019-10-21 13:17               ` Bruce Richardson
2019-10-21 13:45                 ` Varghese, Vipin
2019-10-21 13:56                   ` Bruce Richardson
2019-10-21 14:06                     ` Varghese, Vipin
2019-10-18 23:49   ` Ye Xiaolong
2019-09-30 16:42 ` [dpdk-dev] [PATCH v2 3/3] net/af_xdp: enable support for unaligned umem chunks Ciara Loftus
2019-10-18 23:48   ` Ye Xiaolong
2019-10-22 14:28     ` Ferruh Yigit
2019-10-24 11:10   ` David Marchand
2019-10-24 12:18     ` David Marchand
2019-10-24 14:18       ` Ferruh Yigit

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=4C9E0AB70F954A408CC4ADDBF0F8FA7D4D3DCFC2@BGSMSX101.gar.corp.intel.com \
    --to=vipin.varghese@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=ciara.loftus@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=kevin.laatz@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=xiaolong.ye@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).