[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bc46ffdc-e3c4-93be-39ab-76c2634f2c6e@gmail.com>
Date: Fri, 30 Mar 2018 06:30:42 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Herbert Xu <herbert@...dor.apana.org.au>,
Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>, Florian Westphal <fw@...len.de>,
Thomas Graf <tgraf@...g.ch>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Alexander Aring <alex.aring@...il.com>,
Stefan Schmidt <stefan@....samsung.com>,
Eric Dumazet <eric.dumazet@...il.com>,
Nikolay Aleksandrov <nikolay@...hat.com>
Subject: Re: [PATCH net-next 4/6] inet: frags: use rhashtables for reassembly
units
On 03/30/2018 12:18 AM, Herbert Xu wrote:
> Instead of using the walk interface, how about
> rhashtable_free_and_destroy?
Oh, I was not aware of this beast ;)
I guess I will need to add a cond_resched() in it, right ?
My rough guess is that freeing 30 million frags would take few seconds ;)
>
>> void inet_frag_kill(struct inet_frag_queue *fq)
>> {
>> if (del_timer(&fq->timer))
>> refcount_dec(&fq->refcnt);
>>
>> if (!(fq->flags & INET_FRAG_COMPLETE)) {
>> - fq_unlink(fq);
>> + struct netns_frags *nf = fq->net;
>> +
>> + fq->flags |= INET_FRAG_COMPLETE;
>> + rhashtable_remove_fast(&nf->rhashtable, &fq->node, nf->f->rhash_params);
>> refcount_dec(&fq->refcnt);
>> }
>> }
>
> This means that the hash won't inline properly. Don't know big
> of an issue it is to you. But you could fix it by doing the same
> hack as rhashtable by making inet_frag_kill an inline function and
> take the rhash_params as an explicit argument.
I will investigate this, thanks !
Powered by blists - more mailing lists