[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20131003.184549.1239745820432209741.davem@davemloft.net>
Date: Thu, 03 Oct 2013 18:45:49 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: eric.dumazet@...il.com
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net-next] tcp/dccp: remove twchain
From: Eric Dumazet <eric.dumazet@...il.com>
Date: Thu, 03 Oct 2013 14:58:11 -0700
> On Thu, 2013-10-03 at 17:51 -0400, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@...il.com>
>> Date: Thu, 03 Oct 2013 00:22:02 -0700
>>
>> > Current inet_ehash_bucket contains two chains, one for ESTABLISH (and
>> > friend states) sockets, another for TIME_WAIT sockets only.
>> >
>> > As the hash table is sized to get at most one socket per bucket, it
>> > makes little sense to have separate twchain, as it makes the lookup
>> > slightly more complicated, and doubles hash table memory usage.
>>
>> The idea was that long standing time-wait sockets should be forced to
>> provably never appear in same hash chains and thus cause interference
>> with lookups on established sockets.
>>
>> On the other hand, moving sockets between these two tables has a
>> non-trivial cost, and synchronization complexity.
>>
>> So perhaps your change gives the right tradeoff.
>>
>> Eric this patch needs to be respun against current net-next
>> in order for it to apply cleanly, please do that and I'll add
>> it.
>
> I think the main problem comes from this commit in net tree ?
...
> net: do not call sock_put() on TIMEWAIT sockets
...
> I think you could safely ignore the warnings
> because of (tcp: shrink tcp6_timewait_sock by one cache line) latest changes
>
> patching file include/net/inet_timewait_sock.h
> Hunk #1 succeeded at 141 (offset 5 lines).
> Hunk #2 succeeded at 180 (offset 5 lines).
>
> Please tell me if I need to resend, thanks
Oh that's right, I even read about it in your original patch email.
I'll take care of it, thanks.
--
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