From: Rick Jones <rick.jones2@hp.com>
To: Bill Fink <billfink@mindspring.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
ilpo.jarvinen@helsinki.fi, zbr@ioremap.net,
bert.hubert@netherlabs.nl, h.willstrand@gmail.com,
netdev@vger.kernel.org
Subject: Re: sendfile()? Re: SO_LINGER dead: I get an immediate RST on 2.6.24?
Date: Mon, 12 Jan 2009 23:06:04 -0800 [thread overview]
Message-ID: <496C3D5C.7080407@hp.com> (raw)
In-Reply-To: <20090113015614.3b815ad7.billfink@mindspring.com>
Bill Fink wrote:
> On Tue, 13 Jan 2009, Herbert Xu wrote:
>
>
>>Bill Fink <billfink@mindspring.com> wrote:
>>
>>>If I understand you correctly, to hit this corner case, just after
>>>the final TCP write, there would have to be no packets in flight
>>>together with a zero TCP window. To make it more bullet-proof, I
>>>guess after seeing a zero tcpi_unacked, an additional small delay
>>>should be performed, and then rechecking for a zero tcpi_unacked.
>>>I don't see anything else obvious (to me anyway) in the tcp_info
>>>that would be particularly helpful in handling this.
>>
>>What's wrong with idiag_wqueue? Isn't that a much more direct
>>way to get this?
>
>
> I'm not familiar with idiag_wqueue, but it sounds like it has something
> to do with INET_DIAG/INET_TCP_DIAG. It was a long time ago, but I seem
> to recall that using INET_DIAG had a negative impact on performance,
> and since the main point of nuttcp is to measure TCP/UDP performance,
> that would be contrary to its primary purpose. Also, I don't want to
> rely on something that's not guaranteed to be part of the running kernel.
How likely is it that the "additional small delay" above would be much
less than waiting for a read return of zero after a shutdown(SHUT_WR) call?
rick jones
next prev parent reply other threads:[~2009-01-13 7:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 6:32 sendfile()? Re: SO_LINGER dead: I get an immediate RST on 2.6.24? Herbert Xu
2009-01-13 6:56 ` Bill Fink
2009-01-13 7:01 ` Herbert Xu
2009-01-14 7:43 ` Bill Fink
2009-01-14 8:29 ` Herbert Xu
2009-01-14 9:05 ` Bill Fink
2009-01-14 11:30 ` Herbert Xu
2009-01-15 6:33 ` Bill Fink
2009-01-13 7:06 ` Rick Jones [this message]
2009-01-14 8:05 ` Bill Fink
2009-01-14 8:08 ` Rick Jones
2009-01-14 8:32 ` Bill Fink
-- strict thread matches above, loose matches on Subject: below --
2009-01-11 21:23 bert hubert
2009-01-11 22:08 ` H. Willstrand
2009-01-11 22:45 ` sendfile()? " bert hubert
2009-01-11 22:54 ` Evgeniy Polyakov
2009-01-11 23:08 ` bert hubert
2009-01-11 23:18 ` Evgeniy Polyakov
2009-01-12 4:50 ` Bill Fink
2009-01-12 9:18 ` Ilpo Järvinen
2009-01-13 5:31 ` Bill Fink
2009-02-13 17:02 ` Jeremy Jackson
2009-02-20 18:10 ` Bill Fink
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=496C3D5C.7080407@hp.com \
--to=rick.jones2@hp.com \
--cc=bert.hubert@netherlabs.nl \
--cc=billfink@mindspring.com \
--cc=h.willstrand@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=netdev@vger.kernel.org \
--cc=zbr@ioremap.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).