[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EAB2F58.7080509@hp.com>
Date: Fri, 28 Oct 2011 15:40:24 -0700
From: Rick Jones <rick.jones2@...com>
To: David Miller <davem@...emloft.net>
CC: dbaluta@...acom.com, eric.dumazet@...il.com, kuznet@....inr.ac.ru,
jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net,
netdev@...r.kernel.org, luto@...capital.net
Subject: Re: [RFC v2] tcp: Export TCP Delayed ACK parameters to user
On 10/28/2011 03:31 PM, David Miller wrote:
> From: Daniel Baluta<dbaluta@...acom.com>
> Date: Sat, 29 Oct 2011 00:35:24 +0300
>
>> On Sat, Oct 29, 2011 at 12:19 AM, David Miller<davem@...emloft.net> wrote:
>>> From: Daniel Baluta<dbaluta@...acom.com>
>>> Date: Sat, 29 Oct 2011 00:14:03 +0300
>>>
>>>> +static inline int tcp_delack_thresh(const struct sock *sk)
>>>> +{
>>>> + return inet_csk(sk)->icsk_ack.rcv_mss * sysctl_tcp_delack_segs;
>>>> +}
>>>> +
>>>
>>> Please turn this into a shift or something, you're adding a multiply
>>> into a core code path.
>>
>> Is there any generic API to do this? Default case is not
>> affected since tcp_delack_segs is 1.
>
> I'm saying make the tunable a shift count instead of something to
> multiply against.
That would be loads faster, but won't that have issues with granularity?
It will allow 1, 2, 4, 8, 16, 32, etc segments but none of the umpteen
values in between. FWIW, HP-UX defaults to 22 segments, which IIRC has
its basis in how many "typical" segments could fit in a 32KB window.
If the mss and the delack segs are being converted into an octet count,
and multiplication or successive addition etc are too expensive, how
about using an octet count directly?
rick jones
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists