| 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
| ||
|
Message-ID: <4C99125D.6060106@hp.com> Date: Tue, 21 Sep 2010 13:15:25 -0700 From: Rick Jones <rick.jones2@...com> To: Tom Herbert <therbert@...gle.com> CC: netdev@...r.kernel.org, davem@...emloft.net, sridharr@...gle.com Subject: Re: [PATCH v2] xmit_compl_seq: information to reclaim vmsplice buffers > 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 -- 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
Powered by blists - more mailing lists