From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH v2 net-next 08/12] inet: frags: use rhashtables for
 reassembly units
Date: Fri, 30 Mar 2018 15:54:48 -0700
Message-ID: <6677a301-eacb-8dc3-f780-d59306c9e421@gmail.com>
References: <20180330204236.43675-1-edumazet@google.com>
 <20180330204236.43675-9-edumazet@google.com>
 <3a8d2f22-600c-7389-96f4-f84ca466e647@virtuozzo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: netdev <netdev@vger.kernel.org>, Florian Westphal <fw@strlen.de>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Thomas Graf <tgraf@suug.ch>,
        Jesper Dangaard Brouer <brouer@redhat.com>,
        Alexander Aring <alex.aring@gmail.com>,
        Stefan Schmidt <stefan@osg.samsung.com>,
        Eric Dumazet <eric.dumazet@gmail.com>,
        Nikolay Aleksandrov <nikolay@redhat.com>
To: Kirill Tkhai <ktkhai@virtuozzo.com>,
        Eric Dumazet <edumazet@google.com>,
        "David S . Miller" <davem@davemloft.net>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pg0-f51.google.com ([74.125.83.51]:41578 "EHLO
        mail-pg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752357AbeC3Wyu (ORCPT
        <rfc822;netdev@vger.kernel.org>); Fri, 30 Mar 2018 18:54:50 -0400
Received: by mail-pg0-f51.google.com with SMTP id t10so5808692pgv.8
        for <netdev@vger.kernel.org>; Fri, 30 Mar 2018 15:54:50 -0700 (PDT)
In-Reply-To: <3a8d2f22-600c-7389-96f4-f84ca466e647@virtuozzo.com>
Content-Language: en-US
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>



On 03/30/2018 03:44 PM, Kirill Tkhai wrote:
> Hi, Eric,
> 
> thanks for more small patches in v2. One comment below.
> 

>> -
>> -struct inet_frag_bucket {
>> -	struct hlist_head	chain;
>> -	spinlock_t		chain_lock;
>> +	struct netns_frags      *net;
>> +	struct rcu_head		rcu;
> 
> inet_frag_destroy() calls call_rcu() after frags are destroyed.
> It looks like we may place this rcu in union with fragments and
> fragments_tail and to sa

No, because I am planning to free skbs in the rcu call back very shortly.

As I mentioned, I believe we could use pure RCU lookups, without grabing a
reference and then release it after packet is processed/added to the queue.

This is not urgent, I wanted to get the first patches for review before doing
this final step, as I do not expect more than 5 % improvement from this optimization.

Also note that the ipq structure is 192 bytes, nicely using 3 cache lines.

Trying to save 16 bytes will likely reduce performance,  unless we force padding
to reach 192 bytes again :)