From: William Allen Simpson <william.allen.simpson@gmail.com>
To: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
Eric Dumazet <eric.dumazet@gmail.com>,
Joe Perches <joe@perches.com>
Subject: Re: [net-next-2.6 PATCH v5 5/5 RFC] TCPCT part1e: initial SYN exchange with SYNACK data
Date: Tue, 10 Nov 2009 08:41:05 -0500 [thread overview]
Message-ID: <4AF96D71.8000905@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0911100659470.7059@melkinpaasi.cs.helsinki.fi>
Ilpo Järvinen wrote:
> On Mon, 9 Nov 2009, William Allen Simpson wrote:
>>...
>> Data structures are carefully composed to require minimal additions.
>> For example, the struct tcp_options_received cookie_plus variable fits
>> between existing 16-bit and 8-bit variables, requiring no additional
>> space (taking alignment into consideration). There are no additions to
>> tcp_request_sock, and only 1 pointer in tcp_sock.
>>...
>
> One general comment. ...This particular patch still has lots of noise
> which does not belong to the context of this change. ...Please try to
> minimize. Eg., if you don't like sizeof(struct tcphdr) but prefer
> sizeof(*th), you certainly don't have to do it in this particular patch!
This *is* actually in CodingStyle (line 679), and I'm trying to conform:
<blockquote>
The preferred form for passing a size of a struct is the following:
p = kmalloc(sizeof(*p), ...);
The alternative form where struct name is spelled out hurts readability and
introduces an opportunity for a bug when the pointer variable type is changed
but the corresponding sizeof that is passed to a memory allocator is not.
</blockquote>
Maybe some of these anticipate part 2, so I can defer them to later. I've
already coded much of part 2, so things are bleeding back and forth.
> ...Also some comment changes which certainly are not mandatory nor even
> related.
>
Hmmm....
1) The first is a hole left by the removal of the data fields some time
ago, but they left the old (now incorrect) comment:
-/* SACKs data */
+ u8 cookie_plus:6, /* bytes in authenticator/cookie option */
+ cookie_out_never:1,
+ cookie_in_always:1;
u8 num_sacks; /* Number of SACK blocks */
Although it's not evident from the diff -u, I'm *filling* that hole,
putting everything on a nice 32-bit boundary, thus taking *NO* space
(already mentioned in my patch description above):
u16 saw_tstamp : 1, /* Saw TIMESTAMP on last packet */
tstamp_ok : 1, /* TIMESTAMP seen on SYN packet */
dsack : 1, /* D-SACK is scheduled */
wscale_ok : 1, /* Wscale seen on SYN packet */
sack_ok : 4, /* SACK seen on SYN packet */
snd_wscale : 4, /* Window scaling received from sender */
rcv_wscale : 4; /* Window scaling to send to receiver */
u8 cookie_plus:6, /* bytes in authenticator/cookie option */
cookie_out_never:1,
cookie_in_always:1;
u8 num_sacks; /* Number of SACK blocks */
u16 user_mss; /* mss requested by user in ioctl */
u16 mss_clamp; /* Maximal mss, negotiated at connection setup */
The only reason that it's done this way was Miller's imperative that
required cramming this into as small a space as possible.
"Store the data either somewhere else or in an extremely compact form."
"Make your state take up less space in tcp_sock without making it cost
more in some other form."
Of course, it costs more, and I have to keep copying it from place to place,
adding to the code complexity. But I was feeling rather clever to have
found that hole!
2) The second is a spelling error that I noticed in passing. It's within
the same diff -u area (close to other insertions both before and after), so
fixing it was trivial:
- * to increse this, although since:
+ * to increase this, although since:
Are we not supposed to fix spelling errors in comments?
next prev parent reply other threads:[~2009-11-10 13:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-09 16:07 [net-next-2.6 PATCH v5 0/5 RFC] TCPCT part1: cookie option exchange William Allen Simpson
2009-11-09 16:12 ` [net-next-2.6 PATCH v5 1/5 RFC] TCPCT part 1a: add request_values parameter for sending SYNACK William Allen Simpson
2009-11-09 16:24 ` [net-next-2.6 PATCH v5 2/5 RFC] TCPCT part1b: TCP_MSS_DEFAULT, TCP_MSS_DESIRED William Allen Simpson
2009-11-09 16:39 ` Eric Dumazet
2009-11-09 16:33 ` [net-next-2.6 PATCH v5 3/5 RFC] TCPCT part1c: sysctl_tcp_cookie_size, socket option TCP_COOKIE_TRANSACTIONS, functions William Allen Simpson
2009-11-10 5:31 ` Ilpo Järvinen
2009-11-10 14:43 ` William Allen Simpson
2009-11-09 16:50 ` [net-next-2.6 PATCH v5 4/5 RFC] TCPCT part1d: generate Responder Cookie William Allen Simpson
2009-11-09 17:05 ` [net-next-2.6 PATCH v5 5/5 RFC] TCPCT part1e: initial SYN exchange with SYNACK data William Allen Simpson
2009-11-10 5:05 ` Ilpo Järvinen
2009-11-10 13:41 ` William Allen Simpson [this message]
2009-11-10 14:00 ` Ilpo Järvinen
2009-11-10 14:30 ` Ilpo Järvinen
2009-11-10 16:49 ` William Allen Simpson
2009-11-11 1:48 ` Ilpo Järvinen
2009-11-10 14:29 ` Eric Dumazet
2009-11-10 15:45 ` William Allen Simpson
2009-11-11 1:32 ` Ilpo Järvinen
2009-11-11 17:35 ` 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=4AF96D71.8000905@gmail.com \
--to=william.allen.simpson@gmail.com \
--cc=eric.dumazet@gmail.com \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=joe@perches.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).