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" <[EMAIL PROTECTED]> >To: "Roland Dreier" <[EMAIL PROTECTED]>,"Tom Tucker" <[EMAIL PROTECTED]> >CC: openib-general@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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Roland Dreier > > Sent: Thursday, August 25, 2005 4:21 PM > > To: Tom Tucker > > Cc: openib-general@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. _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general