Profiling has shown that sdma_lock is proving a bottleneck for
performance. The situations include:
- RDMA reads when krcvqs > 1
- post sends from multiple threads
For RDMA read the current global qib_wq mechanism runs on all CPUs
and contends for the sdma_lock when multiple RMDA read requests are
From: Mitko Haralanov
Add support for per-device/per-port driver parameters
allowing users to specify different values for different
ports/devices. All converted parameters will behave as
expected if the old parameter format is used.
New per-device/per-port parameter format:
=[,][:]=[,[:]=]
From: Mitko Haralanov
Convert the krcvqs module paratemter from a per-unit
parameter to a per-port one. This allows the user to
specify kernel receive contexts allocation on each
individual port.
Signed-off-by: Mitko Haralanov
Signed-off-by: Mike Marciniszyn
---
drivers/infiniband/hw/qib/qib.
Added a congestion control agent in the driver that handles
gets and sets from the congestion control manager in the
fabric for the Performance Scale Messagin (PSM) library.
Signed-off-by: Mike Marciniszyn
---
drivers/infiniband/hw/qib/qib.h | 35
drivers/infiniband/hw/qib/qib_init.
From: Shlomo Pongratz
Dave Miller provided a detailed description of why the
way IPoIB is using neighbours for its own ipoib_neigh struct is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
It seems that for some reason the cover-letter wasn't sent properly,
here's listing of the changes:
changes from V0:
- following feedback from Mike and Dave, changed the ipoib_neigh hash table
to allow for lock-free read side, the model follows the RCU based
implementation
in net/core/neig
changes from V0:
- following feedback from Mike and Dave, changed the ipoib_neigh hash table
to allow for lock-free read side, the model follows the RCU based
implementation
in net/core/neighbour.c
- since RCU hash table uses unidirectional collision list, now ipoib_neigh_free
needs to
On Thu, 19 Jul 2012, Or Gerlitz wrote:
> Aged ipoib_neigh instances are deleted by a garbage collection task that runs
> every
> 30 seconds and deletes every ipoib_neigh instance that was idle for at least
> 60
> seconds. The deletion is safe since the ipoib_neigh instances are protected
> using
On 7/19/2012 5:42 PM, Christoph Lameter wrote:
On Thu, 19 Jul 2012, Or Gerlitz wrote:
Aged ipoib_neigh instances are deleted by a garbage collection task that runs
every
30 seconds and deletes every ipoib_neigh instance that was idle for at least 60
seconds. The deletion is safe since the ipoi
On Thu, 19 Jul 2012, Shlomo Pongartz wrote:
> The garbage collection and stale times follow the default ipv4/6
> neigh.default.gc_yyy
> sysctl values, for example
>
> net.ipv4.neigh.default.gc_interval = 30
> net.ipv4.neigh.default.gc_stale_time = 60
>
> If given access to these values from IPoIB,
You should CC: netdev on patches like this.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 7/19/2012 6:40 PM, David Miller wrote:
You should CC: netdev on patches like this.
OK, I was just thinking that cross-posting typically create more damage
than benefit... will do RESEND now to linux-rdma && netdev
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
t
Adding netdev, as of the high relevancy, see V0 @
http://marc.info/?l=linux-rdma&m=134191474831867&w=2
changes from V0:
- following feedback from Mike and Dave, changed the ipoib_neigh hash table
to allow for lock-free read side, the model follows the RCU based
implementation
in net/core/n
From: Shlomo Pongratz
Dave Miller provided a detailed description of why the
way IPoIB is using neighbours for its own ipoib_neigh struct is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
On 7/19/2012 6:24 PM, Christoph Lameter wrote:
On Thu, 19 Jul 2012, Shlomo Pongartz wrote:
The garbage collection and stale times follow the default ipv4/6
neigh.default.gc_yyy
sysctl values, for example
net.ipv4.neigh.default.gc_interval = 30
net.ipv4.neigh.default.gc_stale_time = 60
If giv
From: Or Gerlitz
Date: Thu, 19 Jul 2012 19:20:41 +0300
> On 7/19/2012 6:24 PM, Christoph Lameter wrote:
>> On Thu, 19 Jul 2012, Shlomo Pongartz wrote:
>>
>>> The garbage collection and stale times follow the default ipv4/6
>>> neigh.default.gc_yyy
>>> sysctl values, for example
>>>
>>> net.ipv4.n
There is a cut and paste typo in the function qib_pci_slot_reset() where
it prints that the "link_reset" function is called rather than the
"slot_reset" function. This makes the message misleading.
Signed-off-by: Betty Dall
---
drivers/infiniband/hw/qib/qib_pcie.c |2 +-
1 files changed, 1 i
On Thu, 2012-07-19 at 13:34 -0600, Betty Dall wrote:
> There is a cut and paste typo in the function qib_pci_slot_reset() where
> it prints that the "link_reset" function is called rather than the
> "slot_reset" function. This makes the message misleading.
Hi Betty.
> diff --git a/drivers/infinib
thanks, applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
thanks, applied 1, 2, & 5. see my comments about #3
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[resending because I forgot to cc linux-rdma]
On Thu, Jul 19, 2012 at 6:04 AM, Mike Marciniszyn
wrote:
> Add support for per-device/per-port driver parameters
> allowing users to specify different values for different
> ports/devices. All converted parameters will behave as
> expected if the old
Hi Joe,
Thanks for the comment Joe. It looks like Roland already accepted the
trivial change.
On Thu, 2012-07-19 at 11:03 -0700, Joe Perches wrote:
> On Thu, 2012-07-19 at 13:34 -0600, Betty Dall wrote:
> > There is a cut and paste typo in the function qib_pci_slot_reset() where
> > it prints tha
On Thu, 2012-07-19 at 12:56 -0600, Betty Dall wrote:
> Thanks for the comment Joe. It looks like Roland already accepted the
> trivial change.
No worries.
> On Thu, 2012-07-19 at 11:03 -0700, Joe Perches wrote:
> > On Thu, 2012-07-19 at 13:34 -0600, Betty Dall wrote:
[]
> > > diff --git a/drivers
On Thu, Jul 19, 2012 at 9:26 PM, Roland Dreier wrote:
> I think this is pushing the module parameter facility way past the
> breaking point of usability. We really need to come up with a better
> way to get complex structured config info like this into the drive
IB's netlink infrastructure?
Or
> [5416523.203047] ib_srpt: Received SRP_LOGIN_REQ with i_port_id
> 0x0:0x2c903004ecf8b, t_port_id 0x2c903004ecf82:0x2c903004ecf82 and
> it_iu_len 260 on port 1 (guid=0xfe80:0x2c903004ecf83)
> [5416523.204736] kworker/0:4: page allocation failure: order:4, mode:0x40d0
> [5416523.204738]
25 matches
Mail list logo
