On 10/14/2014 03:53 AM, Prarit Bhargava wrote: >> >> - node = adf_get_dev_node_id(pdev); >> - accel_dev = kzalloc_node(sizeof(*accel_dev), GFP_KERNEL, node); >> + if (num_possible_nodes() > 1 && dev_to_node(&pdev->dev) < 0) { >> + /* If the accelerator is connected to a node with no memory >> + * there is no point in using the accelerator since the remote >> + * memory transaction will be very slow. */ >> + dev_err(&pdev->dev, "Invalid NUMA configuration.\n"); > > This is a lot better. Thank you for taking my comments into account here. Thanks for taking the time to review my patch and providing your comments. > > Let's say I have a non-functional qat device and I see the above message in > the boot log. The log doesn't say what to do ... so perhaps change it to > > dev_err(&pdev->dev, FW_BUG "numa node is set to %d. This can be overridden by > using the numa_node module parameter.", > dev_to_node(&pdev->dev)); > > and add a numa_node module parameter to let the user set that at module load > time in case their FW is broken? I've found that sysadmins are knowledgeable > about these types of things these days and are more than capable of looking > at sysfs and numactl to determine where a device is. > But then what if there are two devices and each belongs to different node. In this case we would fix one and break the other. I think if the FW is broken then using on core encryption will be safer. If a sysadmins is really knowledgeable, then she or he can change the code to customize it for a given platform and rebuild the module. Other than that as far as I know module parameters are not encouraged. T -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html