netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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?


  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).