On Fri, Aug 05, 2016 at 04:46:43AM -0700, Ben Greear wrote:
>
> It would not be fun to have to revert to the old way of hashing
> stations in mac80211...
>
> I'll be happy to test the patches when you have them ready.
Thanks for the offer. Unfortunately it'll be a few days before
I'm ready
On 08/05/2016 03:50 AM, Johannes Berg wrote:
On Fri, 2016-08-05 at 18:48 +0800, Herbert Xu wrote:
On Fri, Aug 05, 2016 at 08:16:53AM +0200, Johannes Berg wrote:
Hm. Would you rather allocate a separate head entry for the
hashtable,
or chain the entries?
My plan is to build support for
On Fri, 2016-08-05 at 18:48 +0800, Herbert Xu wrote:
> On Fri, Aug 05, 2016 at 08:16:53AM +0200, Johannes Berg wrote:
> >
> > Hm. Would you rather allocate a separate head entry for the
> > hashtable,
> > or chain the entries?
>
> My plan is to build support for this directly into rhashtable.
>
On Fri, Aug 05, 2016 at 08:16:53AM +0200, Johannes Berg wrote:
>
> Hm. Would you rather allocate a separate head entry for the hashtable,
> or chain the entries?
My plan is to build support for this directly into rhashtable.
So I'm adding a struct rhlist_head that would be used in place
of
> So I'm going to fix this by consolidating identical objects into
> a single rhashtable entry which also lets us get rid of the
> insecure_elasticity setting.
Hm. Would you rather allocate a separate head entry for the hashtable,
or chain the entries?
(Luckily) the colliding key case
Hi:
While working on rhashtable I noticed that wireless is walking
rhashtables by hand using rht_for_each_*. You must not do that
as an rhashtable can entail multiple hash tables when resizing.
If you walk it by hand then you may end up missing entries.
The correct way to do it is to use the
On Thu, Aug 04, 2016 at 03:18:46PM +0800, Herbert Xu wrote:
>
> So the question is can wireless handle seeing an entry multiple
> times? In particular, __ieee80211_rx_handle_packet would appear
> to process the same packet multiple times if this were to happen.
It's worse than I thought. In
