On Tue, 2006-12-05 at 10:02 -0600, Steve Wise wrote:
> On Tue, 2006-12-05 at 11:45 +0100, Brice Goglin wrote:
> > Steve Wise wrote:
> > > There is no SW TCP stack in this driver. The HW supports RDMA over
> > > TCP/IP/10GbE in HW and this is required for zero-copy RD
On Tue, 2006-12-05 at 10:12 -0600, Steve Wise wrote:
> On Tue, 2006-12-05 at 18:59 +0300, Evgeniy Polyakov wrote:
> > On Tue, Dec 05, 2006 at 09:39:58AM -0600, Steve Wise ([EMAIL PROTECTED])
> > wrote:
> > > > Phrases like "MPA-aware TCP" rise
On Tue, 2006-12-05 at 18:59 +0300, Evgeniy Polyakov wrote:
> On Tue, Dec 05, 2006 at 09:39:58AM -0600, Steve Wise ([EMAIL PROTECTED])
> wrote:
> > > Phrases like "MPA-aware TCP" rises a lot of questions - briefly saying
> > > that hardware (even if it is
On Tue, 2006-12-05 at 11:45 +0100, Brice Goglin wrote:
> Steve Wise wrote:
> > There is no SW TCP stack in this driver. The HW supports RDMA over
> > TCP/IP/10GbE in HW and this is required for zero-copy RDMA over Ethernet
> > (aka iWARP). The device is a 10 GbE d
On Tue, 2006-12-05 at 18:27 +0300, Evgeniy Polyakov wrote:
> On Tue, Dec 05, 2006 at 09:14:36AM -0600, Steve Wise ([EMAIL PROTECTED])
> wrote:
> > Chelsio doesn't implement TCP stack in the driver. Just like Ammasso,
> > it sends messages to the HW to setup connections
On Tue, 2006-12-05 at 18:19 +0300, Evgeniy Polyakov wrote:
> On Tue, Dec 05, 2006 at 09:02:05AM -0600, Steve Wise ([EMAIL PROTECTED])
> wrote:
> > > > > This and a lot of other changes in this driver definitely says you
> > > > > implement your own sta
On Mon, 2006-12-04 at 21:27 -0800, Roland Dreier wrote:
> > So will each new NIC implement some parts of TCP stack in theirs drivers?
>
> I hope not. The driver we merged (amso1100) did it completely in FW,
> with a separate MAC and IP interface for the RDMA connections. I
> think we better
On Tue, 2006-12-05 at 08:13 +0300, Evgeniy Polyakov wrote:
> On Mon, Dec 04, 2006 at 10:20:51AM -0600, Steve Wise ([EMAIL PROTECTED])
> wrote:
> > > > This and a lot of other changes in this driver definitely says you
> > > > implement your own stack of protocols
On Mon, 2006-12-04 at 21:13 -0800, Roland Dreier wrote:
> > It is for iwarp/rdma from description.
>
> Yes, iWARP on top of 10G ethernet.
>
> > If it is 10ge, then why does it parse incomping packet headers and
> > implements initial tcp state machine?
>
> To establish connections to run
On Tue, 2006-12-05 at 08:07 +0300, Evgeniy Polyakov wrote:
> On Mon, Dec 04, 2006 at 07:45:52AM -0800, Roland Dreier ([EMAIL PROTECTED])
> wrote:
> > > This and a lot of other changes in this driver definitely says you
> > > implement your own stack of protocols on top of infiniband hardware.
>
On Tue, 2006-12-05 at 08:07 +0300, Evgeniy Polyakov wrote:
On Mon, Dec 04, 2006 at 07:45:52AM -0800, Roland Dreier ([EMAIL PROTECTED])
wrote:
This and a lot of other changes in this driver definitely says you
implement your own stack of protocols on top of infiniband hardware.
On Mon, 2006-12-04 at 21:13 -0800, Roland Dreier wrote:
It is for iwarp/rdma from description.
Yes, iWARP on top of 10G ethernet.
If it is 10ge, then why does it parse incomping packet headers and
implements initial tcp state machine?
To establish connections to run RDMA over, I
On Tue, 2006-12-05 at 08:13 +0300, Evgeniy Polyakov wrote:
On Mon, Dec 04, 2006 at 10:20:51AM -0600, Steve Wise ([EMAIL PROTECTED])
wrote:
This and a lot of other changes in this driver definitely says you
implement your own stack of protocols on top of infiniband hardware
On Mon, 2006-12-04 at 21:27 -0800, Roland Dreier wrote:
So will each new NIC implement some parts of TCP stack in theirs drivers?
I hope not. The driver we merged (amso1100) did it completely in FW,
with a separate MAC and IP interface for the RDMA connections. I
think we better
On Tue, 2006-12-05 at 18:19 +0300, Evgeniy Polyakov wrote:
On Tue, Dec 05, 2006 at 09:02:05AM -0600, Steve Wise ([EMAIL PROTECTED])
wrote:
This and a lot of other changes in this driver definitely says you
implement your own stack of protocols on top of infiniband hardware
On Tue, 2006-12-05 at 18:27 +0300, Evgeniy Polyakov wrote:
On Tue, Dec 05, 2006 at 09:14:36AM -0600, Steve Wise ([EMAIL PROTECTED])
wrote:
Chelsio doesn't implement TCP stack in the driver. Just like Ammasso,
it sends messages to the HW to setup connections. It differs from
Ammasso
On Tue, 2006-12-05 at 11:45 +0100, Brice Goglin wrote:
Steve Wise wrote:
There is no SW TCP stack in this driver. The HW supports RDMA over
TCP/IP/10GbE in HW and this is required for zero-copy RDMA over Ethernet
(aka iWARP). The device is a 10 GbE device, not Infiniband.
Then, I
On Tue, 2006-12-05 at 18:59 +0300, Evgeniy Polyakov wrote:
On Tue, Dec 05, 2006 at 09:39:58AM -0600, Steve Wise ([EMAIL PROTECTED])
wrote:
Phrases like MPA-aware TCP rises a lot of questions - briefly saying
that hardware (even if it is called ethernet driver) can create and work
On Tue, 2006-12-05 at 10:12 -0600, Steve Wise wrote:
On Tue, 2006-12-05 at 18:59 +0300, Evgeniy Polyakov wrote:
On Tue, Dec 05, 2006 at 09:39:58AM -0600, Steve Wise ([EMAIL PROTECTED])
wrote:
Phrases like MPA-aware TCP rises a lot of questions - briefly saying
that hardware (even
On Tue, 2006-12-05 at 10:02 -0600, Steve Wise wrote:
On Tue, 2006-12-05 at 11:45 +0100, Brice Goglin wrote:
Steve Wise wrote:
There is no SW TCP stack in this driver. The HW supports RDMA over
TCP/IP/10GbE in HW and this is required for zero-copy RDMA over Ethernet
(aka iWARP
On Tue, 2006-12-05 at 19:31 +0300, Evgeniy Polyakov wrote:
On Tue, Dec 05, 2006 at 10:12:42AM -0600, Steve Wise ([EMAIL PROTECTED])
wrote:
Ah. Data from an offloaded connection cannot leak into the main stack
nor vice-verse. We can take an active RDMA connection establishment
On Tue, 2006-12-05 at 20:26 +0300, Evgeniy Polyakov wrote:
On Tue, Dec 05, 2006 at 10:47:25AM -0600, Steve Wise ([EMAIL PROTECTED])
wrote:
And if there were a dataflow between addr/port a.b to addr/port c.d
already, it will either terminated?
Considering the following sequence
On Mon, 2006-12-04 at 08:45 -0800, Roland Dreier wrote:
> > Roland, I think at one time we were talking about changing the Core to
> > better handle this? Either with attributes/capabilities that the low
> > level driver can set, or by set these method ptrs to NULL and the core
> > should
On Sun, 2006-12-03 at 13:07 +0100, Arjan van de Ven wrote:
> On Sat, 2006-12-02 at 16:49 -0600, Steve Wise wrote:
>
> > +
> > +static struct ib_ah *iwch_ah_create(struct ib_pd *pd,
> > + struct ib_ah_attr *ah_attr)
> > +{
> >>
> >
> > I understood that Stephen expressed some doubts regarding the inclusion
> > of TOE enabled features.
> >
> > Was his point addressed ?
> >
> >
>
> My comments were about different hardware.
Just to clarify:
Stephen is working on the Chelsio T2 HW driver.
The drivers
On Mon, 2006-12-04 at 07:45 -0800, Roland Dreier wrote:
> > Could you convince network core developers that it is not own TCP
> > implementation which will mess with existing one?
>
> I'm not qualified to comment on this...
>
I don't understand your question?
> > This and a lot of other
On Mon, 2006-12-04 at 07:45 -0800, Roland Dreier wrote:
Could you convince network core developers that it is not own TCP
implementation which will mess with existing one?
I'm not qualified to comment on this...
I don't understand your question?
This and a lot of other changes in
I understood that Stephen expressed some doubts regarding the inclusion
of TOE enabled features.
Was his point addressed ?
My comments were about different hardware.
Just to clarify:
Stephen is working on the Chelsio T2 HW driver.
The drivers Divy and I are
On Sun, 2006-12-03 at 13:07 +0100, Arjan van de Ven wrote:
On Sat, 2006-12-02 at 16:49 -0600, Steve Wise wrote:
+
+static struct ib_ah *iwch_ah_create(struct ib_pd *pd,
+ struct ib_ah_attr *ah_attr)
+{
+ return ERR_PTR(-ENOSYS);
+}
-ENOSYS
On Mon, 2006-12-04 at 08:45 -0800, Roland Dreier wrote:
Roland, I think at one time we were talking about changing the Core to
better handle this? Either with attributes/capabilities that the low
level driver can set, or by set these method ptrs to NULL and the core
should handle it
Functions to manipulate CQs.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_cq.c | 231 +
1 files changed, 231 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cq.c
b/drivers/infiniband/hw
The RDMA Core interfaces with the T3 HW and ULLD providing a low level
RDMA interface.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/core/cxio_hal.c | 1302 +++
drivers/infiniband/hw/cxgb3/core/cxio_hal.h | 201
2 files c
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/Kconfig |1 +
drivers/infiniband/Makefile |1 +
drivers/infiniband/hw/cxgb3/Kconfig | 27 +++
drivers/infiniband/hw/cxgb3/Makefile| 12
d
Core functions to carve up adapter memory, stag, qp, and cq IDs.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/core/cxio_resource.c | 331 ++
drivers/infiniband/hw/cxgb3/core/cxio_resource.h | 70 +
2 files changed, 401 inse
Debug code to dump various data structs, some of which are in
adapter memory.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/core/cxio_dbg.c | 205 +++
1 files changed, 205 insertions(+), 0 deletions(-)
diff --git a/drivers/infi
Code to manipulate the QP.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_qp.c | 1007 +
1 files changed, 1007 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_qp.c
b/drivers/infiniband/hw
Code to handle async events coming from the T3 RDMA Core.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_ev.c | 228 +
1 files changed, 228 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_e
T3 WQE and CQE structures, defines, etc...
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/core/cxio_wr.h | 685
1 files changed, 685 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_wr.h
b/d
Functions to register memory regions.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_mem.c | 170
1 files changed, 170 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_mem.c
b/drivers/infi
Support provider-specific data in ib_uverbs_cmd_req_notify_cq().
The Chelsio iwarp provider library needs to pass information to the
kernel verb for re-arming the CQ.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/core/uverbs_cmd.c |9 +++--
d
Code to discover all the T3 devices and register them
with the T3 RDMA Core and the Linux RDMA Core.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch.c | 189
drivers/infiniband/hw/cxgb3/iwch.h
Version 2 changes:
- Make code sparse endian clean
- Use IDRs for mapping QP and CQ IDs to structure pointers instead of arrays
- Clean up confusing bitfields
- Use random32() instead of local random function
- Use krefs to track endpoint reference counts
- Misc nits
-
The following series
Provider methods to support the Linux RDMA verbs.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_provider.c | 1170 +++
drivers/infiniband/hw/cxgb3/iwch_provider.h | 362
drivers/infiniband/hw/cxgb3/iwch_user.h
Provider methods to support the Linux RDMA verbs.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_provider.c | 1170 +++
drivers/infiniband/hw/cxgb3/iwch_provider.h | 362
drivers/infiniband/hw/cxgb3/iwch_user.h | 68
Version 2 changes:
- Make code sparse endian clean
- Use IDRs for mapping QP and CQ IDs to structure pointers instead of arrays
- Clean up confusing bitfields
- Use random32() instead of local random function
- Use krefs to track endpoint reference counts
- Misc nits
-
The following series
Code to discover all the T3 devices and register them
with the T3 RDMA Core and the Linux RDMA Core.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch.c | 189
drivers/infiniband/hw/cxgb3/iwch.h | 175
Support provider-specific data in ib_uverbs_cmd_req_notify_cq().
The Chelsio iwarp provider library needs to pass information to the
kernel verb for re-arming the CQ.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/core/uverbs_cmd.c |9 +++--
drivers/infiniband
Functions to register memory regions.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_mem.c | 170
1 files changed, 170 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_mem.c
b/drivers/infiniband/hw
T3 WQE and CQE structures, defines, etc...
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/core/cxio_wr.h | 685
1 files changed, 685 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_wr.h
b/drivers
Code to handle async events coming from the T3 RDMA Core.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_ev.c | 228 +
1 files changed, 228 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_ev.c
b
Code to manipulate the QP.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_qp.c | 1007 +
1 files changed, 1007 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_qp.c
b/drivers/infiniband/hw/cxgb3
Debug code to dump various data structs, some of which are in
adapter memory.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/core/cxio_dbg.c | 205 +++
1 files changed, 205 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/Kconfig |1 +
drivers/infiniband/Makefile |1 +
drivers/infiniband/hw/cxgb3/Kconfig | 27 +++
drivers/infiniband/hw/cxgb3/Makefile| 12
drivers
Core functions to carve up adapter memory, stag, qp, and cq IDs.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/core/cxio_resource.c | 331 ++
drivers/infiniband/hw/cxgb3/core/cxio_resource.h | 70 +
2 files changed, 401 insertions(+), 0
The RDMA Core interfaces with the T3 HW and ULLD providing a low level
RDMA interface.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/core/cxio_hal.c | 1302 +++
drivers/infiniband/hw/cxgb3/core/cxio_hal.h | 201
2 files changed, 1503
Functions to manipulate CQs.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_cq.c | 231 +
1 files changed, 231 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cq.c
b/drivers/infiniband/hw/cxgb3
On Fri, 2006-11-17 at 10:19 -0800, Bryan O'Sullivan wrote:
> Steve Wise wrote:
> > T3 WQE and CQE structures, defines, etc...
>
> I notice that none of the fields in these structs seem to be
> endianness-annotated, but that there's a lot of cpu_to_be64 and so on
> bein
On Fri, 2006-11-17 at 10:07 -0800, Bryan O'Sullivan wrote:
> Steve Wise wrote:
>
> > +static void release_tid(struct t3cdev *tdev, u32 hwtid, struct sk_buff
> > *skb)
> > +{
> > + struct cpl_tid_release *req;
> > +
> > + skb = get_skb(skb,
On Fri, 2006-11-17 at 09:53 -0800, Bryan O'Sullivan wrote:
> Steve Wise wrote:
>
> > +static inline void *vzmalloc(int size)
> > +{
> > + void *p = vmalloc(size);
> > + memset(p, 0, size);
> > + return p;
> > +}
>
> This isn't checking the
On Fri, 2006-11-17 at 08:54 -0800, Roland Dreier wrote:
> > +static u32 next_random(u32 rand)
> > +{
> > + u32 y, ylast;
> > +
> > + y = rand;
> > + ylast = y;
> > + y = (y * 69069) & 0x;
> > + y = (y & 0x8000) + (ylast & 0x7fff);
> > + if ((y & 1))
> > +
On Thu, 2006-11-16 at 20:45 -0800, Roland Dreier wrote:
> > +struct t3_send_wr {
> > + struct fw_riwrh wrh;/* 0 */
> > + union t3_wrid wrid; /* 1 */
> > +
> > + enum t3_rdma_opcode rdmaop:8;
> > + u32 reserved:24;/* 2 */
>
> Does this do the right thing wrt endianness?
On Thu, 2006-11-16 at 20:45 -0800, Roland Dreier wrote:
+struct t3_send_wr {
+ struct fw_riwrh wrh;/* 0 */
+ union t3_wrid wrid; /* 1 */
+
+ enum t3_rdma_opcode rdmaop:8;
+ u32 reserved:24;/* 2 */
Does this do the right thing wrt endianness? I'd be more
On Fri, 2006-11-17 at 08:54 -0800, Roland Dreier wrote:
+static u32 next_random(u32 rand)
+{
+ u32 y, ylast;
+
+ y = rand;
+ ylast = y;
+ y = (y * 69069) 0x;
+ y = (y 0x8000) + (ylast 0x7fff);
+ if ((y 1))
+ y = ylast ^ (y 1)
On Fri, 2006-11-17 at 09:53 -0800, Bryan O'Sullivan wrote:
Steve Wise wrote:
+static inline void *vzmalloc(int size)
+{
+ void *p = vmalloc(size);
+ memset(p, 0, size);
+ return p;
+}
This isn't checking the return value from vmalloc.
Oops...
Also, we could do
On Fri, 2006-11-17 at 10:07 -0800, Bryan O'Sullivan wrote:
Steve Wise wrote:
+static void release_tid(struct t3cdev *tdev, u32 hwtid, struct sk_buff
*skb)
+{
+ struct cpl_tid_release *req;
+
+ skb = get_skb(skb, sizeof *req, GFP_KERNEL);
+ if (!skb) {
+ return
On Fri, 2006-11-17 at 10:19 -0800, Bryan O'Sullivan wrote:
Steve Wise wrote:
T3 WQE and CQE structures, defines, etc...
I notice that none of the fields in these structs seem to be
endianness-annotated, but that there's a lot of cpu_to_be64 and so on
being used to frob values into them
Seems reasonable to me...
Steve.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Roland Dreier
> Sent: Thursday, August 04, 2005 12:32 PM
> To: openib-general@openib.org; linux-kernel@vger.kernel.org
> Subject: [openib-general] [RFC] Move
Seems reasonable to me...
Steve.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Roland Dreier
Sent: Thursday, August 04, 2005 12:32 PM
To: openib-general@openib.org; linux-kernel@vger.kernel.org
Subject: [openib-general] [RFC] Move InfiniBand
601 - 668 of 668 matches
Mail list logo
