Re: [net-next PATCH v4 2/3] net: TCP thin linear timeouts

[Ilpo Järvinen]

On Thu, 18 Feb 2010, Franco Fichtner wrote:

> Andreas Petlund wrote:
> > On 02/18/2010 09:41 AM, Ilpo Järvinen wrote:
> >   
> > > On Wed, 17 Feb 2010, David Miller wrote:
> > > 
> > >     
> > > > From: Andreas Petlund <apetlund@xxxxxxxxx>
> > > > Date: Tue, 16 Feb 2010 15:40:41 +0100
> > > > 
> > > >       
> > > > > @@ -341,6 +342,8 @@ struct tcp_sock {
> > > > >  	u16	advmss;		/* Advertised MSS
> > > > > */
> > > > >  	u8	frto_counter;	/* Number of new acks after RTO */
> > > > >  	u8	nonagle;	/* Disable Nagle algorithm?
> > > > > */
> > > > > +	u8      thin_lto    : 1,/* Use linear timeouts for thin
> > > > > streams */
> > > > > +		thin_undef  : 7;
> > > > >          
> > > > There is now a gap of 3 unused bytes here in this critical
> > > > core TCP socket data structure.
> > > > 
> > > > Please either find a way to avoid this hole, or document
> > > > it with a comment.
> > > >       
> > > There would be multiple bits free for use in both frto_counter and nonagle
> > > byte.
> > > 
> > >     
> > 
> > I was playing aroud with this setup:
> > 
> > =========
> > u8	nonagle     : 4,/* Disable Nagle algorithm?             */
> > 	thin_lto    : 1,/* Use linear timeouts for thin streams */
> > 	thin_dupack : 1,/* Fast retransmit on first dupack      */
> > 	thin_undef  : 2;
> > =========
> > 
> > Do you think that would do the trick?
> >   
> 
> According to Ilpo, it would be ok to reduce both ftro_counter and
> nonagle, so why not join all these into u16 and leave the remaining
> free bits documented for other people. Like this:
> 
>    u16 frto_counter:x; /* Number of new acks after RTO */
>    u16 nonagle:y; /* Disable Nagle algorithm? */
>    u16 thin_lto:1; /* Use linear timeouts for thin streams */
>    u16 unused:15-x-y;
> 
> Not sure about the y and x. Ilpo, can you comment on those values?

I don't remember top of the hat how much of nonagle used, but for 
frto_counter max value was 3 iirc. However, I'm unsure if compiler is 
nowadays wise enough to handle bitfields in some not all so stupid way. 
Btw, also in ecn_flags we have some empty space. But all in all that 
didn't vacate enough to get 4 bytes so I haven't taken effort of 
combining.

-- 
 i.