[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1340082688.7491.2299.camel@edumazet-glaptop>
Date: Tue, 19 Jun 2012 07:11:28 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: greearb@...delatech.com
Cc: netdev@...r.kernel.org, Daniel Baluta <dbaluta@...acom.com>
Subject: Re: [RFC] TCP: Support configurable delayed-ack parameters.
On Mon, 2012-06-18 at 17:52 -0700, greearb@...delatech.com wrote:
> From: Ben Greear <greearb@...delatech.com>
>
> RFC2581 ($4.2) specifies when an ACK should be generated as follows:
>
> " .. an ACK SHOULD be generated for at least every second
> full-sized segment, and MUST be generated within 500 ms
> of the arrival of the first unacknowledged packet.
> "
>
> We export the number of segments and the timeout limits
> specified above, so that a user can tune them according
> to their needs.
>
> Specifically:
> * /proc/sys/net/ipv4/tcp_default_delack_segs, represents
> the threshold for the number of segments.
> * /proc/sys/net/ipv4/tcp_default_delack_min, specifies
> the minimum timeout value
> * /proc/sys/net/ipv4/tcp_default_delack_max, specifies
> the maximum timeout value.
>
> In addition, new TCP socket options are added to allow
> per-socket configuration:
>
> TCP_DELACK_SEGS
> TCP_DELACK_MIN
> TCP_DELACK_MAX
>
> In order to keep a multiply out of the hot path, the segs * mss
> computation is recalculated and cached whenever segs or mss changes.
>
I know David was worried about this multiply, but current cpus do a
multiply in at most 3 cycles.
Addding an u32 field in socket structure adds 1/16 of a cache line, and
adds more penalty.
Avoiding to build/send an ACK packet can save us so many cpu cycles that
the multiply is pure noise.
--
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