netdev - Re: [PATCH] xmit_compl_seq: information to reclaim vmsplice buffers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTinyZxF4ep7tv_uSpcPD8gfNoddX6G7p+ZuA2ze9@mail.gmail.com>
Date:	Mon, 20 Sep 2010 11:22:21 +0800
From:	Changli Gao <xiaosuo@...il.com>
To:	Tom Herbert <therbert@...gle.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, sridharr@...gle.com
Subject: Re: [PATCH] xmit_compl_seq: information to reclaim vmsplice buffers

On Mon, Sep 20, 2010 at 5:55 AM, Tom Herbert <therbert@...gle.com> wrote:
> In this patch we propose to adds some socket API to retrieve the
>  "transmit completion sequence number", essentially a byte counter
> for the number of bytes that have been transmitted and will not be
> retransmitted.  In the case of TCP, this should correspond to snd_una.
>
> The purpose of this API is to provide information to userspace about
> which buffers can be reclaimed when sending with vmsplice() on a
> socket.
>
> There are two methods for retrieving the completed sequence number:
> through a simple getsockopt (implemented here for TCP), as well as
> returning the value in the ancilary data of a recvmsg.
>
> The expected flow would be something like:
>   - Connect is created
>   - Initial completion seq # is retrieved through the sockopt, and is
>     stored in userspace "compl_seq" variable for the connection.
>   - Whenever a send is done, compl_seq += # bytes sent.
>   - When doing a vmsplice the completion sequence number is saved
>     for each user space buffer, buffer_compl_seq = compl_seq.
>   - When recvmsg returns with a completion sequence number in
>     ancillary data, any buffers cover by that sequence number
>     (where buffer_compl_seq < recvmsg_compl_seq) are reclaimed
>     and can be written to again.
>   - If no data is receieved on a connection (recvmsg does not
>     return), a timeout can be used to call the getsockopt and
>     reclaim buffers as a fallback.
>
> Using recvmsg data in this manner is sort of a cheap way to get a
> "callback" for when a vmspliced buffer is consumed.  It will work
> well for a client where the response causes recvmsg to return.

In this case, we don't need it. The response is sufficient to indicate
the request is sent out, and the corresponding pages are available for
the other use.

> On the server side it works well if there are a sufficient
> number of requests coming on the connection (resorting to the
> timeout if necessary as described above).

If no response is sent out by the client, the timeout mechanism may
slow down the data transfer.

I think we should not mix RX and TX. Maybe we can add a new epoll
event to indicate that the snd bufer is advanced.

-- 
Regards,
Changli Gao(xiaosuo@...il.com)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html