From: William Allen Simpson <william.allen.simpson@gmail.com>
To: netdev@vger.kernel.org
Subject: Re: [PATCH] TCPCT+1: initial SYN exchange with SYNACK data
Date: Mon, 05 Oct 2009 13:42:54 -0400 [thread overview]
Message-ID: <4ACA301E.3040806@gmail.com> (raw)
In-Reply-To: <20091005.014558.48061546.davem@davemloft.net>
David Miller wrote:
> Then we'll eat an atomic operation every connect() or something
> like that?
>
Yes, on the client side. On the server side, I was trying to avoid any
until after a 3-way handshake (the reason that I removed the kref'd struct
in Adam's request sock).
Adam:
+ struct tcp_sadata_payload *sadata_payload;
+ u8 sadata_nonce[4]; /* generated nonce */
+ u8 sadata_ok:1; /* send sadata? */
Mine:
+ u8 *cookie_copy; /* temporary pointer */
+ u8 cookie_size; /* bytes in copy */
+ u8 s_data_in:1,
+ s_data_out:1,
+ cookie_in_always:1,
+ cookie_out_never:1;
Mine makes the code more tricky, though. I'm depending on the various
locks and hashes to keep things kosher, whereas Adam kept more kref'd
pointer instances lying around for a longer time. Tradeoffs....
But I *was* patting myself on the back for saving 3 bytes here. ;-)
> That's bad too. We're trying desperately to remove as many
> atomic operations as possible from the socket paths.
>
And Adam had done a good job, too. The state has to go somewhere!
After all, I've plenty of experience with small TCP implementations, as
*all* implementations were constrained back in the day. At least one of
my tiny TCP/IP/PPP stack implementations is in hundreds of millions of
cell phones (originally on 186s with only a few K of RAM).
> Compress your state, really compress it, don't just externalize
> it somewhere else in exchange for a different cost.
>
Cookies are pseudo-random nonces, not compressible by definition.
I think I'll be able to join everything into a single kref'd block, with
some modification/reuse of various function md5sig parameters to pass
pointers.... Cookie nonces are redundant to the authenticator option(s),
so they're never around at the same time.
That will whittle the tcp_sock size down some more, although it could
increase the overall memory footprint, as there will be wasted space for
the case where there are cookies without SYN data. By keeping the sizes
and flags in the sock itself, both Adam and I were optimizing performance.
It's just tradeoffs, always and forever tradeoffs.
next prev parent reply other threads:[~2009-10-05 17:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-03 18:33 [PATCH] TCPCT+1: initial SYN exchange with SYNACK data William Allen Simpson
2009-10-05 7:27 ` David Miller
2009-10-05 7:58 ` William Allen Simpson
2009-10-05 8:06 ` David Miller
2009-10-05 8:23 ` William Allen Simpson
2009-10-05 8:50 ` David Miller
2009-10-05 9:22 ` Eric Dumazet
2009-10-05 8:11 ` William Allen Simpson
2009-10-05 8:45 ` David Miller
2009-10-05 17:42 ` William Allen Simpson [this message]
2009-10-05 7:45 ` William Allen Simpson
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=4ACA301E.3040806@gmail.com \
--to=william.allen.simpson@gmail.com \
--cc=netdev@vger.kernel.org \
/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).