| To: | "David S. Miller" <davem@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1 |
| From: | Trond Myklebust <trond.myklebust@xxxxxxxxxx> |
| Date: | Tue, 9 Jan 2001 16:27:49 +0100 (CET) |
| Cc: | linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <200101091342.FAA02414@xxxxxxxxxxxxxxx> |
| References: | <200101080124.RAA08134@xxxxxxxxxxxxxxx> <shs4rz8vnmf.fsf@xxxxxxxxxxxxxx> <200101091342.FAA02414@xxxxxxxxxxxxxxx> |
| Reply-to: | trond.myklebust@xxxxxxxxxx |
| Sender: | owner-netdev@xxxxxxxxxxx |
>>>>> David S Miller <davem@xxxxxxxxxx> writes:
> I would have thought one of the main interests of doing
> something like this would be to allow us to speed up large
> writes to the socket for ncpfs/knfsd/nfs/smbfs/...
> This is what TCP_CORK/MSG_MORE et al. are all for, things get
> coalesced perfectly. Sending in a vector of pages seems nice,
> but none of the page cache infrastructure works like this, all
> of the core routines work on a page at a time. It actually
> simplifies a lot.
> The writepage interface optimizes large file writes to a socket
> just fine.
OK, but can you eventually generalize it to non-stream protocols
(i.e. UDP)?
After all, it doesn't make sense to differentiate between zero-copy on
stream and non-stream sockets, and Linux NFS, at least, remains
heavily UDP-oriented...
Cheers,
Trond
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1, Stephen Frost |
|---|---|
| Next by Date: | Apparent bug in cls_u32.c, Christopher Neufeld |
| Previous by Thread: | Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1, David S. Miller |
| Next by Thread: | Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1, David S. Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |