One of our customers recently merged some new systems into a
large, existing cluster. They requested a mechanism to prevent
opensm from sweeping while the new equipment was being added to
the IB fabric, and then resume sweeping once they felt confident
that the newly added (sub)fabric was correctl
> Looks ok to me. Functionally it doesn't change anything I guess.
That's the hope at least...
--
Roland Dreier || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma"
Looks ok to me. Functionally it doesn't change anything I guess.
Roland Dreier wrote:
Hey Steve,
What do you think about this for the next merge window? I think it
arguably makes the source cleaner, and it definitely makes the compiled
code better:
add/remove: 0/1 grow/shrink: 4/3 up/down:
Hey Steve,
What do you think about this for the next merge window? I think it
arguably makes the source cleaner, and it definitely makes the compiled
code better:
add/remove: 0/1 grow/shrink: 4/3 up/down: 4/-1682 (-1678)
function old new delta
tx_ack
Hi,
I think this is because sdp_add_device() require FMR to be supported.
I need to put a fix to disable ZCopy and not create FMR pool if doesn't
have support - I thought it would be part of BZ2027 fix.
As a workaround - you could comment out all the calls to
sdp_dev->fmr_pool. and make sure ZCop
On Apr 27, 2010 01:25 PM, Amir Vadai wrote:
> Andrea Hi,
>
> I am sorry - the commit missed the 24.4.2010 build which I asked you
> to
> test.
> Please test this build (the latest): OFED-1.5.2-20100426-0600
>
> - Amir
>
>
> On 04/27/2010 01:34 PM, Andrea Gozzelino wrote:
> > Hi Amir,
> > I h
