netdev - Re: [PATCH] allow to configure tcp_retries1 and tcp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87bpbi4ycc.fsf@basil.nowhere.org>
Date:	Thu, 10 Jun 2010 19:00:19 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Salvador Fandino <salvador@...del.com>
Cc:	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	linux-kernel@...stfloor.org, "@vger.kernel.org"@firstfloor.org
Subject: Re: [PATCH] allow to configure tcp_retries1 and tcp_retries2 per TCP socket

Salvador Fandino <salvador@...del.com> writes:


> The included patch adds support for setting the tcp_retries1 and
> tcp_retries2 options in a per socket fashion as it is done for the
> keepalive options TCP_KEEPIDLE, TCP_KEEPCNT and TCP_KEEPINTVL.
>
> The issue I am trying to solve is that when a socket has data queued for
> delivering, the keepalive logic is not triggered. Instead, the
> tcp_retries1/2 parameters are used to determine how many delivering
> attempts should be performed before giving up.

And why exactly do you need new tunables to solve this?

>
> The patch is very straight forward and just replicates similar
> functionality. There is one thing I am not completely sure and is if the
> new per-socket fields should go into inet_connection_sock instead of
> into tcp_sock.

tcp_sock is already quite big (>2k on 64bit) 

IMHO any new fields in there need very good justification.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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