On Tue, 16 Jun 2009 09:10:39 -0700
Roland Dreier rdre...@cisco.com wrote:
Yeah, the notifier code remains untouched as we still do not allow dynamic
memory operations _while_ our module is loaded. The patch allows the
driver to
cope with DMEM operations that happened before the
On Mon, Jun 15, 2009 at 02:26:42PM -0400, Hal Rosenstock wrote:
Should ib_post_send_mad return some error on QP0 sends on RDMAoE ports ?
You can't send anything over QP0 because it is not created and so
there are no data structs corresponding to it.
What QP1 sends are allowed ?
Basically, all
On Tue, Jun 16, 2009 at 10:27:33AM -0700, Sean Hefty wrote:
+
+w-member-multicast.rec.qkey = cpu_to_be32(0xc2c);
How can a user control this? An app needs the same qkey for unicast traffic.
In RDMAoE, the qkey has a fixed well-known value, which will be
returned both by multicast and
On Tue, Jun 16, 2009 at 11:16:28AM -0500, Steve Wise wrote:
Hey Eli,
Does this series implement UD/multicast support?
I didn't see it with a quick perusal of the patches.
Hi Steve,
yes UD multicast is supported. Note that in this version of the
pathces I use the broadcast MAC address (all
On Wed, Jun 17, 2009 at 7:10 AM, Eli Cohene...@dev.mellanox.co.il wrote:
On Mon, Jun 15, 2009 at 02:26:42PM -0400, Hal Rosenstock wrote:
Should ib_post_send_mad return some error on QP0 sends on RDMAoE ports ?
You can't send anything over QP0 because it is not created and so
there are no data
On Wed, Jun 17, 2009 at 07:14:56AM -0400, Hal Rosenstock wrote:
On Wed, Jun 17, 2009 at 7:10 AM, Eli Cohene...@dev.mellanox.co.il wrote:
On Mon, Jun 15, 2009 at 02:26:42PM -0400, Hal Rosenstock wrote:
Should ib_post_send_mad return some error on QP0 sends on RDMAoE ports ?
You can't send
On Wed, Jun 17, 2009 at 7:57 AM, Eli Cohene...@dev.mellanox.co.il wrote:
On Wed, Jun 17, 2009 at 07:14:56AM -0400, Hal Rosenstock wrote:
On Wed, Jun 17, 2009 at 7:10 AM, Eli Cohene...@dev.mellanox.co.il wrote:
On Mon, Jun 15, 2009 at 02:26:42PM -0400, Hal Rosenstock wrote:
Should
Why not just use IP to MAC calls? Or use the MAC as the GUID?
We do use standard OS services to map the IP addresses (that were
encoded in the GID) to MACs.
GIDs encode IP addresses rather than MACs to enable users to use the
node names that they are used to.
Specifically, we will feed in all
From: Sasha Khapyorsky [mailto:sashakv...@gmail.com] On Behalf Of Sasha
Khapyorsky
Sent: Wednesday, June 17, 2009 11:32 AM
To: Todd Rimmer
Cc: Tziporet Koren; ewg@lists.openfabrics.org
Subject: Re: [ewg] RE: OFED libraries - on the web at last
On 08:14 Wed 17 Jun , Todd Rimmer wrote:
Hum, This is a very tricky subject. Co-mingling the IB GID address
space and the IPv6 address space like this is not really something
that was envisioned from the IBA side.
Doesn't the IB spec say that an IB GID *is* an IPv6 address? So in
theory it should be OK; however I don't think in
Eli Cohen wrote,
RDMA over Ethernet (RDMAoE) allows running the IB transport protocol over
Ethernet, providing IB capabilities for Ethernet fabrics. The packets are
standard Ethernet frames with an Ethertype, an IB GRH, unmodified IB transport
headers and payload. HCA RDMAoE ports are no
On Wed, Jun 17, 2009 at 11:20:26AM -0700, Roland Dreier wrote:
Hum, This is a very tricky subject. Co-mingling the IB GID address
space and the IPv6 address space like this is not really something
that was envisioned from the IBA side.
Doesn't the IB spec say that an IB GID *is* an
It is like an IPv6 address but it was expressly envisioned to be a
seperate space. The IBA authors copied many of the conventions from
IPv6 for numbering this new space, like link local, and multicast
prefixes, but it was not intended to be co-mingled.
Well (I've quoted this many times):
On Wed, Jun 17, 2009 at 11:38:43AM -0700, Roland Dreier wrote:
It is like an IPv6 address but it was expressly envisioned to be a
seperate space. The IBA authors copied many of the conventions from
IPv6 for numbering this new space, like link local, and multicast
prefixes, but it was
Hmm, murky indeed. Your point about IGMPv6 is well made. The problem
is that IB GRHs are not IPv6 headers and have different numerology for
the Next Header field. Ie in IPv6 Next Header 0x1B is RFC 908, while
in GRH it is a BTH. Labeling GRHs with an IPv6 ethertype is
fundamentally
Hey Vlad,
Please pull from:
ssh://v...@sofa.openfabrics.org/~swise/scm/ofed_kernel.git ofed_1_5
This adds RHEL5.2 backports for cxgb3.
Thanks,
Steve.
---
commit 9167dcdbc40252562fd826acc0598853456deafc
Author: Steve Wise sw...@opengridcomputing.com
Date: Wed Jun 17 19:16:31 2009 -0500
16 matches
Mail list logo
