On 02/18/2013 05:51 PM, Johannes Berg wrote:
On Mon, 2013-02-18 at 17:07 +0100, Antonio Quartulli wrote:
On Mon, Feb 18, 2013 at 07:58:18 -0800, Johannes Berg wrote:
On Mon, 2013-02-18 at 16:49 +0100, Antonio Quartulli wrote:
On Mon, Feb 18, 2013 at 07:43:26 -0800, Johannes Berg wrote:
I did not like this approach because the sta_info struct is so big that
when we want to fill the stats substruct only we will waste a lot of bytes.
I don't understand your point.
struct sta_info {
...
struct stats stats;
};
My concern is about those "..." that we are allocating within the sta_info struct
that we will never use for every non-peer station.
While if we used the struct below (with its own hash table), we would allocate
only the space needed for the stats.
struct stats_entry {
struct hash/list/whatever;
struct stats stats;
};
no?
Maybe I misunderstood your idea?
But I'm not saying that these are mutually exclusive, I'm saying both
should exist.
Ah ok..Sorry, but I did not take this as an option :)
So, if I understood correctly, this means one table lookup for peer stations,
while two table lookups for non peers (first in sta_hash, which will fail). Right?
This would save one look up for each peer, since we have to do perform one of
them anyway (now I fully understood your previous statement!).
Right... But the failing sta lookup has to happen anyway, so it really
adds practically no cost in the peer case, and a singe lookup in the
"non-peer already exists" case.
IMHO, this is the most efficient implementation for most practical use
cases, where 'peer' traffic accounts more the majority of the traffic.
Hence it should be in the 'fast path', while the extra lookup for 'non
peer' traffic should be tolerable.
My five cents,
Mathias
johannes
--
Fraunhofer FOKUS - RESourCe Optimised Networks
Dr. Mathias Kretschmer
Schloss Birlinghoven; D-53754 Sankt Augustin
T +49-2241-14-3466, F +49-2241-14-1050,
E mathias.kretschmer@xxxxxxxxxxxxxxxxxxx
http://www.fokus.fraunhofer.de/en/rescon
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
