Messages in this thread | | | Subject | Re: zero-copy TCP | From | Jes Sorensen <> | Date | 03 Sep 2000 16:09:42 +0200 |
| |
>>>>> "Ingo" == Ingo Molnar <mingo@elte.hu> writes:
Ingo> On 2 Sep 2000, Jes Sorensen wrote:
>> You can't DMA directly from a file cache page unless you have a >> network card that does scatter/gather DMA and surprise surprise, >> 80-90% of the cards on the market don't support this. [...]
Ingo> exactly. The TUX patch solves this by copying 'multi-fragment Ingo> skbs' into a temporary single-fragment skb, if the card doesnt Ingo> support scatter-gather, 64-bit DMA. This way the copying is Ingo> delayed as much as possible, to the point where we queue the Ingo> packet to the network device.
Ok, I need to go look at your code. Sounds like you started doing a lot of the stuff we discussed during OLS.
>> Besides that you need to do copy-on-write if you want to be able to >> do zero copy on write() from user space [...]
Ingo> i agree that this is hard - i'm not sure wether we want to go Ingo> the pain to enable anonymous-buffer write()s do zero-copy. My Ingo> plan is to enable sendfile() first - it should cover all the Ingo> important high-performance server cases. The point is that a Ingo> write() is only used if some sort of dynamic data is generated Ingo> on the fly. If data is generated once and sent once then there Ingo> is no much win in zero-copy. If data is generated once and Ingo> reused multiple times afterwards then it should rather be Ingo> written into a temporary file and then it can be sent out via Ingo> sendfile().
At CERN we had a bunch of applications where this would be a win, data aquisition servers taking data in from on some custom hardware and sending out data over the wire on another card. You never really want to touch data in memory with the CPU but because of the lack of write() zero copy you end up having to do so.
Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |