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: [email protected] > 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 > [email protected] > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
