sebastien dugue wrote:
So I guess you need to change the ports used within the new port space -- but then
why can't you just stay in the TCP space but change the ports used?
No, with the new port space, there's no need to change ports. You only need to
specify the target GUIDs. For
On Wed, 20 Jan 2010 10:03:47 +0200
Or Gerlitz ogerl...@voltaire.com wrote:
sebastien dugue wrote:
So I guess you need to change the ports used within the new port space --
but then
why can't you just stay in the TCP space but change the ports used?
No, with the new port space,
Hi Slava,
On 16:11 Thu 03 Dec , Slava Strebkov wrote:
Proposed new algorithm for calculation of root switch for multicast
spanning tree. Only edge switches(those connected to hosts) and
switches - multicast members themselves are involved in root calculation.
This gives improvement,
Hi Sasha,
average hops was chosen instead of max hops because in root weight
calculation the number of ports is also important, not only the distance
(hops).
Slava
-Original Message-
From: Sasha Khapyorsky [mailto:sashakv...@gmail.com] On Behalf Of Sasha
Khapyorsky
Sent: Wednesday,
On 13:32 Wed 20 Jan , Slava Strebkov wrote:
average hops was chosen instead of max hops because in root weight
calculation the number of ports is also important, not only the distance
(hops).
But this patch is declared as root switch calculation optimization, not
as algorithm change
sebastien dugue wrote:
No, because in OpenSM's QoS logic, there's no way to map the TCP port
space with specific target GUIDs onto an SL. You have keywords for SDP, SRP,
RDS, ISER, ... but not for the TCP port space (or am I missing something?).
going with this, what prevents you from
Roland Dreier wrote:
In other words this check catches common bugs and makes them a gazillion times
easier to find and fix. So unless the performance impact is extreme, I'm
inclined to leave it
okay, lets leave this like that for unless someone comes with
performance data that shows this is
Or Gerlitz wrote:
As of commit f56bcd8 IPoIB: Use separate CQ for UD send completions,
there are no TX interrupts at the main code path. Change the ethtool
related code to comply with this, such the users will not be misleaded
to assume they can control TX interrupt moderation.
Hi Roland, did
Looks like a sysfs problem or maybe a SCSI - sysfs interaction that
doesn't have much to do with ib_srp in particular. The two locks
involved, namely s_active and attribute_container_mutex, are completely
outside of ib_srp and are taken out of its control.
This is probably triggering now because
I'll contribute my 2c here, as I have experienced some page allocation
errors in the past when using drbd and cm. I think drbd in particular
might trigger it since it's pushes a lot of data through the link, but
regardless the circumstances are somewhat difficult to replicate. I'm not
On Wed, Jan 20, 2010 at 8:16 PM, Roland Dreier rdre...@cisco.com wrote:
- * may also be |ed in to request a hint about missed events, as
+ * may also be passed in to request a hint about missed events, as
I don't think this is a typo -- the comment is trying to say that the
report
On Tue, Jan 19, 2010 at 05:09:49PM -0800, Roland Dreier wrote:
The last time I tried to use it the kernel began reporting lots of
OOM events (2.6.30 stock). I thought this was well known because CM
mode uses high order allocations??
That's not well-known to me. What's the backtrace
The DMA api requires that the full mapping be sync'd when
copying frame. First found by Jarek on sky2.
Signed-off-by: Stephen Hemminger shemmin...@vyatta.com
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c 2010-01-20 12:02:29.269388203
-0800
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
Woodruff, Robert J wrote:
[wo...@det-17 src]$ ucmatose -b 192.168.0.17
cmatose: starting server
cmatose: bind address failed: No such file or directory
return status -1
A case were rdma_bind returns -ENOENT was debugged here this week with the
problem being the same IP assigned to two
14 matches
Mail list logo
