Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Ingo Molnar wrote: > this is what TUX uses. When a eg. static HTTP request arrives it sends > reply headers shortly after having checked file permissions and stuff (but > the file is not yet sent), with MSG_MORE set. Then it sends the file, and > sendfile() keeps MSG_MORE set right until the end

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Ingo Molnar wrote: this is what TUX uses. When a eg. static HTTP request arrives it sends reply headers shortly after having checked file permissions and stuff (but the file is not yet sent), with MSG_MORE set. Then it sends the file, and sendfile() keeps MSG_MORE set right until the end of

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

http://community.roxen.com/developers/idocs/drafts/draft-minshall-nagle-01.txt There's also a paper on the specific issues: http://www.cc.gatech.edu/fac/Ellen.Zegura/wisp99/papers/minshall.ps You may also want to look up the ietf tcp-impl archive from '99 for discussions on the draft. cheers,

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

http://community.roxen.com/developers/idocs/drafts/draft-minshall-nagle-01.txt There's also a paper on the specific issues: http://www.cc.gatech.edu/fac/Ellen.Zegura/wisp99/papers/minshall.ps You may also want to look up the ietf tcp-impl archive from '99 for discussions on the draft. cheers,

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On 20 Jan 2001, Kai Henningsen wrote: > [EMAIL PROTECTED] (dean gaudet) wrote on 18.01.01 in ><[EMAIL PROTECTED]>: > > > i'm pretty sure the actual use of pipelining is pretty disappointing. > > the work i did in apache preceded the widespread use of HTTP/1.1 and we > > What widespread use of

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

[EMAIL PROTECTED] wrote: > > Hello! > > > is there really > > much value in the second request flowing to the server before the first > > byte of the reply has hit? > > Yes, of course, it has lots of sense: f.e. all the icons, referenced >

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

[EMAIL PROTECTED] wrote: Hello! is there really much value in the second request flowing to the server before the first byte of the reply has hit? Yes, of course, it has lots of sense: f.e. all the icons, referenced parent page

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On 20 Jan 2001, Kai Henningsen wrote: [EMAIL PROTECTED] (dean gaudet) wrote on 18.01.01 in [EMAIL PROTECTED]: i'm pretty sure the actual use of pipelining is pretty disappointing. the work i did in apache preceded the widespread use of HTTP/1.1 and we What widespread use of HTTP/1.1?

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! > So now the question is: when does this new nagle algorithm delay packets in the > write queue? It _must_ do something, otherwise TCP_NODELAY would obviously be a > noop. It allows _one_ incomplete segment to fly. Minshall and BSD behave absolutely similarly in all the curcumstances

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! So now the question is: when does this new nagle algorithm delay packets in the write queue? It _must_ do something, otherwise TCP_NODELAY would obviously be a noop. It allows _one_ incomplete segment to fly. Minshall and BSD behave absolutely similarly in all the curcumstances except

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sun, 21 Jan 2001, Lincoln Dale wrote: > hi, > > At 04:56 PM 20/01/2001 +0200, Kai Henningsen wrote: > >[EMAIL PROTECTED] (dean gaudet) wrote on 18.01.01 in > ><[EMAIL PROTECTED]>: > > > i'm pretty sure the actual use of pipelining is pretty disappointing. > > > the work i did in apache

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

hi, At 04:56 PM 20/01/2001 +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (dean gaudet)  wrote on 18.01.01 in <[EMAIL PROTECTED]>: > i'm pretty sure the actual use of pipelining is pretty disappointing. > the work i did in apache preceded the widespread use of HTTP/1.1 and we What widespread

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, Jan 20, 2001 at 10:39:36PM +0300, Alexey Kuznetsov wrote: > Yes. It is cost, which we have to pay. Look into Minshall's draft, > by the way (draft-minshall-nagle-*), it discusses pros and contras. What kind of draft is that? I can't find it on the IETF site. Could you provide me with a

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, Jan 20, 2001 at 11:22:14PM +0300, [EMAIL PROTECTED] wrote: > Hello! > > > > write(10*MSS) > > > write(1) > > > write(1) > ... > > As far as I can tell, the second "write(1)" will always merge with the > > first one > > This would be true, if Andrea wrote not exactly

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, Jan 20, 2001 at 10:39:36PM +0300, [EMAIL PROTECTED] wrote: > Much saner behaviour wrt latency (and perfect clarity) overweights IMHO latency can be fixed in a much better way using ioctl(SIOCPUSH) after the last write() plus we could also add a MSG_NOMORE to set in the last send().

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, Jan 20, 2001 at 11:39:30AM -0800, Linus Torvalds wrote: > As far as I can tell, the second "write(1)" will always merge with the > first one - unless the first one has already been sent out, [..] Here the question is only if the first write(1) will be still there when we do the second

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! > > write(10*MSS) > > write(1) > > write(1) ... > As far as I can tell, the second "write(1)" will always merge with the > first one This would be true, if Andrea wrote not exactly 10*MSS, but 10*MSS+1 or just write(). In some exceptional situations (sort of

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! > So this mean if I do: Yes. It is cost, which we have to pay. Look into Minshall's draft, by the way (draft-minshall-nagle-*), it discusses pros and contras. Much saner behaviour wrt latency (and perfect clarity) overweights a bit worse coalescing. Alexey - To unsubscribe from this

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

[EMAIL PROTECTED] (dean gaudet) wrote on 18.01.01 in <[EMAIL PROTECTED]>: > i'm pretty sure the actual use of pipelining is pretty disappointing. > the work i did in apache preceded the widespread use of HTTP/1.1 and we What widespread use of HTTP/1.1? I justtried the following excercise:

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, 20 Jan 2001, Andrea Arcangeli wrote: > On Sat, Jan 20, 2001 at 10:05:45PM +0300, [EMAIL PROTECTED] wrote: > > It makes. One small packet is allowed to fly, not depending on packets_out. > > So this mean if I do: > > write(10*MSS) > write(1) > write(1) > > 2.4

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, Jan 20, 2001 at 10:05:45PM +0300, [EMAIL PROTECTED] wrote: > It makes. One small packet is allowed to fly, not depending on packets_out. So this mean if I do: write(10*MSS) write(1) write(1) 2.4 can send 10 packet with MSS large payload plus two packets

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! > semantics of snd_sml), maybe it makes the difference but then I don't see how. It makes. One small packet is allowed to fly, not depending on packets_out. This is idea of Minshall. "Classic" Nagle also does not prohibit this, but it is difficult to formulate it in terms of

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, Jan 20, 2001 at 08:28:04PM +0300, [EMAIL PROTECTED] wrote: > Hello! > > > My argument applies to 2.4. The uncork _won't_ push on the wire the last > > not mss-sized fragment until it's the last one in the write queue even once > > cwnd and receiver window allows that. I think > > Look

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! > is there really > much value in the second request flowing to the server before the first > byte of the reply has hit? Yes, of course, it has lots of sense: f.e. all the icons, referenced parent page are batched to single

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

[EMAIL PROTECTED] wrote: > > > > The manpage disagrees with you: > > Do you jest? > > This manpages is wrong, or, to be more exact, is incomplete, > which is common flaw of them. > > get/set mean nothing but read-only/changing, i.e. > another important property missing in ioctl interface.

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! > My argument applies to 2.4. The uncork _won't_ push on the wire the last > not mss-sized fragment until it's the last one in the write queue even once > cwnd and receiver window allows that. I think Look at the code again. You misread it. > wouldn't be setting nonalge

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! My argument applies to 2.4. The uncork _won't_ push on the wire the last not mss-sized fragment until it's the last one in the write queue even once cwnd and receiver window allows that. I think Look at the code again. You misread it. wouldn't be setting nonalge unconditionally to

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! is there really much value in the second request flowing to the server before the first byte of the reply has hit? Yes, of course, it has lots of sense: f.e. all the icons, referenced parent page are batched to single

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

[EMAIL PROTECTED] wrote: The manpage disagrees with you: Do you jest? This manpages is wrong, or, to be more exact, is incomplete, which is common flaw of them. get/set mean nothing but read-only/changing, i.e. another important property missing in ioctl interface. setsockopt

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, Jan 20, 2001 at 08:28:04PM +0300, [EMAIL PROTECTED] wrote: Hello! My argument applies to 2.4. The uncork _won't_ push on the wire the last not mss-sized fragment until it's the last one in the write queue even once cwnd and receiver window allows that. I think Look at the

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! semantics of snd_sml), maybe it makes the difference but then I don't see how. It makes. One small packet is allowed to fly, not depending on packets_out. This is idea of Minshall. "Classic" Nagle also does not prohibit this, but it is difficult to formulate it in terms of presegmented

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, Jan 20, 2001 at 10:05:45PM +0300, [EMAIL PROTECTED] wrote: It makes. One small packet is allowed to fly, not depending on packets_out. So this mean if I do: write(10*MSS) write(1) write(1) 2.4 can send 10 packet with MSS large payload plus two packets

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, 20 Jan 2001, Andrea Arcangeli wrote: On Sat, Jan 20, 2001 at 10:05:45PM +0300, [EMAIL PROTECTED] wrote: It makes. One small packet is allowed to fly, not depending on packets_out. So this mean if I do: write(10*MSS) write(1) write(1) 2.4 can send

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

[EMAIL PROTECTED] (dean gaudet) wrote on 18.01.01 in [EMAIL PROTECTED]: i'm pretty sure the actual use of pipelining is pretty disappointing. the work i did in apache preceded the widespread use of HTTP/1.1 and we What widespread use of HTTP/1.1? I justtried the following excercise:

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! write(10*MSS) write(1) write(1) ... As far as I can tell, the second "write(1)" will always merge with the first one This would be true, if Andrea wrote not exactly 10*MSS, but 10*MSS+1 or just write(lots of data). In some exceptional situations (sort of

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! So this mean if I do: Yes. It is cost, which we have to pay. Look into Minshall's draft, by the way (draft-minshall-nagle-*), it discusses pros and contras. Much saner behaviour wrt latency (and perfect clarity) overweights a bit worse coalescing. Alexey - To unsubscribe from this

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, Jan 20, 2001 at 11:22:14PM +0300, [EMAIL PROTECTED] wrote: Hello! write(10*MSS) write(1) write(1) ... As far as I can tell, the second "write(1)" will always merge with the first one This would be true, if Andrea wrote not exactly 10*MSS, but

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, Jan 20, 2001 at 11:39:30AM -0800, Linus Torvalds wrote: As far as I can tell, the second "write(1)" will always merge with the first one - unless the first one has already been sent out, [..] Here the question is only if the first write(1) will be still there when we do the second

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, Jan 20, 2001 at 10:39:36PM +0300, [EMAIL PROTECTED] wrote: Much saner behaviour wrt latency (and perfect clarity) overweights IMHO latency can be fixed in a much better way using ioctl(SIOCPUSH) after the last write() plus we could also add a MSG_NOMORE to set in the last send().

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sat, Jan 20, 2001 at 10:39:36PM +0300, Alexey Kuznetsov wrote: Yes. It is cost, which we have to pay. Look into Minshall's draft, by the way (draft-minshall-nagle-*), it discusses pros and contras. What kind of draft is that? I can't find it on the IETF site. Could you provide me with a

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

hi, At 04:56 PM 20/01/2001 +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (dean gaudet) wrote on 18.01.01 in [EMAIL PROTECTED]: i'm pretty sure the actual use of pipelining is pretty disappointing. the work i did in apache preceded the widespread use of HTTP/1.1 and we What widespread use of

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Sun, 21 Jan 2001, Lincoln Dale wrote: hi, At 04:56 PM 20/01/2001 +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (dean gaudet) wrote on 18.01.01 in [EMAIL PROTECTED]: i'm pretty sure the actual use of pipelining is pretty disappointing. the work i did in apache preceded the

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

> Look: http-1.1, asynchronous one, the first request is sent, but not acked. > Time to send the second one, but it is blocked by Nagle. If there is no > third request, the pipe stalls. Seems, this situation will be usual, > when http-1.1 will start to be used by clients, because of dependencies

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Fri, Jan 19, 2001 at 09:18:04PM +0300, [EMAIL PROTECTED] wrote: > Hello! > > > The "uncork" won't push the last skb on the wire if there is not acknowledged > > data in the write_queue and the payload of the last skb in the write_queue > > isn't large MSS. This because the `uncork' will only

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Fri, Jan 19, 2001 at 08:52:53PM +0300, [EMAIL PROTECTED] wrote: > Hello! > > > I thought setsockopt is meant to set an option in the socket, > > It is not. The manpage disagrees with you: getsockopt, setsockopt - get and set options on sockets

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! > the business about the last 1100ish bytes of a 4096 byte send being > delayed by nagle only implies that the stack's implementation of nagle > was broken and interpreting it on a per-segment rather than a per-send > basis. + > software, or the host TCP stack. otherwise, the persistent

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

dean gaudet wrote: > > On Wed, 17 Jan 2001, Rick Jones wrote: > > > > actually the problem isn't nagle... nagle needs to be turned off for > > > efficient servers anyhow. > > > > i'm not sure I follow that. could you expand on that a bit? > > the problem which caused us to disable nagle in

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! > The "uncork" won't push the last skb on the wire if there is not acknowledged > data in the write_queue and the payload of the last skb in the write_queue > isn't large MSS. This because the `uncork' will only re-evaluate the > write_queue in function of the _nagle_ algorithm, quite

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! > I thought setsockopt is meant to set an option in the socket, It is not. setsockopt() is simply a bit more clever extension to ioctl(), which is adapted (in bsd style though) to understand layering and has an explicit length to data. It is prefered for all the operations on sockets,

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 11:18:48PM +0100, Ingo Molnar wrote: > > On Thu, 18 Jan 2001, Andrea Arcangeli wrote: > > > This is a possible slow (but userspace based) implementation of SIOCPUSH: > > of course this is what i meant. Lets stop wasting time on this, ok? We were both wrong. Not even my

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! I thought setsockopt is meant to set an option in the socket, It is not. setsockopt() is simply a bit more clever extension to ioctl(), which is adapted (in bsd style though) to understand layering and has an explicit length to data. It is prefered for all the operations on sockets,

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

dean gaudet wrote: On Wed, 17 Jan 2001, Rick Jones wrote: actually the problem isn't nagle... nagle needs to be turned off for efficient servers anyhow. i'm not sure I follow that. could you expand on that a bit? the problem which caused us to disable nagle in apache is

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! the business about the last 1100ish bytes of a 4096 byte send being delayed by nagle only implies that the stack's implementation of nagle was broken and interpreting it on a per-segment rather than a per-send basis. + software, or the host TCP stack. otherwise, the persistent

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Fri, Jan 19, 2001 at 08:52:53PM +0300, [EMAIL PROTECTED] wrote: Hello! I thought setsockopt is meant to set an option in the socket, It is not. The manpage disagrees with you: getsockopt, setsockopt - get and set options on sockets

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Look: http-1.1, asynchronous one, the first request is sent, but not acked. Time to send the second one, but it is blocked by Nagle. If there is no third request, the pipe stalls. Seems, this situation will be usual, when http-1.1 will start to be used by clients, because of dependencies

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! The "uncork" won't push the last skb on the wire if there is not acknowledged data in the write_queue and the payload of the last skb in the write_queue isn't large MSS. This because the `uncork' will only re-evaluate the write_queue in function of the _nagle_ algorithm, quite

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 11:18:48PM +0100, Ingo Molnar wrote: On Thu, 18 Jan 2001, Andrea Arcangeli wrote: This is a possible slow (but userspace based) implementation of SIOCPUSH: of course this is what i meant. Lets stop wasting time on this, ok? We were both wrong. Not even my

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Fri, Jan 19, 2001 at 09:18:04PM +0300, [EMAIL PROTECTED] wrote: Hello! The "uncork" won't push the last skb on the wire if there is not acknowledged data in the write_queue and the payload of the last skb in the write_queue isn't large MSS. This because the `uncork' will only

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

dean gaudet wrote: > the reason, gag puke, is for doing things such as sending "activity" > progress -- like a line at a time or whatever to indicate that the CGI is > there and still working. I understand the gagging on this and generally I agree. I do appreciate having the ability to do this

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

ok i'm spouting lots today sorry! :) can i just say this solves even more problems? there's a problem with the current apache pipeline code where if a pipeline consists of, say, a light request followed by a heavy request. a "light" request is say, a static file, something that essentially is

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

huh -- i think with this apache could solve the problem documented in heidemann's paper while also leaving nagle on... which would solve the CGI dribbler vs. bulk problem i just posted about. at the end of a request apache would check first if it can get another request without blocking; if it

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Zach Brown wrote: > We set TCP_CORK on the socket we handed to external programs that were > being run via 'site exec' in an ftp server. It resulted in much nicer > packets being spit out, especially in the 'ls' case where it likes to > write() on really goofy boundaries. >

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

btw -- i'd like to point out something which some folks are aware of already. pipelining was only part of the answer to fixing HTTP/1.0 network performance problems. the real answer is a multiplexing protocol such as WebMUX . a MUX protocol is more general

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Wed, 17 Jan 2001, Rick Jones wrote: > > actually the problem isn't nagle... nagle needs to be turned off for > > efficient servers anyhow. > > i'm not sure I follow that. could you expand on that a bit? the problem which caused us to disable nagle in apache is documented in this paper

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Olivier Galibert wrote: > > On Thu, Jan 18, 2001 at 10:04:28PM +0100, Andrea Arcangeli wrote: > > NAGLE algorithm is only one, CORK algorithm is another different algorithm. So > > probably it would be not appropriate to mix CORK and NAGLE under the name > > "CONTROL_NAGLING", but certainly I

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 10:04:28PM +0100, Andrea Arcangeli wrote: > NAGLE algorithm is only one, CORK algorithm is another different algorithm. So > probably it would be not appropriate to mix CORK and NAGLE under the name > "CONTROL_NAGLING", but certainly I agree they could stay together under

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

[EMAIL PROTECTED] wrote: > > Hello! > > > So if I understand all this correctly... > > > > The difference in ACK generation > > CORK does not affect receive direction and, hence, ACK geneartion. I was asking how the semantics of cork interacted with piggybacking ACK's on data flowing the

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Andrea Arcangeli wrote: > BTW, the simmetry between getsockopt/setsockopt further bias how > SIOCPUSH doesn't fit into the setsockopt options but it fits very well > into the ioctl categorty instead. There's simply no state one can > return via getsockopt for the SIOCPUSH

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 10:57:20PM +0100, Ingo Molnar wrote: > > On Thu, 18 Jan 2001, Andrea Arcangeli wrote: > > > > { > > > int val = 1; > > > setsockopt(req->sock, IPPROTO_TCP, TCP_CORK, > > > (char *),sizeof(val)); > > > val = 0; > > >

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Andrea Arcangeli wrote: > This is a possible slow (but userspace based) implementation of SIOCPUSH: of course this is what i meant. Lets stop wasting time on this, ok? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 09:44:57PM +0100, Ingo Molnar wrote: > why? TCP_CORK is equivalent to MSG_MORE, it's just a different I thought you agreed it isn't (Linus's example I quoted). > > Doing PUSH from setsockopt(TCP_CORK) looked obviously wrong because it > > isn't setting any socket state,

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Andrea Arcangeli wrote: > > { > > int val = 1; > > setsockopt(req->sock, IPPROTO_TCP, TCP_CORK, > > (char *),sizeof(val)); > > val = 0; > > setsockopt(req->sock, IPPROTO_TCP, TCP_CORK, > > (char

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 11:52:33AM -0800, Linus Torvalds wrote: > On Thu, 18 Jan 2001, Ingo Molnar wrote: > > > > i believe a network-conscious application should use MSG_MORE - that has > > no system-call overhead. > > I think Andrea was thinking more of the case of the anonymous IO >

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 11:37:10PM +0300, [EMAIL PROTECTED] wrote: > Hello! > > > Doing PUSH from setsockopt(TCP_CORK) looked obviously wrong because it isn't > > setting any socket state, > > ? 8) I thought setsockopt is meant to set an option in the socket, something _stateful_, a PUSH

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001 [EMAIL PROTECTED] wrote: > Actually, TUX-1.1 (Ingo, do I not lie, did you not kill this code?) > does this. It does not ack quickly, when complete request is received > and still not answered, so that all the redundant acks disappear. (it's TUX 2.0 meanwhile), and yes, TUX

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! > So if I understand all this correctly... > > The difference in ACK generation CORK does not affect receive direction and, hence, ACK geneartion. The problem is that TCP does not know, when full request is received and it must ack instantly at connection start and after some idle

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Andrea Arcangeli wrote: > Agreed. However since TCP_CORK logic is more generic than MSG_MORE > [...] why? TCP_CORK is equivalent to MSG_MORE, it's just a different representation of the same issue. TCP_CORK needs an extra syscall (in the case of a push event - which might

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 10:59:11PM +0300, [EMAIL PROTECTED] wrote: > Hello! > > > I'm all for TCP_CORK but it has the disavantage of two syscalls for doing the > > MSG_MORE was invented to allow to collapse this to 0 of syscalls. 8) Yes, I know. > > A new ioctl on the socket should be able to

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! > Doing PUSH from setsockopt(TCP_CORK) looked obviously wrong because it isn't > setting any socket state, ? 8) > and also because the SIOCPUSH has nothing specific > with TCP_CORK, as said it can be useful also to flush the last fragment of data > pending in the send queue without

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Linus Torvalds wrote: > I think Andrea was thinking more of the case of the anonymous IO > generator, and having the "controller" program thgat keeps the socket > always in CORK mode, but uses SIOCPUSH when it doesn't know what teh > future access patterns will be. yep. >

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 08:43:47PM +0100, Ingo Molnar wrote: > > On Thu, 18 Jan 2001, Andrea Arcangeli wrote: > > > I'm all for TCP_CORK but it has the disavantage of two syscalls for > > doing the flush of the outgoing queue to the network. And one of those > > two syscalls is spurious. [...]

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! > Ingo, you should realize Ingo did not try to argue. I do not too. This is right, no doubts. > Mantra: "everything is a stream of bytes". Repeat until enlightened. ... but devil invented record marks and pushes, seduced mankind and we was evicted from the paradise. 8) Alexey - To

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Hello! > I'm all for TCP_CORK but it has the disavantage of two syscalls for doing the MSG_MORE was invented to allow to collapse this to 0 of syscalls. 8) > A new ioctl on the socket should be able to do that (and ioctl looks ligther > than a setsockopt, ok ignoring actually the VFS is

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Ingo Molnar wrote: > > i believe a network-conscious application should use MSG_MORE - that has > no system-call overhead. I think Andrea was thinking more of the case of the anonymous IO generator, and having the "controller" program thgat keeps the socket always in CORK

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Andrea Arcangeli wrote: > > I'm all for TCP_CORK but it has the disavantage of two syscalls for doing the > flush of the outgoing queue to the network. And one of those two syscalls is > spurious. Certainly it makes perfect sense that the uncork flushes the outgoing >

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 10:20:16AM -0800, Rick Jones wrote: > Andi Kleen wrote: > > > > On Wed, Jan 17, 2001 at 02:17:36PM -0800, Rick Jones wrote: > > > How does CORKing interact with ACK generation? In particular how it > > > might interact with (or rather possibly induce) standalone ACKs? > >

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Andrea Arcangeli wrote: > I'm all for TCP_CORK but it has the disavantage of two syscalls for > doing the flush of the outgoing queue to the network. And one of those > two syscalls is spurious. [...] i believe a network-conscious application should use MSG_MORE - that has

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 08:49:38AM -0800, Linus Torvalds wrote: > state. However, the fact is that you _need_ the persistency of a socket > option if you want to take advantage of external programs etc getting good > behaviour without having to know that they are talking to a socket. I'm all

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Rick Jones wrote: > Linus Torvalds wrote: > > Remember the UNIX philosophy: everything is a file. > > ...and a file is simply a stream of bytes (iirc?) Indeed. And normal applications really shouldn't need to worry about things like packetization etc. Of course, many

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Linus Torvalds wrote: > Remember the UNIX philosophy: everything is a file. ...and a file is simply a stream of bytes (iirc?) rick jones -- ftp://ftp.cup.hp.com/dist/networking/misc/rachel/ these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Ingo Molnar wrote: > > On Wed, 17 Jan 2001, Rick Jones wrote: > > > i'd heard interesting generalities but no specifics. for instance, > > when the send is small, does TCP wait exclusively for the app to > > flush, or is there an "if all else fails" sort of timer running? > > yes there is a

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

Andi Kleen wrote: > > On Wed, Jan 17, 2001 at 02:17:36PM -0800, Rick Jones wrote: > > How does CORKing interact with ACK generation? In particular how it > > might interact with (or rather possibly induce) standalone ACKs? > > It doesn't change the ACK generation. If your cork'ed packets gets

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 08:49:38AM -0800, Linus Torvalds wrote: > That has its advantages: it's a very local thing, and doesn't need any > state. However, the fact is that you _need_ the persistency of a socket > option if you want to take advantage of external programs etc getting good >

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Linus Torvalds wrote: > Remember the UNIX philosophy: everything is a file. MSG_MORE > completely breaks that, because the only way to use it is with > send[msg](). It's absolutely unusable with something like a > traditional UNIX "anonymous" application that doesn't know

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Linus Torvalds wrote: > Yeah, and how are you going to teach a perl CGI script that writes to > stdout to use it? yep, correct. But you can have TCP_CORK behavior from user-space (by setting the cork flag in user-space and writing it for all network output), while you

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Ingo Molnar wrote: > > Basically MSG_MORE is a simplified probability distribution of the next > SEND, and it already covers all the other (iovec, nagle, TCP_CORK) > mechanizm available, in a surprisingly easy way IMO. I believe MSG_MORE is > very robust from a

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Ingo Molnar wrote: > > [ BSD's TCP_NOPUSH ] > > this is what MSG_MORE does.Basically i added MSG_MORE for the purpose of > getting perfect TUX packet boundaries (and was ignorant enough to not know > about BSD's NOPUSH), without an additional system-call overhead, and >

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 02:06:46PM +0100, Ingo Molnar wrote: > > On Wed, 17 Jan 2001, Rick Jones wrote: > > > i'd heard interesting generalities but no specifics. for instance, > > when the send is small, does TCP wait exclusively for the app to > > flush, or is there an "if all else fails"

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Wed, 17 Jan 2001, Rick Jones wrote: > certainly, i see by your examples how cork can make life easier on the > developer - they can putc() the reply if they want. for a persistent > http connection, there would be the cork and uncork each time, for a > pipelined connection, it is basically a

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Wed, 17 Jan 2001, Linus Torvalds wrote: > (I also had one person point out that BSD's have the notion of > TCP_NOPUSH, which does almost what TCP_CORK does under Linux, except > it doesn't seem to have the notion of uncorking - you can turn NOPUSH > off, but apparently it doesn't affect

  1   2   >