Jason Gunthorpe wrote:
OFED works on kernels that have compiled-in inline'd multicast map functions
that do not include the pkey copy, while mainline's multicast map functions do.
So to work around this there is a bit of code in OFED to overwrite the pkey in
the multicast hw address. This
Hi,
This message follows a discussion in the EWG mailing list.
We want to promote a patch that enables use of a new QP type.
This QP type lets the user post_send() data to its SQ and treat it as the
entire packet, including headers.
An example of use with this QP is sending Ethernet packets from
I would prefer a name IBV_QPT_FRAME so it is a L2 layerQP. The packet is
reserved for L3.
Regards,
Mirek
-Original Message-
From: Moni Shoua [mailto:mo...@voltaire.com]
Sent: Wednesday, June 23, 2010 11:20 AM
To: linux-rdma
Cc: Walukiewicz, Miroslaw; Roland Dreier; al...@voltaire.com
It is true that on the send path for such a QP you can send any sort of
packet. The user of the QP is required to build the MAC header and the
NIC will wrap the post_sent data in an Ethernet type II frame which
includes the tailing CRC.
On the receive path this QP assume an MAC header. The qp
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/cm.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c
index f75108f..8c9b483 100644
---
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/cm.c | 10 +-
drivers/infiniband/hw/cxgb4/t4fw_ri_api.h | 10 ++
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/cm.c
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/device.c |9 +++--
drivers/infiniband/hw/cxgb4/resource.c |7 ---
drivers/infiniband/hw/cxgb4/t4.h |2 --
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git
Hey Roland,
Please ignore these 3 patches. I forgot to run checkpatch on them and
they need some cleanup.
I'll re-submit as v2 of the series.
Sorry for the noise.
Steve.
Steve Wise wrote:
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/cm.c |9
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/cm.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c
index f75108f..8c9b483 100644
---
Turn off IB latency mode. This improves link quality for slower
process chips.
Signed-off-by: Ralph Campbell ralph.campb...@qlogic.com
---
drivers/infiniband/hw/qib/qib_iba7322.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/qib/qib_iba7322.c
Chris Worley, on 06/22/2010 08:06 PM wrote:
When given an LBA w/ a bad boundary, the drive returns an error and
the target side says:
dev_vdisk: ***ERROR***: cmd 810196f58b70 returned error -22
... and the initiator:
sd 8:0:0:0: SCSI error: return code = 0x0802
sdc: Current: sense
iWARP is just another protocol on top of TCP - like iSCSI. There is
no good reason to invent another TCP port maintainer per TCP user
type trying to synchonize with the kernel if the resource is host
global and already maintained by the kernel.
I think the counter-argument to this is than
There is no qp type IBV_QPT_RAW_ETY in user space (at least not in the
definitions
coming with libibverbs). In fact, libibverbs that comes with OFED defines
(in verbs.h)
a qp type called IBV_QPT_RAW_ETT which equals to 7.
The patch that is under discussion here adds a new qp type
On Wed, Jun 23, 2010 at 11:08 AM, Vladislav Bolkhovitin v...@vlnb.net wrote:
Chris Worley, on 06/22/2010 08:06 PM wrote:
When given an LBA w/ a bad boundary, the drive returns an error and
the target side says:
dev_vdisk: ***ERROR***: cmd 810196f58b70 returned error -22
... and the
Roland Dreier wrote:
Since we are developing and already open sourced a full software
implementation (SoftiWARP) of RDMA, our view on the optimal solution
must be different. Like kernel iSCSI, we are running on top of regular
kernel sockets. With that, there is no point having a
On the other hand, I never fully understood what does IBV_QPT_RAW_ETY
stand for? Maybe we should change its name to better represent what the
code does.
Picking names for things is not my strongest suit, and I don't have a
very good suggestion, so I'll leave that out. But on the point
The following patches are for various bug fixes.
I'm not sure what counts as a regression for code that is newly introduced.
I'm hoping that all except #2 can be made for 2.6.35 whereas
#2 can wait for 2.6.36 since it is actually a feature.
All except #2 look OK for 2.6.35. I'll hold #2
Roland, do you think the iSCSI approach is a good design for iWARP
devices?
Well, it's a different problem since as I said the port collision
problem is a non-issue for iSCSI anyway. But yes having a separate
interface to assign an iWARP IP address to an RNIC does seem to avoid
the immediate
I think this is an extremely strong argument against the patch that
started the thread. Breaking soft iWARP seems a fatal flaw.
- R.
I agree.
The patch or SoftiWARP can be reworked to allow the whole iWARP family
to coexist. It is a matter of agreeing on which path to take.
Chien
Tung, Chien Tin wrote:
I think this is an extremely strong argument against the patch that
started the thread. Breaking soft iWARP seems a fatal flaw.
- R.
I agree.
The patch or SoftiWARP can be reworked to allow the whole iWARP family
to coexist. It is a matter of agreeing
I just think the customer looses when we add iwarp-specific tools,
ipaddrs, subnets, etc etc. And what about software iwarp? Will it
use the host stack tools and not these new tools? So then we end up
with 2 sets of tools for iwarp devices. :(
Agree -- but same prob with current iSCSI
what's smac_idx? what's port viid?
hard to know what the heck this fixes :)
--
Roland Dreier rola...@cisco.com || 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 in
is this fixing anything? ie 2.6.35 or .36?
--
Roland Dreier rola...@cisco.com || 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 in
the body of a message to
again fixing anything or just cleaning up?
--
Roland Dreier rola...@cisco.com || 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 in
the body of a message to
Roland Dreier wrote:
what's smac_idx? what's port viid?
hard to know what the heck this fixes :)
smac_idx == source mac index: the index into the HW source mac table.
viid = Virtual Interface ID: for virtualization, this allows having smac
tables, among other things, per virtual
Roland Dreier wrote:
is this fixing anything? ie 2.6.35 or .36?
2.6.36.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Roland Dreier wrote:
again fixing anything or just cleaning up?
This one is dependent on a cxgb3 change merged into net-next.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On the other hand trying to hook offloaded iWARP into the normal stack
does seem to lead to a mess. I see DaveM's point: TCP port space is
just the beginning -- filtering, queueing, etc also have config that
ultimately an offload device would want to hook too.
TCP port space is just the
On Wed, Jun 23, 2010 at 01:46:47PM -0500, Steve Wise wrote:
Yes. Perusing the drivers/scsi/cxgb3i code I see the iscsi ipaddr is
actually stored in the port_info struct which is hung of the netdev_priv
of the cxgb3 device. It is set by cxgb3i_host_set_param() which is part
of the
Jason Gunthorpe wrote:
On Wed, Jun 23, 2010 at 01:46:47PM -0500, Steve Wise wrote:
Yes. Perusing the drivers/scsi/cxgb3i code I see the iscsi ipaddr is
actually stored in the port_info struct which is hung of the netdev_priv
of the cxgb3 device. It is set by cxgb3i_host_set_param()
I wonder how does neighbor discovery, routing, etc work with iscsi?
For cxgb3i:
ND is handled by initiating ND via exported kernel services
(neigh_event_send()) and registering for NETEVENT_NEIGH_UPDATE net
events to get updated neigh entries.
The host routing table is consulted via
Steve Wise wrote:
I wonder how does neighbor discovery, routing, etc work with iscsi?
For cxgb3i:
ND is handled by initiating ND via exported kernel services
(neigh_event_send()) and registering for NETEVENT_NEIGH_UPDATE net
events to get updated neigh entries.
The host routing
On the other hand trying to hook offloaded iWARP into the normal stack
does seem to lead to a mess. I see DaveM's point: TCP port space is
just the beginning -- filtering, queueing, etc also have config that
ultimately an offload device would want to hook too.
TCP port space is
On Wed, Jun 23, 2010 at 02:42:43PM -0500, Steve Wise wrote:
I wonder how does neighbor discovery, routing, etc work with iscsi?
For cxgb3i:
ND is handled by initiating ND via exported kernel services
(neigh_event_send()) and registering for NETEVENT_NEIGH_UPDATE net
events to get
Doesn't that mean the port collision problem still exits [for iSCSI],
although probably less likely?
Yes, it's there, but almost impossible to hit: first of all, iSCSI HBAs
never listen on a port, so that can never collide. Second, iSCSI HBAs
only establish connections to iSCSI targets on
Jason Gunthorpe wrote:
On Wed, Jun 23, 2010 at 02:42:43PM -0500, Steve Wise wrote:
I wonder how does neighbor discovery, routing, etc work with iscsi?
For cxgb3i:
ND is handled by initiating ND via exported kernel services
(neigh_event_send()) and registering for
Roland Dreier wrote:
Doesn't that mean the port collision problem still exits [for iSCSI],
although probably less likely?
Yes, it's there, but almost impossible to hit: first of all, iSCSI HBAs
never listen on a port, so that can never collide. Second, iSCSI HBAs
only establish connections
Jason Gunthorpe wrote:
On Wed, Jun 23, 2010 at 03:11:27PM -0500, Steve Wise wrote:
The IP address assigned for the cxgb3i iscsi device is _not_ assigned to
a netdev interface via ifconfig, as far as I understand it (by looking
at the cxgb3i code). So the host stack doesn't know about
Steve Wise wrote:
Jason Gunthorpe wrote:
On Wed, Jun 23, 2010 at 03:11:27PM -0500, Steve Wise wrote:
The IP address assigned for the cxgb3i iscsi device is _not_
assigned to a netdev interface via ifconfig, as far as I understand
it (by looking at the cxgb3i code). So the host stack
On Wed, Jun 23, 2010 at 03:19:31PM -0500, Steve Wise wrote:
So who responds to neighbor queries, and how do outgoing queries get
sent with the right IP? Sounds odd...
The iscsi hba is only an initiator, so it doesn't need to respond to arp
queries.
Hmm.. The other side could arp you at
Jason Gunthorpe wrote:
On Wed, Jun 23, 2010 at 03:19:31PM -0500, Steve Wise wrote:
So who responds to neighbor queries, and how do outgoing queries get
sent with the right IP? Sounds odd...
The iscsi hba is only an initiator, so it doesn't need to respond to arp
queries.
On the other hand trying to hook offloaded iWARP into the normal stack
does seem to lead to a mess. I see DaveM's point: TCP port space is
just the beginning -- filtering, queueing, etc also have config that
ultimately an offload device would want to hook too.
TCP port space
If the table is placed in mlx4_core (as of today in upstream), then I
assume the mlx4_en and _ib aren't being probed by pci hot-plug
mechasnisms, correct? else if you put it in _en _ib et al files, then
one has to maintain two copies of the table, but maybe this would be
the correct
This is actually a continue of the RAW_ET() issue. We want to
make a submition of the patches to the upstream, but there is not
support for IB transport in Ethernet devices, and the mlx4_en drivers
version is a bit outdated 1.4.1.1 in upstream and 1.5.1 in the OFED
There is also
44 matches
Mail list logo
