Subject: RE: [Tsvwg] Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues(Resend)

From: [email-masked]
Date: Fri, 26 Mar 2004 16:28:52 -0700

I'll take the liberty of responding to your rhetorical question. I don't think the question can be answered outside the context of protocols like RDMA and iSCSI. A good part of the performance problem for 10 Gig links is the data copies required. Protocols like iSCSI and RDMA can allow the NIC to place the data into applications buffers. This is similar to the function of some Fibre Channel interfaces that allow it higher performance. This is a large part of the benefit gained from implementing a TOE. Protocols like RDMA and iSCSI require TCP (or an alternative transport layer) to be implemented other them which means you need a TOE. 

If you aren't doing placement on the NIC, it isn't clear that there is enough benefit from implementing a TOE. Because we want to do placement, we need a TOE.

Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Rick Jones
Sent: Thursday, March 11, 2004 10:49 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Tsvwg] Re: [tcpm] Re: [e2e] Are you interested in TOEs and
related issues(Resend)

> Yes, that was one of the first thoughts that came to my mind when I
> started looking at this space. Its not just security issues but bugs and
> new features. TCP despite being mature still sees couple of RFC or tweaks
> a year that needs to be rolled out to existing systems. Apparantly the
> TOE vendors had thought about that. The firmware running the protocol code
> actually lives on the host and is delivered via exisiting delivery
> mechanism (packages in Solaris which can be upgraded). When machine boots
> and interface is configured, the protocol firmware is sucked in. So
> delivering fix or new revs in pretty similar to exisiting mechanisms.
> Also, the source code is still 'C' based so people like me can still
> work with it (just need to use some magic in the end to create the
> firmware instead of complier). Some vendors we talked to have promised
> that they can pretty much suck in the same code that runs on the host
> into the card (as long as we can clean some complier specific directives
> etc). Although I must admit that this aspect (common source files) of TOE
> has not been investigated by us at all so far.

That seems like a path out when the TOE is based on an embedded CPU, but doesn't
seem like it would work for those TOEs that are ASICs.

And a mostly rhetorical question - strictly in the context of TCP comms and not
RDMA and the like - if one can code tightly enough for an embedded CPU a TCP/IP
stack including comms with the host across the I/O bus with enough performance
to be reasonable for a given link, can't one presumeably make the host's TCP/IP
stack similarly efficient?  If nothing else that seems to be alluded to by the
last sentence in the quoted paragraph.

rick jones
-- 
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm