netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Steve Wise <swise@opengridcomputing.com>
Cc: Roland Dreier <rdreier@cisco.com>,
	netdev@vger.kernel.org, openib-general@openib.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH  v2 04/13] Connection Manager
Date: Tue, 5 Dec 2006 18:59:32 +0300	[thread overview]
Message-ID: <20061205155932.GA32380@2ka.mipt.ru> (raw)
In-Reply-To: <1165333198.16087.53.camel@stevo-desktop>

On Tue, Dec 05, 2006 at 09:39:58AM -0600, Steve Wise (swise@opengridcomputing.com) 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 seen 
> > in driver. Likely such flows will not be seen by upper layers like OS 
> > network stack according to hardware descriptions.
> > 
> > Is it correct?
> > 
> 
> I don't quite get your point about the driver aspect of this?
> 
> The HW manages the iWARP connection including data flow.  It adheres to
> the MPA, RDDP, and RDMAP protocol specification IDs from the IETF.  The
> HW manages how data gets pushed out in the RDMA stream.   The RDMA
> Driver just requests a TCP connection and does the MPA exchange.  Then
> tells the hardware to move the connection into RDMA mode.  From that
> point on, the driver simply suffles IO work requests from the consumer
> application to the hardware and handles asynchronous events while the
> connection is up and running.

My main concern about this is the fact, that protocol handling is
splitted into SF and HW parts, and actually until negotiation is
completed those parts are completely unrelated to each other, so
requested TCP connection can leak into main stack and main stack can
send some packets which can be considered as MPA negotiation.

> Steve.

-- 
	Evgeniy Polyakov

  reply	other threads:[~2006-12-05 16:04 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-02 22:49 [PATCH v2 00/13] 2.6.20 Chelsio T3 RDMA Driver Steve Wise
2006-12-02 22:49 ` [PATCH v2 01/13] Linux RDMA Core Changes Steve Wise
2006-12-02 22:49 ` [PATCH v2 02/13] Device Discovery and ULLD Linkage Steve Wise
2006-12-03 16:03   ` Jan Engelhardt
2006-12-02 22:49 ` [PATCH v2 03/13] Provider Methods and Data Structures Steve Wise
2006-12-03 12:07   ` Arjan van de Ven
2006-12-04 16:28     ` Steve Wise
2006-12-04 16:45       ` Roland Dreier
2006-12-04 16:50         ` Steve Wise
2006-12-02 22:49 ` [PATCH v2 04/13] Connection Manager Steve Wise
2006-12-04 11:08   ` Evgeniy Polyakov
2006-12-04 15:45     ` Roland Dreier
2006-12-04 16:20       ` Steve Wise
2006-12-05  5:13         ` Evgeniy Polyakov
2006-12-05 15:07           ` Steve Wise
2006-12-05 10:45         ` Brice Goglin
2006-12-05 16:02           ` Steve Wise
2006-12-05 16:27             ` [openib-general] " Steve Wise
2006-12-05 17:14           ` Roland Dreier
2006-12-05  5:07       ` Evgeniy Polyakov
2006-12-05  5:13         ` Roland Dreier
2006-12-05  5:16           ` Evgeniy Polyakov
2006-12-05  5:27             ` Roland Dreier
2006-12-05 15:14               ` Steve Wise
2006-12-05 15:27                 ` Evgeniy Polyakov
2006-12-05 15:46                   ` Steve Wise
2006-12-05 15:03           ` Steve Wise
2006-12-05 15:02         ` Steve Wise
2006-12-05 15:19           ` Evgeniy Polyakov
2006-12-05 15:39             ` Steve Wise
2006-12-05 15:59               ` Evgeniy Polyakov [this message]
2006-12-05 16:12                 ` Steve Wise
2006-12-05 16:17                   ` [openib-general] " Steve Wise
2006-12-05 16:31                   ` Evgeniy Polyakov
2006-12-05 16:47                     ` Steve Wise
2006-12-05 17:26                       ` Evgeniy Polyakov
2006-12-05 17:32                         ` Evgeniy Polyakov
2006-12-05 17:51                         ` Steve Wise
2006-12-05 18:09                           ` Evgeniy Polyakov
2006-12-06  1:27                             ` [openib-general] " Michael Krause
2006-12-02 22:50 ` [PATCH v2 05/13] Queue Pairs Steve Wise
2006-12-02 22:50 ` [PATCH v2 06/13] Completion Queues Steve Wise
2006-12-02 22:50 ` [PATCH v2 07/13] Async Event Handler Steve Wise
2006-12-02 22:50 ` [PATCH v2 08/13] Memory Registration Steve Wise
2006-12-02 22:50 ` [PATCH v2 09/13] Core WQE/CQE Types Steve Wise
2006-12-02 22:50 ` [PATCH v2 10/13] Core HAL Steve Wise
2006-12-02 22:51 ` [PATCH v2 11/13] Core Resource Allocation Steve Wise
2006-12-02 22:51 ` [PATCH v2 12/13] Core Debug functions Steve Wise
2006-12-02 22:51 ` [PATCH v2 13/13] Kconfig/Makefile Steve Wise
2006-12-02 23:13 ` [PATCH v2 00/13] 2.6.20 Chelsio T3 RDMA Driver Francois Romieu
2006-12-03  0:24   ` Stephen Hemminger
2006-12-04 16:24     ` Steve Wise

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061205155932.GA32380@2ka.mipt.ru \
    --to=johnpol@2ka.mipt.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=openib-general@openib.org \
    --cc=rdreier@cisco.com \
    --cc=swise@opengridcomputing.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).