netdev - Re: [PATCH net-next] tcp: shrink tcp6_timewait

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: <20131003.160252.2071364130742864278.davem@davemloft.net>
Date:	Thu, 03 Oct 2013 16:02:52 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] tcp: shrink tcp6_timewait_sock by one cache
 line

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Thu, 03 Oct 2013 12:47:22 -0700

> On Thu, 2013-10-03 at 15:31 -0400, David Miller wrote:
> 
>> Eric just use tcp_time_stamp in all of these locations, then you can
>> lose the casts and still achieve your stated objective.
> 
> I thought about this, but this would break if tcp_time_stamp was no
> longer tied to jiffies.
> 
> Van Jacobson had the idea of using finer resolution tcp_time_stamp for
> TCP flows in data centers, for better RTT estimation and and cwin
> control, but also for better diagnostics.
> 
> Note we used this (u32)jiffies thing in net/ipv4/inetpeer.c in the past,
> and tp->tso_deferred is also a u32 value.

I am sure that you could define a set of interfaces which are named
such that the intent and usage is clear, would do the u32 cast, and
would be updated by whoever changes the timestamp implementation in
the future.

The cast is really ugly, even if we do it in inetpeer already, and
you're already here cleaning things up, so please do it right.

Thank you.
--
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