Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*TCP\s+IP\s+Offloading\s+Interface\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*TCP\s+IP\s+Offloading\s+Interface\s*$/: 48 ]

Total 48 documents matching your query.

21. Re: TCP IP Offloading Interface (score: 1): Author: xxxx; Date: 16 Jul 2003 01:02:33 -0400; A friend of mine mentioned that the MS support may all be a big scam. It makes it easy to kill TOE if they get involved ;-> Yes, there will be some MIS managers who will buy the M$ B$. What about inf; /archives/netdev/2003-07/msg00350.html (10,351 bytes)
22. Re: TCP IP Offloading Interface (score: 1): Author: m@xxxxxxxxxxxxxxxxx>; Date: Tue, 15 Jul 2003 19:37:58 -0700; The following reference should be useful for those following along at home and wondering what the hell this hardware flow cache scheme is: http://www.ussg.iu.edu/hypermail/linux/kernel/0306.2/0429.ht; /archives/netdev/2003-07/msg00355.html (10,190 bytes)
23. Re: TCP IP Offloading Interface (score: 1): Author: x>; Date: Tue, 15 Jul 2003 19:46:49 -0700; Do you have a reference to an existing card that implements a header parsing engine like this (and has obtainable docs)? Regards, -- Matt Porter mporter@xxxxxxxxxxxxxxxxxxx; /archives/netdev/2003-07/msg00356.html (11,105 bytes)
24. Re: TCP IP Offloading Interface (score: 1): Author: unda@xxxxxxxxxxx>; Date: Tue, 15 Jul 2003 20:36:47 +0100; The above ignores the economics of the matter. The money in optical carriers is currently in datacomm, not telecomm. You'll see the highspeed optics in your server room before you see it at your telc; /archives/netdev/2003-07/msg00357.html (10,734 bytes)
25. Re: TCP IP Offloading Interface (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Sun, 13 Jul 2003 00:48:18 -0700; TOE is evil, read this: http://www.usenix.org/events/hotos03/tech/full_papers/mogul/mogul.pdf TOE is exactly suboptimal for the very things performance matters, high connection rates. Your return is; /archives/netdev/2003-07/msg00953.html (9,600 bytes)
26. Re: TCP IP Offloading Interface (score: 1): Author: Roland Dreier <roland@xxxxxxxxxxx>; Date: 13 Jul 2003 09:22:32 -0700; David> http://www.usenix.org/events/hotos03/tech/full_papers/mogul/mogul.pdf David> TOE is exactly suboptimal for the very things performance David> matters, high connection rates. David> Your retur; /archives/netdev/2003-07/msg00957.html (10,805 bytes)
27. Re: TCP IP Offloading Interface (score: 1): Author: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>; Date: 13 Jul 2003 17:31:35 +0100; Take a look at who holds the official internet land speed record. Its not a TOE using system. Page remapping is adequate for send of data when the MSS is below the VM page size since you don't have t; /archives/netdev/2003-07/msg00958.html (11,092 bytes)
28. Re: TCP IP Offloading Interface (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxx>; Date: Sun, 13 Jul 2003 12:49:59 -0400; I had forgotten all about splice. For interested readers, here is the link: http://www.bitmover.com/lm/papers/splice.ps Jeff; /archives/netdev/2003-07/msg00959.html (10,177 bytes)
29. Re: TCP IP Offloading Interface (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Sun, 13 Jul 2003 16:02:00 -0700; I didn't say I agree with all of Moguls ideas, just his anti-TOE arguments. For example, I also think RDMA sucks too yet he thinks it's a good iea. On send this doesn't matter, on receive you use my; /archives/netdev/2003-07/msg00960.html (10,680 bytes)
30. Re: TCP IP Offloading Interface (score: 1): Author: Larry McVoy <lm@xxxxxxxxxxxx>; Date: Sun, 13 Jul 2003 16:35:03 -0700; Please don't. I think page flipping was a bad idea. I think you'd be better off to try and make the data flow up the stack in small enough windows that it all sits in the cache. One thing SGI taught; /archives/netdev/2003-07/msg00961.html (11,225 bytes)
31. Re: TCP IP Offloading Interface (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Sun, 13 Jul 2003 16:40:03 -0700; At 10GB/sec nothing fits in the cache :-) The whole point is to not touch any of this data. The idea is to push the pages directly into the page cache of the filesystem. I'm not talking about doing t; /archives/netdev/2003-07/msg00962.html (11,171 bytes)
32. Re: TCP IP Offloading Interface (score: 1): Author: Larry McVoy <lm@xxxxxxxxxxxx>; Date: Sun, 13 Jul 2003 16:54:24 -0700; It doesn't work. Measure the cost of the VM operations before you go down this path. Just set up a system call that swaps a page with a kernel allocated buffer and then see how many of those you can; /archives/netdev/2003-07/msg00963.html (11,866 bytes)
33. Re: TCP IP Offloading Interface (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Sun, 13 Jul 2003 16:53:23 -0700; I really don't see why receive is so much of a big deal compared to send, and we do a send side version of this stuff already with zero problems. The NFS code is already basically ready to handle a f; /archives/netdev/2003-07/msg00964.html (11,501 bytes)
34. Re: TCP IP Offloading Interface (score: 1): Author: Larry McVoy <lm@xxxxxxxxxxxx>; Date: Sun, 13 Jul 2003 17:22:00 -0700; Hey, maybe it isn't, but could you please quantify the cost of the VM operations? How hard is that? -- -- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm; /archives/netdev/2003-07/msg00965.html (12,474 bytes)
35. Re: TCP IP Offloading Interface (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Sun, 13 Jul 2003 17:24:14 -0700; Ok. So the page is in a non-uptodate state, NFS would have it locked, and anyone else trying to get at it would sleep. This page we have currently is "dummy" in that it is only a place holder in case; /archives/netdev/2003-07/msg00966.html (11,934 bytes)
36. Re: TCP IP Offloading Interface (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Sun, 13 Jul 2003 17:28:36 -0700; The bad assumption here is that this belongs in the OS. Let me ask you this, how many modern scsi drivers have to speak every piece of the SCSI bus protocol. Or fibre channel? All of it is done on th; /archives/netdev/2003-07/msg00967.html (11,230 bytes)
37. Re: TCP IP Offloading Interface (score: 1): Author: Valdis.Kletnieks@xxxxxx; Date: Sun, 13 Jul 2003 20:46:38 -0400; Well.... there's optimizations you can do on the send side.. For example, in this case, you know a priori what the IP header will look like, so you can use tricks like scatter-gather to send the head; /archives/netdev/2003-07/msg00968.html (12,422 bytes)
38. Re: TCP IP Offloading Interface (score: 1): Author: Larry McVoy <lm@xxxxxxxxxxxx>; Date: Sun, 13 Jul 2003 17:48:09 -0700; In theory, practice and theory are the same... I think the point I'm trying to make is that the VM stuff costs something and it shouldn't be that hard to dummy up a system call to measure it. It was; /archives/netdev/2003-07/msg00969.html (13,809 bytes)
39. Re: TCP IP Offloading Interface (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Sun, 13 Jul 2003 17:42:42 -0700; I consider the send side complete covered already. We don't touch any of the data portion, we only put together the headers. There are cards, both existing and in development, that have very simple h; /archives/netdev/2003-07/msg00970.html (12,070 bytes)
40. Re: TCP IP Offloading Interface (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxx>; Date: Sun, 13 Jul 2003 12:58:01 -0400; As an aside, I really like sendfile's semantics except for * People occasionally want to add a receivefile(2). I disagree... sendfile(2) interface should be really be considered a universal "fdcopy"; /archives/netdev/2003-07/msg00971.html (10,790 bytes)

Current List: 21 - 40
Page: [1] [2] [3]