From: Harald Welte <[EMAIL PROTECTED]>
Date: Tue, 12 Jul 2005 13:31:23 +0200
> On Mon, Jul 11, 2005 at 01:21:03PM -0700, David S. Miller wrote:
> > I still see no real use for this feature. Either the data is
> > stored inside of kernel buffers, or user application buffers.
> > And if the data sent is not useful to the receiver, fix the
> > sender to not send the unwanted data.
>
> Well, this assumes that you have full control over both ends. In
> reality you are often confronted with misdesigned "standard" protocols
> (I'm not even talking about proprietary senders/servers, or boxes
> outside of your control).
>
> So I have to disagree in that I think the feature is useful. Whether or
> not it is feasible without complicating the codebase unneccessary, I
> don't know.
But even if you can't control the sender, the seeking buys you no
memory savings at all. You don't consume less memory, because even
the data you're not interested in sits in kernel buffers while you
wait for the stuff you're interested in to arrive.
I do see how you can avoid some copies, but that seems easier to
implement with a "MSG_NOCOPY" or similar recvmsg() flag rather than
seeking. Ie, to skip the crap you're not interested in you go:
int len = recv(sock_fd, NULL, ignore_len, MSG_NOCOPY);
Then you do normal reads into a buffer for the parts you really
do want.
That is infinitely cleaner than this seek() idea, really.
Sockets were not meant to be seek()'d upon, so don't go there.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
