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.

1. Re: TCP IP Offloading Interface (score: 1): Author: is@xxxxxxxxxxxxxxxx>; 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/msg00264.html (9,447 bytes)
2. Re: TCP IP Offloading Interface (score: 1): Author: r" <davem@xxxxxxxxxx>; 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/msg00268.html (10,647 bytes)
3. Re: TCP IP Offloading Interface (score: 1): Author: <pekkas@xxxxxxxxxx>; 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/msg00269.html (10,912 bytes)
4. Re: TCP IP Offloading Interface (score: 1): Author: " <davem@xxxxxxxxxx>; Date: Sun, 13 Jul 2003 12:49:59 -0400; Alan Cox wrote: Finally if you are streaming objects by non mapped references (eg sendfile or see LM's paper from long ago on splice()) then the problem goes away. I had forgotten all about splice. F; /archives/netdev/2003-07/msg00270.html (10,103 bytes)
5. Re: TCP IP Offloading Interface (score: 1): Author: ellwig <hch@xxxxxx>; 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/msg00271.html (10,515 bytes)
6. Re: TCP IP Offloading Interface (score: 1): Author: dfire@xxxxxxxxxxx>; 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/msg00272.html (11,008 bytes)
7. Re: TCP IP Offloading Interface (score: 1): Author: a <pekkas@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/msg00273.html (10,946 bytes)
8. Re: TCP IP Offloading Interface (score: 1): Author: roland@xxxxxxxxxxx>; 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/msg00274.html (11,582 bytes)
9. Re: TCP IP Offloading Interface (score: 1): Author: alan@xxxxxxxxxxxxxxxxxxx>; 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/msg00275.html (11,209 bytes)
10. Re: TCP IP Offloading Interface (score: 1): Author: <jgarzik@xxxxxxxxx>; 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/msg00276.html (12,123 bytes)
11. Re: TCP IP Offloading Interface (score: 1): Author: 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/msg00277.html (11,575 bytes)
12. Re: TCP IP Offloading Interface (score: 1): Author: oy <lm@xxxxxxxxxxxx>; 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/msg00278.html (10,965 bytes)
13. Re: TCP IP Offloading Interface (score: 1): Author: " <davem@xxxxxxxxxx>; 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/msg00279.html (12,087 bytes)
14. Re: TCP IP Offloading Interface (score: 1): Author: ry 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/msg00280.html (13,391 bytes)
15. Re: TCP IP Offloading Interface (score: 1): Author: vid 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/msg00281.html (11,701 bytes)
16. Re: TCP IP Offloading Interface (score: 1): Author: ry McVoy <lm@xxxxxxxxxxxx>; Date: Sun, 13 Jul 2003 12:58:01 -0400; Alan Cox wrote: Finally if you are streaming objects by non mapped references (eg sendfile or see LM's paper from long ago on splice()) then the problem goes away. As an aside, I really like sendfile; /archives/netdev/2003-07/msg00282.html (10,592 bytes)
17. RE: TCP IP Offloading Interface (score: 1): Author: <scott.feldman@xxxxxxxxx>; Date: Mon, 14 Jul 2003 22:42:55 -0700; TCP offloading does not necessarily need to be the goal but a MUST if one wants to build a performance-scalable architecture. This vision is in fact introduced by Mogul in his paper. He writes: "The; /archives/netdev/2003-07/msg00311.html (16,182 bytes)
18. Re: TCP IP Offloading Interface (score: 1): Author: id Mosberger <davidm@xxxxxxxxxxxxxxxxx>; Date: Mon, 14 Jul 2003 22:51:33 -0700; [ Please fix Outlook Express or whatever lame email client you use to put newlines into the emails that you compose. These excessive long lines make your emails nearly impossible to read ] I totally; /archives/netdev/2003-07/msg00313.html (11,961 bytes)
19. Re: TCP IP Offloading Interface (score: 1): Author: xx>; Date: Tue, 15 Jul 2003 09:28:10 -0700; Ok I've taken a look at your scheme and I have a few questions. From: "David S. Miller" <davem@xxxxxxxxxx> You also ignore the points others have made that the systems HAVE SCALED to evolving network; /archives/netdev/2003-07/msg00322.html (11,073 bytes)
20. RE: TCP IP Offloading Interface (score: 1): Author: xx>; Date: Tue, 15 Jul 2003 15:01:11 -0400 (EDT); Moore's law is borne out in practice; most optical tansmission developments are theory. 3 years ago the fastest circuit you could readily buy from a carrier (QWest, 360, Williams, etc) was OC192. Tod; /archives/netdev/2003-07/msg00333.html (10,217 bytes)

Current List: 1 - 20
Page: [1] [2] [3]