Re: Possible problem with zero-copy TCP and sendfile()
On Tue, Apr 17, 2001 at 01:23:07PM -0700, David S. Miller wrote: > One more subtle note, for the case of error handling. There is a > change to sendfile() in the zerocopy patches which causes sendfile() > to act more like sendmsg() when errors occur. How is this likely to affect applications? Currently, the glibc2.1 sendfile interface looks like: ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count); On error, -1 is returned in the usual fashion and offset is purported to be updated to point to the next byte following the last one sent. Will the zerocopy patches break this? > > Specifically, sendmsg() works roughly like the following when an > error happens: > > handle_error: > if (sent_something) > return how_much_we_sent; > else > return ERROR_CODE; > > So when an error happens, and the kernel was able to send some of > the data, you see something like this in the trace: > > sendmsg() = N > ... > sendmsg() = ERROR_CODE > > sendfile() used to act differently, and this made it difficult to > directly transform a sendmsg()+local_buffer based server into a > sendfile() one because the error handling was so different. > > Previously, sendfile() wouldn't give you the partial transfer length, > you'd just get the error _regardless_ of whether any data was sent > successfully during that call. Alexey, myself, and others considered > this behavior bogus and inconsistent. So it was changed. > > The long and short of it is that sendfile() now acts just like > sendmsg() when errors happen mid-send. > > Later, > David S. Miller > [EMAIL PROTECTED] -- "In the event of a failure, the system can be configured to automatically restart itself. This feature of Windows NT Server provides maximum system up-time." -- Reliability and Fault Tolerance in Windows NT Server, MSC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible problem with zero-copy TCP and sendfile()
On Tue, Apr 17, 2001 at 06:15:24PM +0200, Jan Kasprzak wrote: > Alan Cox wrote: > : > : but once a fixed BIOS is out for your board that would be a good first step. > : > : If it still does it then, its worth digging for kernel naughties > : > : > : > I don't think I have 686b southbridge. I have 686 (without "b"): > : > : Ok. What revision of 3c90x card do you have ? > : > PCI: Found IRQ 11 for device 00:0c.0 > 3c59x.c:LK1.1.13 27 Jan 2001 Donald Becker and others. >http://www.scyld.com/network/vortex.html > See Documentation/networking/vortex.txt > eth0: 3Com PCI 3c905C Tornado at 0xa000, 00:50:da:06:95:21, IRQ 11 > product code 5957 rev 00.13 date 07-17-99 > 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. > MII transceiver found at address 24, status 782d. > Enabling bus-master transmits and whole-frame receives. > eth0: scatter/gather enabled. h/w checksums enabled > > Some more progress: I now downgraded to proftpd without sendfile(). > The CPU usage is now nearly 100% (with ~170 FTP users; with sendfile() > it was under 50% with >320 FTP users). But nevertheless, the downloaded > images now seem to be OK. After cursory examination of proftpd, it appears that there is a misuse of the sendfile() call under Linux, which may be responsible for the corruption. The code was originally based on BSD semantics. Under Linux, the offset argument is not being used correctly to determine how much data has been sent in the case of EINTR. A patch will be coming out soon, as it is a fairly trivial fix. -- "In the event of a failure, the system can be configured to automatically restart itself. This feature of Windows NT Server provides maximum system up-time." -- Reliability and Fault Tolerance in Windows NT Server, MSC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible problem with zero-copy TCP and sendfile()
On Tue, Apr 17, 2001 at 06:15:24PM +0200, Jan Kasprzak wrote: Alan Cox wrote: : : but once a fixed BIOS is out for your board that would be a good first step. : : If it still does it then, its worth digging for kernel naughties : : :I don't think I have 686b southbridge. I have 686 (without "b"): : : Ok. What revision of 3c90x card do you have ? : PCI: Found IRQ 11 for device 00:0c.0 3c59x.c:LK1.1.13 27 Jan 2001 Donald Becker and others. http://www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt eth0: 3Com PCI 3c905C Tornado at 0xa000, 00:50:da:06:95:21, IRQ 11 product code 5957 rev 00.13 date 07-17-99 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. eth0: scatter/gather enabled. h/w checksums enabled Some more progress: I now downgraded to proftpd without sendfile(). The CPU usage is now nearly 100% (with ~170 FTP users; with sendfile() it was under 50% with 320 FTP users). But nevertheless, the downloaded images now seem to be OK. After cursory examination of proftpd, it appears that there is a misuse of the sendfile() call under Linux, which may be responsible for the corruption. The code was originally based on BSD semantics. Under Linux, the offset argument is not being used correctly to determine how much data has been sent in the case of EINTR. A patch will be coming out soon, as it is a fairly trivial fix. -- "In the event of a failure, the system can be configured to automatically restart itself. This feature of Windows NT Server provides maximum system up-time." -- Reliability and Fault Tolerance in Windows NT Server, MSC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible problem with zero-copy TCP and sendfile()
On Tue, Apr 17, 2001 at 01:23:07PM -0700, David S. Miller wrote: One more subtle note, for the case of error handling. There is a change to sendfile() in the zerocopy patches which causes sendfile() to act more like sendmsg() when errors occur. How is this likely to affect applications? Currently, the glibc2.1 sendfile interface looks like: ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count); On error, -1 is returned in the usual fashion and offset is purported to be updated to point to the next byte following the last one sent. Will the zerocopy patches break this? Specifically, sendmsg() works roughly like the following when an error happens: handle_error: if (sent_something) return how_much_we_sent; else return ERROR_CODE; So when an error happens, and the kernel was able to send some of the data, you see something like this in the trace: sendmsg() = N ... sendmsg() = ERROR_CODE sendfile() used to act differently, and this made it difficult to directly transform a sendmsg()+local_buffer based server into a sendfile() one because the error handling was so different. Previously, sendfile() wouldn't give you the partial transfer length, you'd just get the error _regardless_ of whether any data was sent successfully during that call. Alexey, myself, and others considered this behavior bogus and inconsistent. So it was changed. The long and short of it is that sendfile() now acts just like sendmsg() when errors happen mid-send. Later, David S. Miller [EMAIL PROTECTED] -- "In the event of a failure, the system can be configured to automatically restart itself. This feature of Windows NT Server provides maximum system up-time." -- Reliability and Fault Tolerance in Windows NT Server, MSC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
