DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Varghese, Vipin" <vipin.varghese@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 14:56:04 +0100	[thread overview]
Message-ID: <20191021135604.GE942@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D3DD007@BGSMSX101.gar.corp.intel.com>

On Mon, Oct 21, 2019 at 02:45:05PM +0100, Varghese, Vipin wrote:
> Hi Bruce,
> 
> snipped
> > >  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?
> > >
> > 
> > Actually I disagree. I think the user should pass the cores for interrupt pinning,
> I agree to this.
> 
> > because unlike other PMDs it is perfectly valid to have the interrupts pinned to
> > dedicated cores separate from those used by DPDK.
> My point is the same, but not on DPDK DP or service cores.
> 
> > 
> > Or taking another example, suppose the app takes 8 cores in the coremask, but
> > only one of those cores is to be used for I/O, what cores should the driver pin
> > the interrupts to?
> It can be cores on machine (guest or host) which is not used by DPDK.
> 
>  It probably should be the same core used for I/O, but the
> > driver can't know which cores will be for that, or alternatively the user might
> > want to use AF_XDP split across two cores, in which case any core on the
> > system might be the intended one for interrupts.
> I agree to the patch, only difference in dev->probe function, should not there be validation to ensure the IRQ core is not DPDK core or Service core as the Interface is owned by kernel and for non matched eBPF skb buff is used by kernel.
> 
No. Since the 5.4 kernel, it's a usable configuration to run both the
kernel and userspace portions of AF_XDP on the same core. In order to get
best performance with a fixed number of cores, this setup - with interrupts
pinned to the polling RX core - is now recommended. [For absolute best perf
using any number of cores, a separate interrupt core may still work best,
though]

/Bruce

  reply	other threads:[~2019-10-21 13:56 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
2019-10-21 13:17               ` Bruce Richardson
2019-10-21 13:45                 ` Varghese, Vipin
2019-10-21 13:56                   ` Bruce Richardson [this message]
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=20191021135604.GE942@bricha3-MOBL.ger.corp.intel.com \
    --to=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=vipin.varghese@intel.com \
    --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).