linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tadeusz Struk <tadeusz.struk@intel.com>
To: Prarit Bhargava <prarit@redhat.com>
Cc: herbert@gondor.apana.org.au, bruce.w.allan@intel.com,
	qat-linux@intel.com, john.griffin@intel.com,
	linux-crypto@vger.kernel.org, naleksan@redhat.com,
	davem@davemloft.net
Subject: Re: [PATCH 2/2] crypto: qat - Enforce valid numa configuration.
Date: Sat, 11 Oct 2014 10:05:40 -0700	[thread overview]
Message-ID: <54396364.1020703@intel.com> (raw)
In-Reply-To: <54385A88.5040901@redhat.com>

On 10/10/2014 03:15 PM, Prarit Bhargava wrote:
> In short, that calcuation is wrong.  Don't use it; stick with the widely
> accepted and used dev_to_node of the pci_dev.  It is used in other cases IIRC to
> determine the numa location of the device.  It shouldn't be any different for
> this driver.
As a matter of fact this is what we are doing now. Effectively
dev_to_node() is used for all numa allocations.
The only reason it was done this way was to ensure the best performance.
We are competing with very fast on core encryption here and the only way
we can beat that is to make sure the dma transactions will not have to
go over the QPI link to the remote numa node. If it will then the
performance will drop significantly and in this case we don't want to
bring the device up.
I agree that this is not the most elegant way to figure out the numa
locality for a device, but it worked for us so far.
Anyway I think I know how to get done this using ACPI. Will send v2 on
Monday.
T.

      reply	other threads:[~2014-10-11 17:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-08 17:38 [PATCH 0/2] crypto: qat - Fix for invalid dma mapping and numa Tadeusz Struk
2014-10-08 17:38 ` [PATCH 1/2] crypto: qat - Prevent dma mapping zero length assoc data Tadeusz Struk
2014-10-08 17:38 ` [PATCH 2/2] crypto: qat - Enforce valid numa configuration Tadeusz Struk
2014-10-08 17:57   ` Prarit Bhargava
2014-10-08 18:11     ` Tadeusz Struk
2014-10-08 18:35       ` Prarit Bhargava
2014-10-08 18:57         ` Tadeusz Struk
2014-10-08 19:01           ` Prarit Bhargava
2014-10-08 19:25             ` Tadeusz Struk
2014-10-09 11:23               ` Prarit Bhargava
2014-10-09 16:14                 ` Tadeusz Struk
2014-10-09 17:32                   ` Prarit Bhargava
2014-10-09 19:55                     ` Tadeusz Struk
2014-10-09 21:42                       ` Prarit Bhargava
2014-10-09 23:12                         ` Tadeusz Struk
2014-10-10 11:23                           ` Prarit Bhargava
2014-10-10 13:25                             ` Tadeusz Struk
2014-10-10 22:15                               ` Prarit Bhargava
2014-10-11 17:05                                 ` Tadeusz Struk [this message]

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=54396364.1020703@intel.com \
    --to=tadeusz.struk@intel.com \
    --cc=bruce.w.allan@intel.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=john.griffin@intel.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=naleksan@redhat.com \
    --cc=prarit@redhat.com \
    --cc=qat-linux@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).