traversing mlx5_ib_dev_list, mlx5_ib_add_slave_port()
repeatedly attempts to bind the new mpi structure to every device
on the list until it finds an unbound device.
Change the log level from warn to dbg to avoid log flooding as the warning
should be harmless.
Signed-off-by: Qing Huang
---
v1 -&g
traversing mlx5_ib_dev_list, mlx5_ib_add_slave_port()
repeatedly attempts to bind the new mpi structure to every device
on the list until it finds an unbound device.
Change the log level from warn to dbg to avoid log flooding as the warning
should be harmless.
Signed-off-by: Qing Huang
---
v1 -&g
Hi Daniel,
On 7/23/2018 11:11 AM, Daniel Jurgens wrote:
On 7/23/2018 10:36 AM, Qing Huang wrote:
Hi Daniel/Parav,
Have you got a chance to review this patch? Thanks!
Hi Qing, sorry for the delay, I just got back to the office today. I don't
agree with the proposed fix, I provided
Hi Daniel,
On 7/23/2018 11:11 AM, Daniel Jurgens wrote:
On 7/23/2018 10:36 AM, Qing Huang wrote:
Hi Daniel/Parav,
Have you got a chance to review this patch? Thanks!
Hi Qing, sorry for the delay, I just got back to the office today. I don't
agree with the proposed fix, I provided
On 7/15/2018 12:48 PM, Daniel Jurgens wrote:
On 7/14/2018 10:57 AM, Or Gerlitz wrote:
On Sat, Jul 14, 2018 at 2:50 AM, Qing Huang wrote:
When a CX5 device is configured in dual-port RoCE mode, after creating
many VFs against port 1, creating the same number of VFs against port 2
will flood
On 7/15/2018 12:48 PM, Daniel Jurgens wrote:
On 7/14/2018 10:57 AM, Or Gerlitz wrote:
On Sat, Jul 14, 2018 at 2:50 AM, Qing Huang wrote:
When a CX5 device is configured in dual-port RoCE mode, after creating
many VFs against port 1, creating the same number of VFs against port 2
will flood
traversing mlx5_ib_dev_list, mlx5_ib_add_slave_port()
shouldn't repeatedly attempt to bind the new mpi data unit to every device
on the list until it finds an unbound device.
Reported-by: Gerald Gibson
Signed-off-by: Qing Huang
---
drivers/infiniband/hw/mlx5/main.c | 3 ++-
1 file changed, 2 insert
traversing mlx5_ib_dev_list, mlx5_ib_add_slave_port()
shouldn't repeatedly attempt to bind the new mpi data unit to every device
on the list until it finds an unbound device.
Reported-by: Gerald Gibson
Signed-off-by: Qing Huang
---
drivers/infiniband/hw/mlx5/main.c | 3 ++-
1 file changed, 2 insert
On 5/31/2018 2:10 AM, Michal Hocko wrote:
On Thu 31-05-18 10:55:32, Michal Hocko wrote:
On Thu 31-05-18 04:35:31, Eric Dumazet wrote:
[...]
I merely copied/pasted from alloc_skb_with_frags() :/
I will have a look at it. Thanks!
OK, so this is an example of an incremental development ;).
On 5/31/2018 2:10 AM, Michal Hocko wrote:
On Thu 31-05-18 10:55:32, Michal Hocko wrote:
On Thu 31-05-18 04:35:31, Eric Dumazet wrote:
[...]
I merely copied/pasted from alloc_skb_with_frags() :/
I will have a look at it. Thanks!
OK, so this is an example of an incremental development ;).
for each mtt
entry). So we need a 16MB allocation for a table->icm pointer array to
hold 2M pointers which can easily cause kcalloc to fail.
The solution is to use kvzalloc to replace kcalloc which will fall back
to vmalloc automatically if kmalloc fails.
Signed-off-by: Qing Huang <q
for each mtt
entry). So we need a 16MB allocation for a table->icm pointer array to
hold 2M pointers which can easily cause kcalloc to fail.
The solution is to use kvzalloc to replace kcalloc which will fall back
to vmalloc automatically if kmalloc fails.
Signed-off-by: Qing Huang
Acked-by: Dan
On 5/22/2018 8:33 AM, Tariq Toukan wrote:
On 18/05/2018 12:45 AM, Qing Huang wrote:
On 5/17/2018 2:14 PM, Eric Dumazet wrote:
On 05/17/2018 01:53 PM, Qing Huang wrote:
When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk allocations will likely
On 5/22/2018 8:33 AM, Tariq Toukan wrote:
On 18/05/2018 12:45 AM, Qing Huang wrote:
On 5/17/2018 2:14 PM, Eric Dumazet wrote:
On 05/17/2018 01:53 PM, Qing Huang wrote:
When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk allocations will likely
On 5/17/2018 2:14 PM, Eric Dumazet wrote:
On 05/17/2018 01:53 PM, Qing Huang wrote:
When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk allocations will likely trigger kernel
memory management to enter slow path doing memory compact/migration
ops
On 5/17/2018 2:14 PM, Eric Dumazet wrote:
On 05/17/2018 01:53 PM, Qing Huang wrote:
When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk allocations will likely trigger kernel
memory management to enter slow path doing memory compact/migration
ops
ned-off-by: Qing Huang <qing.hu...@oracle.com>
Acked-by: Daniel Jurgens <dani...@mellanox.com>
Reviewed-by: Zhu Yanjun <yanjun@oracle.com>
---
v3: use PAGE_SIZE instead of PAGE_SHIFT
add comma to the end of enum variables
include vmalloc.h header file to avoid buil
ned-off-by: Qing Huang
Acked-by: Daniel Jurgens
Reviewed-by: Zhu Yanjun
---
v3: use PAGE_SIZE instead of PAGE_SHIFT
add comma to the end of enum variables
include vmalloc.h header file to avoid build issues on Sparc
v2: adjuste chunk size to reflect different architectures
drivers/
On 5/15/2018 12:08 PM, Eric Dumazet wrote:
On 05/15/2018 11:53 AM, Qing Huang wrote:
This is control path so it is less latency-sensitive.
Let's not produce unnecessary degradation here, please call kvzalloc so we
maintain a similar behavior when contiguous memory is available
On 5/15/2018 12:08 PM, Eric Dumazet wrote:
On 05/15/2018 11:53 AM, Qing Huang wrote:
This is control path so it is less latency-sensitive.
Let's not produce unnecessary degradation here, please call kvzalloc so we
maintain a similar behavior when contiguous memory is available
On 5/15/2018 2:19 AM, Tariq Toukan wrote:
On 14/05/2018 7:41 PM, Qing Huang wrote:
On 5/13/2018 2:00 AM, Tariq Toukan wrote:
On 11/05/2018 10:23 PM, Qing Huang wrote:
When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk allocations
On 5/15/2018 2:19 AM, Tariq Toukan wrote:
On 14/05/2018 7:41 PM, Qing Huang wrote:
On 5/13/2018 2:00 AM, Tariq Toukan wrote:
On 11/05/2018 10:23 PM, Qing Huang wrote:
When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk allocations
On 5/13/2018 2:00 AM, Tariq Toukan wrote:
On 11/05/2018 10:23 PM, Qing Huang wrote:
When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk allocations will likely trigger kernel
memory management to enter slow path doing memory compact/migration
ops
On 5/13/2018 2:00 AM, Tariq Toukan wrote:
On 11/05/2018 10:23 PM, Qing Huang wrote:
When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk allocations will likely trigger kernel
memory management to enter slow path doing memory compact/migration
ops
ned-off-by: Qing Huang <qing.hu...@oracle.com>
Acked-by: Daniel Jurgens <dani...@mellanox.com>
Reviewed-by: Zhu Yanjun <yanjun@oracle.com>
---
v2 -> v1: adjusted chunk size to reflect different architectures.
drivers/net/ethernet/mellanox/mlx4/icm.c | 14 +++---
1 fi
ned-off-by: Qing Huang
Acked-by: Daniel Jurgens
Reviewed-by: Zhu Yanjun
---
v2 -> v1: adjusted chunk size to reflect different architectures.
drivers/net/ethernet/mellanox/mlx4/icm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/mellano
On 5/11/2018 3:27 AM, Håkon Bugge wrote:
On 11 May 2018, at 01:31, Qing Huang<qing.hu...@oracle.com> wrote:
When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk allocations will likely trigger kernel
memory management to enter slow path doing
On 5/11/2018 3:27 AM, Håkon Bugge wrote:
On 11 May 2018, at 01:31, Qing Huang wrote:
When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk allocations will likely trigger kernel
memory management to enter slow path doing memory compact/migration
ops
Thank you for reviewing it!
On 5/10/2018 6:23 PM, Yanjun Zhu wrote:
On 2018/5/11 9:15, Qing Huang wrote:
On 5/10/2018 5:13 PM, Yanjun Zhu wrote:
On 2018/5/11 7:31, Qing Huang wrote:
When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk
Thank you for reviewing it!
On 5/10/2018 6:23 PM, Yanjun Zhu wrote:
On 2018/5/11 9:15, Qing Huang wrote:
On 5/10/2018 5:13 PM, Yanjun Zhu wrote:
On 2018/5/11 7:31, Qing Huang wrote:
When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk
). So we need a 16MB allocation for a table->icm pointer array to
hold 2M pointers which can easily cause kcalloc to fail.
The solution is to use vzalloc to replace kcalloc. There is no need
for contiguous memory pages for a driver meta data structure (no need
of DMA ops).
Signed-off-by: Qing Hu
). So we need a 16MB allocation for a table->icm pointer array to
hold 2M pointers which can easily cause kcalloc to fail.
The solution is to use vzalloc to replace kcalloc. There is no need
for contiguous memory pages for a driver meta data structure (no need
of DMA ops).
Signed-off-by: Qing Hu
Thanks! Looks like Eran's patch will be available much sooner than v4.18
release time frame (since v4.16 was just released).
We will wait. :-)
On 04/26/2018 04:43 PM, Saeed Mahameed wrote:
Before you address my comments, it looks like Eran's work is
converging and we will finalize the
Thanks! Looks like Eran's patch will be available much sooner than v4.18
release time frame (since v4.16 was just released).
We will wait. :-)
On 04/26/2018 04:43 PM, Saeed Mahameed wrote:
Before you address my comments, it looks like Eran's work is
converging and we will finalize the
On 04/26/2018 02:50 PM, Saeed Mahameed wrote:
On Thu, Apr 26, 2018 at 1:37 PM, Qing Huang <qing.hu...@oracle.com> wrote:
Current stats collecting scheme in mlx5 driver is to periodically fetch
aggregated stats from all the active mlx5 software channels associated
with the device. Howeve
On 04/26/2018 02:50 PM, Saeed Mahameed wrote:
On Thu, Apr 26, 2018 at 1:37 PM, Qing Huang wrote:
Current stats collecting scheme in mlx5 driver is to periodically fetch
aggregated stats from all the active mlx5 software channels associated
with the device. However when a mlx5 interface
stats into netdev stats fields, so all the
accumulated stats will survive multiple runs of ifdown/ifup commands and
be shown correctly.
Orabug: 27548610
Signed-off-by: Qing Huang <qing.hu...@oracle.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 30 +++
stats into netdev stats fields, so all the
accumulated stats will survive multiple runs of ifdown/ifup commands and
be shown correctly.
Orabug: 27548610
Signed-off-by: Qing Huang
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 30 +++
1 file changed, 25 insertions
Hi Or,
On 12/13/2017 06:28 AM, Or Gerlitz wrote:
On Tue, Dec 12, 2017 at 5:21 AM, Qing Huang <qing.hu...@oracle.com> wrote:
Hi,
We found an issue with the bonding driver when testing Mellanox devices.
The following test commands will stall the whole system sometimes, with
serial c
Hi Or,
On 12/13/2017 06:28 AM, Or Gerlitz wrote:
On Tue, Dec 12, 2017 at 5:21 AM, Qing Huang wrote:
Hi,
We found an issue with the bonding driver when testing Mellanox devices.
The following test commands will stall the whole system sometimes, with
serial console
flooded with log messages
(resend this email in text format)
Hi,
We found an issue with the bonding driver when testing Mellanox devices.
The following test commands will stall the whole system sometimes, with
serial console
flooded with log messages from the bond_miimon_inspect() function.
Setting mtu size
to be
(resend this email in text format)
Hi,
We found an issue with the bonding driver when testing Mellanox devices.
The following test commands will stall the whole system sometimes, with
serial console
flooded with log messages from the bond_miimon_inspect() function.
Setting mtu size
to be
The size of path array could be dynamic. However the fixed number(2)
of memset could cause memory corruption by writing into wrong memory
space.
Fixes: 9fdca4da4d8c (IB/SA: Split struct sa_path_rec based on IB ands
ROCE specific fields)
Signed-off-by: Qing Huang <qing.hu...@oracle.
The size of path array could be dynamic. However the fixed number(2)
of memset could cause memory corruption by writing into wrong memory
space.
Fixes: 9fdca4da4d8c (IB/SA: Split struct sa_path_rec based on IB ands
ROCE specific fields)
Signed-off-by: Qing Huang
---
drivers/infiniband
On 5/23/2017 12:42 AM, Christoph Hellwig wrote:
On Mon, May 22, 2017 at 04:43:57PM -0700, Qing Huang wrote:
On 5/19/2017 6:05 AM, Christoph Hellwig wrote:
On Thu, May 18, 2017 at 04:33:53PM -0700, Qing Huang wrote:
This change will optimize kernel memory deregistration operations
On 5/23/2017 12:42 AM, Christoph Hellwig wrote:
On Mon, May 22, 2017 at 04:43:57PM -0700, Qing Huang wrote:
On 5/19/2017 6:05 AM, Christoph Hellwig wrote:
On Thu, May 18, 2017 at 04:33:53PM -0700, Qing Huang wrote:
This change will optimize kernel memory deregistration operations
On 5/19/2017 6:05 AM, Christoph Hellwig wrote:
On Thu, May 18, 2017 at 04:33:53PM -0700, Qing Huang wrote:
This change will optimize kernel memory deregistration operations.
__ib_umem_release() used to call set_page_dirty_lock() against every
writable page in its memory region. Its purpose
On 5/19/2017 6:05 AM, Christoph Hellwig wrote:
On Thu, May 18, 2017 at 04:33:53PM -0700, Qing Huang wrote:
This change will optimize kernel memory deregistration operations.
__ib_umem_release() used to call set_page_dirty_lock() against every
writable page in its memory region. Its purpose
choose not to set page dirty bit if it's
already set by kernel prior to calling __ib_umem_release(). This
reduces memory deregistration time by half or even more when we ran
application simulation test program.
Signed-off-by: Qing Huang <qing.hu...@oracle.com>
---
drivers/infiniband/core/umem
choose not to set page dirty bit if it's
already set by kernel prior to calling __ib_umem_release(). This
reduces memory deregistration time by half or even more when we ran
application simulation test program.
Signed-off-by: Qing Huang
---
drivers/infiniband/core/umem.c | 2 +-
1 file changed, 1
On 08/09/2016 03:11 AM, Shamir Rabinovitch wrote:
On Mon, Aug 08, 2016 at 05:10:05PM -0700, Qing Huang wrote:
Not sure if I understood your scenario. Why there is a deadlock here?
CPU0 | CPU1
On 08/09/2016 03:11 AM, Shamir Rabinovitch wrote:
On Mon, Aug 08, 2016 at 05:10:05PM -0700, Qing Huang wrote:
Not sure if I understood your scenario. Why there is a deadlock here?
CPU0 | CPU1
On 08/08/2016 03:42 AM, Shamir Rabinovitch wrote:
Hi Qing,
I suspect there is potential dead-lock with this patch:
cpu0cpu1
driver_deferred_probe_add deferred_probe_work_func
...
On 08/08/2016 03:42 AM, Shamir Rabinovitch wrote:
Hi Qing,
I suspect there is potential dead-lock with this patch:
cpu0cpu1
driver_deferred_probe_add deferred_probe_work_func
...
On 08/08/2016 01:44 PM, Frank Rowand wrote:
On 07/29/16 22:39, Qing Huang wrote:
In normal condition, the device probe requests kept in deferred
queue would only be triggered for re-probing when another new device
probe is finished successfully. This change will set up a delayed
trigger work
On 08/08/2016 01:44 PM, Frank Rowand wrote:
On 07/29/16 22:39, Qing Huang wrote:
In normal condition, the device probe requests kept in deferred
queue would only be triggered for re-probing when another new device
probe is finished successfully. This change will set up a delayed
trigger work
gre...@linuxfoundation.org>
Cc: Grant Likely <grant.lik...@linaro.org>
Cc: Santosh Shilimkar <santosh.shilim...@oracle.com>
Signed-off-by: Qing Huang <qing.hu...@oracle.com>
---
drivers/base/dd.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --g
Likely
Cc: Santosh Shilimkar
Signed-off-by: Qing Huang
---
drivers/base/dd.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 16688f5..251042d 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -53,6
58 matches
Mail list logo
