Re: [PATCH v2] xmit_compl_seq: information to reclaim vmsplice buffers

[Rick Jones <rick.jones2@hp.com>]

> 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.
> 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 there is a recvmsg(), how often will the data received implicitly/explicitly 
tell the application how much of the previously sent data has been acked?  A 
subsequent request from the client in a persistent (but not pipelined) HTTP 
session implicitly says the data of the previous response was ACKed no?  Is that 
simply too rare to rely upon?

On the bulk side, an application filling the (fixed size at least) socket buffer 
will "know" that the bytes sent a "socket buffer size ago" were ACKed because 
that is what makes room in the socket buffer for data right?

rick jones

ftp://ftp.cup.hp.com/dist/networking/briefs/copyavoid.pdf