[openib-general] [PATCH][iWARP] Added provider CM verbs andquery provider methods

[Asgeir Eiriksson]

Caitlin

For the openib folk: keep in mind in the following that iWARP runs on
top of TCP, and the TCP is offloaded so TOE enters the iWARP picture.

I second the requirement that an iWARP RNIC needs to integrate with host
configuration, reporting, and security mechanisms, and this is the
approach taken in the Chelsio TOE patches that we have submitted.
Standard tools such as netstat, ifconfig, work with the Chelsio TOE
today, and there's nothing to prevent netfilter to work, etc. For those
that are interested there is more information available at
https://service.chelsio.com/open_toe and in particular in
Chelsio_toe_arch.pdf

I have to disagree that this means that the connection is necessarily
setup by the host stack. The Chelsio 10GE NIC/TOE/iSCSI/iWARP products
setup the connection on the card, but the setup includes an "ASK host"
phase initiated by the card where the host can filter the connect
request, and modify any of the initial TCP values chosen by the card,
etc., and then respond with accept or reject.

In general the iWARP connection manager needs to accommodate three
possible TCP connection setup models in use today in iWARP devices: a)
what you seem to be advocating, i.e. TCP connection setup on the host
stack, b) what I brought up, i.e. offloaded TCP connection setup with an
ASK phase, and c) what was brought up previously and that's full TCP
connection setup offload.

'Asgeir


>From: "Caitlin Bestler" <caitlinb at broadcom.com>
>To: "Roland Dreier" <rolandd at cisco.com>,"Tom Tucker" <tom at ammasso.com>
>CC: openib-general at openib.org
>Subject: RE: [openib-general] [PATCH][iWARP] Added provider CM verbs
andquery provider methods
>Date: Thu, 25 Aug 2005 16:46:38 -0700
>
>Device vendors would jump at the opportunity to have a stable
>interface with the host stack. Things like routing, protection
>from denial of service attacks, rules for logging and filtering
>connection requests and more all *should* be handled by the host
>stack.
>
>That's where the end user wants to control them, it's where
>the security code can be kept most current and most robust.
>It is also largely on packets that do not require offload
>optimization.
>
>But we also need time to ensure that the community understands
>this as giving the host stack control of an offload connection
>during connection establishment -- rather than as the offload
>device "stealing" the connection from the host stack.
>
>Moving the entire TCP connection logic to the offload device
>not only increases the work that the offload device must do,
>it reduces the auditability of the system and the user's control
>over their network activity.
>
>So the intent is not to evade the stack, rather it is to allow
>time for proper integration with host stack control. The tradeoffs
>are complex, and neither side fully understands the other's
>issues yet. We need to work together to determine how to provide
>the acceleration that our users want without sacrificing the OS
>provided security that they assume will not be sacrificed.
>
>
> > -----Original Message-----
> > From: openib-general-bounces at openib.org
> > [mailto:openib-general-bounces at openib.org] On Behalf Of Roland
Dreier
> > Sent: Thursday, August 25, 2005 4:21 PM
> > To: Tom Tucker
> > Cc: openib-general at openib.org
> > Subject: Re: [openib-general] [PATCH][iWARP] Added provider
> > CM verbs and query provider methods
> >
> >     Tom> RNIC Verbs imply that the modify qp verb takes a handle to
a
> >     Tom> connection -- presumably a socket. This CAN'T be done on
> >     Tom> Linux in any fashion that is acceptable to the netdev
> >     Tom> crowd. SOOO we modeled this after DAPL.  Trust me, I would
> >     Tom> LOVE to be able to establish the connection using bind,
> >     Tom> listen, etc..., query the Linux connection state and then
> >     Tom> pass this down to the qp modify verb...but I can't.
> >
> > Let's not be too quick to say that this is impossible.  I
> > think we should work with the Linux networking community and
> > come up with the right answer, and not accept a bad solution
> > just because it lets us go around the networking people.
> >
> > Has there been any real discussion of this on netdev?
> >
> >  - R.