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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.