On Wed, 04 Oct 2006 00:07:22 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Ben Woodard <[EMAIL PROTECTED]>
> Date: Tue, 03 Oct 2006 11:14:38 -0700
>
> > > Other issues:
> > >
> > > 1) 2 "u32" in the tcp_sock is a lot of space to devote to this
> > > new state. If it can fit in 2 "u16"'s or even less space,
> > > please use that.
> > >
> > > 2) the expression "(tp->foo ? : sysctl_foo)" is repeated many times
> > > in the patch, please encapsulate it into an inline function
> > > or similar
> > >
> >
> > How does this look to you for answering your two complaints above.
>
> It looks a lot better. I'd like you to take #2 further,
> put the inline function into net/tcp.h and use it in the
> tcp.c instances too.
>
> Also, please don't format code like this:
>
> +static inline __u16 rto_max(struct tcp_sock *tp){
> + return tp->rto_max ? : sysctl_tcp_rto_max;
> +}
> +
> +static inline __u16 rto_init(struct tcp_sock *tp){
> + return tp->rto_init ? : sysctl_tcp_rto_init;
> +}
>
> The openning brace of each functions belongs on a line by itself,
> thanks.
>
> Finally, I'm not so sure "seconds" is the best unit for the
> socket option. In fact you use "seconds" as the unit for
> the socket option and the sysctl is raw jiffies. That's
> inconsistency is really problematic.
>
> At the very least, seconds might not be fine enough granularity
> for some circumstances. Heck, the default RTO_MIN is 1/5 of a
> second. :-)
>
> I also understand that going to milliseconds or microseconds would
> make the size of the in-socket struct members an issue again. These
> things are never easy are they? :-/
>
> Any better ideas?
If you are willing to do a little more work, the sysctl value can be
in milliseconds, and the internal socket member in some other unit
like jiffies. It does require writing your own in/out translation
instead of using proc_dointvec
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html