mirror of https://lore.kernel.org/lkml/
 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 20:32:22 +0300	[thread overview]
Message-ID: <20061205173221.GB24149@2ka.mipt.ru> (raw)
In-Reply-To: <20061205172649.GA20229@2ka.mipt.ru>

On Tue, Dec 05, 2006 at 08:26:49PM +0300, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote:
> On Tue, Dec 05, 2006 at 10:47:25AM -0600, Steve Wise (swise@opengridcomputing.com) 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
> > > example CPL_PASS_ACCEPT_REQ->pass_accept_req() - it just parses incoming
> > > skb and sets port/addr/route and other fields to be used as a base for rdma
> > > connection. What if it just a usual network packet from kernelspace or 
> > > userspace with the same payload as should be sent by remote rdma system?
> > > 
> > 
> > That skb isn't a network packet.  Its a CPL_PASS_ACCEPT_REQ message (see
> > struct cpl_pass_accept_req in the Ethernet driver t3_cpl.h).  If the
> > RDMA driver hadn't registered to listen on that addr/port, it would
> > never get this skb.  Once a connection is established, the MPA messages
> > (and any TCP payload data) is delivered to the RDMA driver in the form
> > of skb's containing struct cpl_rx_data.  So these skbs aren't just TCP
> > packets at all.  They either control messages or TCP payload. Either way
> > they are encapsulated in CPL message structures.
> > 
> > Does this make sense?
>  
> 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 negotiation protocol.
> 
> If it is correct, it means that any packet in the network can be
> potentially 'stolen' by rdma hardware, although it was part of the usual
> dataflow. 
> If that packets are not from ethernet network, but from different
> low-level, then there is a question (besides why this driver is called
> ethernet if it manages different hardware) about how connection over
> that different media is being setup and since packets contain perfectly
> valid IP addresses and ports.

It looks like I've answered myself - it is _not_ ethernet driver, but
rdma one, and although it gets all data through skbs from ethernet
driver, the latter gets them not from ethernet network.
And thus addresses and ports and all other information can not be mixed
between the two.

-- 
	Evgeniy Polyakov

  reply	other threads:[~2006-12-05 17:32 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
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 [this message]
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=20061205173221.GB24149@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

all inboxes | Powered by JetHome®