On 10/08/2014 04:30 AM, Sandy Harris wrote:
I have started a thread about this on the gcc help mailing list
https://gcc.gnu.org/ml/gcc-help/2014-10/msg00047.html
Great, perhaps you want to pass a patch proposal to gcc folks?
We might consider replacinging memzero_explicit with memset_s()
On 10/08/2014 11:50 AM, Tadeusz Struk wrote:
Hi Prarit,
On 10/07/2014 05:12 PM, Prarit Bhargava wrote:
The method in which the qat code determines the numa node for memory
allocations is a bit clunky. On 2 socket, single node systems it is
possible that adf_get_dev_node_id() returns node
Hi Prarit,
On 10/07/2014 05:12 PM, Prarit Bhargava wrote:
The method in which the qat code determines the numa node for memory
allocations is a bit clunky. On 2 socket, single node systems it is
possible that adf_get_dev_node_id() returns node 1, even though node 1
doesn't exist.
This code
Hi,
These two patches fix invalid (zero length) dma mapping and
enforce numa configuration for maximum performance.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
Tadeusz Struk (2):
crypto: qat - Prevent dma mapping zero length assoc data.
crypto: qat - Enforce valid numa
In a system with NUMA configuration we want to enforce that the accelerator is
connected to a node with memory to avoid cross QPI memory transaction.
Otherwise there is no point in using the accelerator as the encryption in
software will be faster.
Signed-off-by: Tadeusz Struk
Do not attempt to dma map associated data if it is zero length.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
drivers/crypto/qat/qat_common/qat_algs.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c
On 10/08/2014 01:38 PM, Tadeusz Struk wrote:
In a system with NUMA configuration we want to enforce that the accelerator is
connected to a node with memory to avoid cross QPI memory transaction.
Otherwise there is no point in using the accelerator as the encryption in
software will be
On 10/08/2014 10:57 AM, Prarit Bhargava wrote:
node = adf_get_dev_node_id(pdev);
^^^ I don't think you should ever make this call. IMO it is wrong to do it
that
way. Just stick with
node = dev_to_node(pdev-dev)
as the line below forces a default to that anyway.
But then
On 10/08/2014 02:11 PM, Tadeusz Struk wrote:
On 10/08/2014 10:57 AM, Prarit Bhargava wrote:
node = adf_get_dev_node_id(pdev);
^^^ I don't think you should ever make this call. IMO it is wrong to do it
that
way. Just stick with
node = dev_to_node(pdev-dev)
as the line below
On 10/08/2014 11:35 AM, Prarit Bhargava wrote:
But then how do I know which node I'm physically connected to?
The pci_dev maps to the bus which maps to a numa node. The pci_dev's numa
value
is copied directly from the bus (or busses depending on how deep it is).
I'd argue (strongly) that
On 10/08/2014 02:57 PM, Tadeusz Struk wrote:
On 10/08/2014 11:35 AM, Prarit Bhargava wrote:
But then how do I know which node I'm physically connected to?
The pci_dev maps to the bus which maps to a numa node. The pci_dev's numa
value
is copied directly from the bus (or busses depending
On 10/08/2014 12:01 PM, Prarit Bhargava wrote:
No that isn't correct. dev_to_node() will return the node the device is
connected to.
include/linux/device.h:
static inline int dev_to_node(struct device *dev)
{
return dev-numa_node;
}
struct device {
.
int numa_node; /* NUMA node this
12 matches
Mail list logo
