The text is saying that the specification does not use any of the
LID fields in the verbs interface, that is it. It isn't talking
about MAC addresses.
Exactly how and where the MAC address comes about was
never decided,
and at least some participants thought it should be a
But, we can't mandate an overload of the GID in a way that
it prevents its use as a true L3 address (eventually routable).
Actually I'm beginning to think that the only possible way we
can use the GID in IBoE is as a link-local IPv6 addresses
containing an Ethernet address. Trying
A quibble about multicast - AFAIK this is unsolved. I
think some spec needs to be agreed that documents what
sort of multicast snooping operations switches need to do,
ie if IGMP joins imply that IBoE traffic for the same DMAC
is included in the join, or if IBoE requires a
Pradeep Satyanarayana wrote:
Pradeep Satyanarayana wrote:
Roland Dreier wrote:
I guess I came to a premature conclusion. One set of tests ran fine and
I made that
conclusion. Another set of tests caused the following crash:
I don't really know how to interpret this. Is this crash new,
Hello Arlin,
I am Or's colleague whom he assist with this manner.
OK, we got Intel MPI to run. To test the pkey usage we configured it to run
over pkey that is not configured on the node. In this case the MPI should have
failed, but it didn't.
The dapl debug reports the given pkey (0x8001 =
Now firmware version is read from correct place
Signed-off-by: Mirek Walukiewicz miroslaw.walukiew...@intel.com
---
drivers/infiniband/hw/nes/nes_verbs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/nes/nes_verbs.c
Now correct interface link type is set for ibv_query_port()
Signed-off-by: Mirek Walukiewicz miroslaw.walukiew...@intel.com
---
drivers/infiniband/hw/nes/nes_verbs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/nes/nes_verbs.c
OK, we got Intel MPI to run. To test the pkey usage we
configured it to run over pkey that is not configured on the
node. In this case the MPI should have failed, but it didn't.
The dapl debug reports the given pkey (0x8001 = 32769).
How can that be?
Itay,
If the pkey override is not valid
On Thu, Jul 15, 2010 at 01:55:32PM +0300, Liran Liss wrote:
I objected to the draft spec leaving this area
absent, even.
You should submit a comment on this matter using the IBTA comment
tracker database if you intend your concern to be taken into account.
The position of IBTA is that
No:
No. Same warning:
[r...@dodly0 compat-dapl-1.2.18]# mpiexec -ppn 1 -n 2 -env I_MPI_FABRICS
dapl:dapl -env I_MPI_DEBUG 2 -env I_MPI_CHECK_DAPL_PROVIDER_MISMADAPL_DBG_TYPE
0x -env DAPL_IB_PKEY 0x8002 /tmp/osu
dodly4:625b: dapl_init: dbg_type=0x,dbg_dest=0x1
dodly0:2c17: dapl_init:
No, I think all switches will flood unknown multicast packets. But
there is a reason that IGMP snooping was invented -- it is inefficient
(to say the least) to flood all multicast traffic.
And by the way I view the fact that the IBoE spec does not say anything
at all about how to map MGIDs
No:
No. Same warning:
dodly4:625b: Warning: new pkey(32770), query (Success) err or
key !found, using defaults
dodly4:625b: query_hca: port.link_layer = 0x1
dodly4:625b: query_hca: (a0.0) eps 262076, sz 16351 evds
65408, sz 4194303 mtu 2048 - pkey 32770 p_idx 0 sl 0
[r...@dodly0
Itay,
Can you add -env I_MPI_DAPL_PROVIDER ofa-v2-mthca0-1 to your mpiexec options
to make sure we pick up the correct v2 provider with pkey support? Also bump
up I_MPI_DEBUG to 5 so I can see the provider selection from MPI output.
Thanks,
-arlin
-Original Message-
From: Itay Berman
From: Peter Huewe peterhu...@gmx.de
This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and
.subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the
PCI_VDEVICE macro, and thus improves readability.
Signed-off-by: Peter Huewe peterhu...@gmx.de
---
No, I think all switches will flood unknown multicast packets. But
there is a reason that IGMP snooping was invented -- it is inefficient
(to say the least) to flood all multicast traffic.
- R.
Small correction needed regarding the multicast forwarding.
Since we are talking about IPv6
I will write up a description of the locking as I
understand it and the changes I made. Give
me a day or two to write it up and check it.
On Thu, 2010-07-15 at 04:56 -0700, Pradeep Satyanarayana wrote:
Pradeep Satyanarayana wrote:
Pradeep Satyanarayana wrote:
Roland Dreier wrote:
I guess
Small correction needed regarding the multicast forwarding.
Since we are talking about IPv6 multicast groups, which translate to
33:33:xx:xx:xx:xx MAC address, the router listener notification protocol
is going to be MLD and not IGMP. Still there are switches which support
MLD forwarding
On Thu, 2010-07-15 at 04:56 -0700, Pradeep Satyanarayana wrote:
Pradeep Satyanarayana wrote:
Pradeep Satyanarayana wrote:
Roland Dreier wrote:
I guess I came to a premature conclusion. One set of tests ran fine
and I made that
conclusion. Another set of tests caused the following
18 matches
Mail list logo
