If you require more details on how this all works - it was fully explored
in the IETF RDDP workgroup - may I suggest a reading of the RDMA Security
Considerations draft which goes through many of the issues on how one
relates to a host stack. This complements the MPA spec and supports much
On Tue, Dec 05, 2006 at 11:51:40AM -0600, Steve Wise ([EMAIL PROTECTED]) wrote:
> > Almost - except the case about where those skbs are coming from?
> > It looks like they are obtained from network, since it is ethernet
> > driver, and if they match some set of rules, they are considered as valid
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
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 Tue, Dec 05, 2006 at 08:26:49PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
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?
> > >
> >
> Is there really no way to only keep the actual hw infiniband there, move
> iwarp/rdma drivers in drivers/net/something/ and the core stuff in
> net/something/ ?
It's definitely possible, but rearranging the source tree hasn't been
a high priority (for me at least).
- R.
-
To unsubscribe
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 as
> >
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 as
> an example if you want: Once the message is sent to the HW to "setup
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
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
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
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.
>
>
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
> > with own TCP flows potentially modified in the way it likes
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
> >
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
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 in at least 2 ways:
>
> 1) Ammasso does the MPA negotiations in
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.
> > >
> > > ...but I do know this driver is for 10-gig ethernet
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 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
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.
>
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 wonder why the driver goes in drivers/infiniband/ :)
Is there
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 wonder why the driver goes in drivers/infiniband/ :)
Is there
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, 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.
...but I do know this driver is for 10-gig ethernet HW.
It
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 in at least 2 ways:
1) Ammasso does the MPA negotiations in FW/HW.
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 in
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
with own TCP flows potentially modified in the way it likes which 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 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
with
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 if
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). The
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 as
an example if you want: Once the message is sent to the HW to setup a
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 as
an
Is there really no way to only keep the actual hw infiniband there, move
iwarp/rdma drivers in drivers/net/something/ and the core stuff in
net/something/ ?
It's definitely possible, but rearranging the source tree hasn't been
a high priority (for me at least).
- R.
-
To unsubscribe from
On Tue, Dec 05, 2006 at 08:26:49PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
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
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:
handlers-t3c_handlers-sched()-work_queue-work_handlers()-for
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 Tue, Dec 05, 2006 at 11:51:40AM -0600, Steve Wise ([EMAIL PROTECTED]) wrote:
Almost - except the case about where those skbs are coming from?
It looks like they are obtained from network, since it is ethernet
driver, and if they match some set of rules, they are considered as valid
MPA
If you require more details on how this all works - it was fully explored
in the IETF RDDP workgroup - may I suggest a reading of the RDMA Security
Considerations draft which goes through many of the issues on how one
relates to a host stack. This complements the MPA spec and supports much
> 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 understand the Chelsio driver pretty well and think it
over
On Mon, Dec 04, 2006 at 09:13:59PM -0800, Roland Dreier ([EMAIL PROTECTED])
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
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.
> >
> > ...but I do know this driver is for 10-gig ethernet HW.
> >
> 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 guess. iWARP is RDMA
over TCP.
- R.
-
To unsubscribe from
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.
>
> ...but I do know this driver is for 10-gig ethernet HW.
It is
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
> 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...
> This and a lot of other changes in this driver definitely says you
> implement your own stack of protocols on top of infiniband
On Sat, Dec 02, 2006 at 04:49:58PM -0600, Steve Wise ([EMAIL PROTECTED]) wrote:
> +static int send_halfclose(struct iwch_ep *ep, gfp_t gfp)
> +{
> + struct cpl_close_con_req *req;
> + struct sk_buff *skb;
> +
> + PDBG("%s ep %p\n", __FUNCTION__, ep);
> + skb = get_skb(NULL,
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.
...but I do know this driver is for 10-gig ethernet HW.
It is for
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 guess. iWARP is RDMA
over TCP.
- R.
-
To unsubscribe from this
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.
...but I do know this driver is for 10-gig ethernet HW.
There
On Mon, Dec 04, 2006 at 09:13:59PM -0800, Roland Dreier ([EMAIL PROTECTED])
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
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 understand the Chelsio driver pretty well and think it
over carefully
On Sat, Dec 02, 2006 at 04:49:58PM -0600, Steve Wise ([EMAIL PROTECTED]) wrote:
+static int send_halfclose(struct iwch_ep *ep, gfp_t gfp)
+{
+ struct cpl_close_con_req *req;
+ struct sk_buff *skb;
+
+ PDBG(%s ep %p\n, __FUNCTION__, ep);
+ skb = get_skb(NULL, sizeof(*req),
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...
This and a lot of other changes in this driver definitely says you
implement your own stack of protocols on top of infiniband
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
60 matches
Mail list logo
