Hi Hal,
Hal Rosenstock wrote:
On Wed, Aug 25, 2010 at 4:43 AM, Eli Dorfman (Voltaire)
dorfman@gmail.com wrote:
Hal Rosenstock wrote:
Hi Eli,
On Mon, Aug 23, 2010 at 3:37 PM, Eli Dorfman dorfman@gmail.com wrote:
Hi Hal,
On Mon, Aug 23, 2010 at 5:25 PM, Hal Rosenstock
Hi Eli,
On Thu, Aug 26, 2010 at 2:24 AM, Eli Dorfman (Voltaire)
dorfman@gmail.com wrote:
Hi Hal,
Hal Rosenstock wrote:
On Wed, Aug 25, 2010 at 4:43 AM, Eli Dorfman (Voltaire)
dorfman@gmail.com wrote:
Hal Rosenstock wrote:
Hi Eli,
On Mon, Aug 23, 2010 at 3:37 PM, Eli Dorfman
On Thu, Aug 26, 2010 at 3:43 AM, Doron Shoham dor...@voltaire.com wrote:
add '-f' flag to show full information (ports' speed and witdh).
mainly to work with ibsim (using links real speed and width).
Just a couple of (output formatting) nits below...
Signed-off-by: Doron Shoham
add '-f' flag to show full information (ports' speed and witdh).
mainly to work with ibsim (using links real speed and width).
Signed-off-by: Doron Shoham dor...@voltaire.com
---
infiniband-diags/src/ibnetdiscover.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff
Add support functions to aid in packing IBoE packets.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/ud_header.c | 128 ++-
include/rdma/ib_pack.h | 30 +++-
2 files changed, 124 insertions(+), 34 deletions(-)
diff
This is done to synchronize mlx4 with the API changes.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/hw/mlx4/qp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
index
This is done to synchronize mthca with the API changes.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/hw/mthca/mthca_qp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c
The following patch handles address vectors creation for IBoE ports. mlx4 needs
the MAC address of the remote node to include it in the WQE of a UD QP or in
the QP context of connected QPs. Address resolution is done atomically in the
case of a link local address or a multicast GID and otherwise
Add 802.1q vlan support to IBoE. The vlan tag is encoded within the GID
derived from a link local address in the following way:
GID[11] GID[12] contain the vlan ID when the GID represents VLAN.
The 3 bits user priority field of the packets are identical to the 3 bits of
the SL.
In case rdma_cm
This is done to synchronize mthca with the API changes.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/hw/mthca/mthca_qp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c
This patch allows IBoE traffic to be encapsulated in 802.1q tagged VLAN
frames. The VLAN tag is encoded in the GID and derived from it by a simple
computation. The netdev notifier callback is modified to catch new VLAN devices
addition/removal and the port's GID table is updated to reflect the
This field can have one of the values - IBV_LINK_LAYER_UNSPECIFIED,
IBV_LINK_LAYER_INFINIBAND, IBV_LINK_LAYER_ETHERNET. It can be used by
applications to know the link layer used by the port, which can be either
Infiniband or Ethernet. The addition of the new field does not change the size
of
Modify the code to allow passing the link layer of a port from kernel to user.
Update ibv_query_port.3 man page with the change.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
include/infiniband/kern-abi.h |3 ++-
man/ibv_query_port.3 |1 +
src/cmd.c |1
Add a new API, resolve_eth_gid(), which resolves a GID to layer 2 address
information. A GID resembles an IPv6 link local address and encodes the MAC
address and the VLAN tag within it. The function accepts the destination GID,
port number and source GID index and returns the MAC, VLAN and
Since IBoE requires usage of GRH, update ibv_*_pinpong examples to accept GIDs.
GIDs are given as an index to the local port's table and are exchanged between
the client and the server through the socket connection. The examples are also
modified to pass the gid index to the code that creates the
Modify libmlx4 to support IBoE. The change involves retrieving the ethernet
layer 2 address of a port based on its GID and source index through a new
userspace call, resolve_eth_gid(), and embedding the layer 2 information in
the address vector representation of mlx4.
Signed-off-by: Eli Cohen
With the new IBoE implementation, Ethernet devices expose also IB devices.
Update the list of supported devices with that of the kernel.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
src/mlx4.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/mlx4.c
On Thu, 26 Aug 2010, Eli Cohen wrote:
With these patches, IBoE multicast frames may be broadcast as there is
currently no use of a L2 multicast group membership protocol.
May be? They are broadcast because there is no IGMP like support? Any
hopes of multicast support soon?
--
To unsubscribe
I had to move the check around a bit but the patch now passes our tests.
Please merge soon.
Subject: [IPoIB] Identify Multicast packets and fix IGMP breakage
IGMP processing is broken because the IPOIB does not set the
skb-pkt_type the right way for Multicast traffic. All incoming
packets are
@@ -330,15 +348,29 @@ static int cma_acquire_dev(struct rdma_id_private
*id_priv)
union ib_gid gid;
int ret = -ENODEV;
- rdma_addr_get_sgid(dev_addr, gid);
+ if (dev_addr-dev_type != ARPHRD_INFINIBAND) {
+ iboe_addr_get_sgid(dev_addr, gid);
How does this
+/* According to Jason Gunthorpe byte 24 in the GRH has the MGID */
I think we could put a better explanation here than Jason said so. In
fact since the GRH format matches the IPv6 header format, maybe we do
something like ((struct ipv6hdr *) skb-data)-daddr to get at the
DGID being used.
On Thu, 26 Aug 2010, Roland Dreier wrote:
also it's not clear to me why it's OK to do this test of the DGID if the
packet didn't have a GRH -- presumably we are just looking at random
uninitialized memory so we might incorrectly say some packets are
multicast if that byte happens to be 0xff.
On Thu, Aug 26, 2010 at 04:17:08PM -0500, Christoph Lameter wrote:
On Thu, 26 Aug 2010, Roland Dreier wrote:
also it's not clear to me why it's OK to do this test of the DGID if the
packet didn't have a GRH -- presumably we are just looking at random
uninitialized memory so we might
Is this better?
Subject: [IPoIB] Identify Multicast packets and fix IGMP breakage V2
IGMP processing is broken because the IPOIB does not set the
skb-pkt_type the right way for Multicast traffic. All incoming
packets are set to PACKET_HOST which means that the igmp_recv()
function will ignore
also it's not clear to me why it's OK to do this test of the DGID if the
packet didn't have a GRH -- presumably we are just looking at random
uninitialized memory so we might incorrectly say some packets are
multicast if that byte happens to be 0xff. (or does that not matter?
if so
From: Christoph Lameter c...@linux.com
Date: Thu, 26 Aug 2010 16:31:14 -0500 (CDT)
@@ -271,6 +271,13 @@ static void ipoib_ib_handle_rx_wc(struct
ipoib_ud_dma_unmap_rx(priv, mapping);
ipoib_ud_skb_put_frags(priv, skb, wc-byte_len);
+ if ((wc-wc_flags IB_WC_GRH)
+
On Thu, Aug 26, 2010 at 03:15:53PM -0700, David Miller wrote:
From: Christoph Lameter c...@linux.com
Date: Thu, 26 Aug 2010 16:31:14 -0500 (CDT)
@@ -271,6 +271,13 @@ static void ipoib_ib_handle_rx_wc(struct
ipoib_ud_dma_unmap_rx(priv, mapping);
ipoib_ud_skb_put_frags(priv, skb,
On Thu, 26 Aug 2010, Jason Gunthorpe wrote:
The 40 bytes at this location are defined by the HW specification to
be an IB GRH which has an identical layout to an IPv6 header. Roland
is right, it would be clearer to use ib_grh -dgid
Ok but then we have no nice function that checks for
On Thu, Aug 26, 2010 at 06:26:58PM -0500, Christoph Lameter wrote:
On Thu, 26 Aug 2010, Jason Gunthorpe wrote:
The 40 bytes at this location are defined by the HW specification to
be an IB GRH which has an identical layout to an IPv6 header. Roland
is right, it would be clearer to use
On Thu, 26 Aug 2010, Jason Gunthorpe wrote:
I think doing the memcmp only in the multicast path should be
reasonable overhead wise.
Thats is not always possible. Here the multicast path is the
default path that is taken 99% of the time.
--
To unsubscribe from this list: send the line
Were you going to try it this way?
/* First byte of dgid signals multicast/broadcast when 0xff */
if ((wc-wc_flags IB_WC_GRH)
((struct ib_grh *)skb-data)-dgid.raw[0] == 0xff) {
if (memcmp(((struct ib_grh *)skb-data)-dgid.raw,
From: Christoph Lameter c...@linux.com
Date: Thu, 26 Aug 2010 18:57:09 -0500 (CDT)
On Thu, 26 Aug 2010, Jason Gunthorpe wrote:
I think doing the memcmp only in the multicast path should be
reasonable overhead wise.
Thats is not always possible. Here the multicast path is the
default path
On Fri, Aug 27, 2010 at 03:02:54AM +0300, Yossi Etigin wrote:
Shouldn't struct ib_grh be packed to make this really work?
No idea what the kernel convention for this is. It looks OK to me, in
that no arch I am familiar with will insert padding.
The code looks a little messy to me anyway...
On Thu, 26 Aug 2010, David Miller wrote:
The highest cost is bringing in that packet header's cache line, which
you've already done by reading the byte and checking for 0xff.
And then you need to bring in the cacheline of the broadcast address
These are pretty long byte strings in the IB
On Thu, Aug 26, 2010 at 01:11:56PM -0700, Hefty, Sean wrote:
@@ -330,15 +348,29 @@ static int cma_acquire_dev(struct rdma_id_private
*id_priv)
union ib_gid gid;
int ret = -ENODEV;
- rdma_addr_get_sgid(dev_addr, gid);
+ if (dev_addr-dev_type != ARPHRD_INFINIBAND) {
+
35 matches
Mail list logo
