From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46164) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSy6u-0002yy-Rj for qemu-devel@nongnu.org; Fri, 11 May 2012 18:14:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SSy6t-00081g-58 for qemu-devel@nongnu.org; Fri, 11 May 2012 18:14:52 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:33492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSy6s-00081Z-SZ for qemu-devel@nongnu.org; Fri, 11 May 2012 18:14:51 -0400 Received: by dadv2 with SMTP id v2so4959933dad.4 for ; Fri, 11 May 2012 15:14:48 -0700 (PDT) From: Ronnie Sahlberg Date: Sat, 12 May 2012 08:04:36 +1000 Message-Id: <1336773877-20725-1-git-send-email-ronniesahlberg@gmail.com> Subject: [Qemu-devel] [PATCH 0/1] ISCSI: Dont call libiscsi for POLLIN if there are no bytes readable from the socket List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, kwolf@redhat.com, pbonzini@redhat.com Kevin, List, Paolo Updated patch based on Paolo's suggestion to do these checks in iscsi_process_read instead. Additionally, since this means we can no remain setting a fd-is-readable event unconditionally we can handle target initiated NOPs better. For example the case when the initiator is idle for a long time and has no i/o in flight a target may at this situation send NOPs to the initiator to ping that it is still alive, as an alternative to TCP-Keepalives. Unconditionally setting fd-is-readable event means that we will trigger on such target driven NOPs and can respond to them even if the initiator itself is idle. When iscsi_process_read is invoked we check if there is a socket error. If there is we pass POLLIN down to libiscsi and let it handle it, and possibly also try to reconnect and recover. If not, we check if there are any available bytes to read using ioctl(...FIONREAD...) and if there were no bytes avaialble, we assume that this was probably just a false invocation of the read event so we do nothing and just return. If there were bytes available to read from the socket, we pass POLLIN down into libiscsi as usual and let it read and process them. regards ronnie sahlberg