From: Oleksij Rempel <linux@rempel-privat.de>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH 0/11] use ether_addr_equal_64bits
Date: Fri, 17 Jan 2014 23:02:06 +0100 [thread overview]
Message-ID: <52D9A85E.8070306@rempel-privat.de> (raw)
In-Reply-To: <20140117212410.GA13930@amd.pavel.ucw.cz>
Am 17.01.2014 22:24, schrieb Pavel Machek:
> On Mon 2013-12-30 19:14:56, Julia Lawall wrote:
>> Ether_addr_equal_64bits is more efficient than ether_addr_equal, and can be
>> used when each argument is an array within a structure that contains at
>> least two bytes of data beyond the array.
>
> I mean, yes, it is probably faster, and yes, most structures probably
> contain two more bytes, but... is the uglyness worth the speedup? I'd
> say this should not be done except in very time-critical places...
> Pavel
This code run on every received beacon, almost on every wifi driver (If
i understand what you mean.)
--
Regards,
Oleksij
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140117/a291f46a/attachment.pgp
WARNING: multiple messages have this Message-ID (diff)
From: Oleksij Rempel <linux@rempel-privat.de>
To: Pavel Machek <pavel@ucw.cz>, Julia Lawall <Julia.Lawall@lip6.fr>
Cc: ath9k-devel@lists.ath9k.org, kernel-janitors@vger.kernel.org,
ath5k-devel@lists.ath5k.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
"John W. Linville" <linville@tuxdriver.com>,
users@rt2x00.serialmonkey.com
Subject: Re: [PATCH 0/11] use ether_addr_equal_64bits
Date: Fri, 17 Jan 2014 22:02:06 +0000 [thread overview]
Message-ID: <52D9A85E.8070306@rempel-privat.de> (raw)
In-Reply-To: <20140117212410.GA13930@amd.pavel.ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]
Am 17.01.2014 22:24, schrieb Pavel Machek:
> On Mon 2013-12-30 19:14:56, Julia Lawall wrote:
>> Ether_addr_equal_64bits is more efficient than ether_addr_equal, and can be
>> used when each argument is an array within a structure that contains at
>> least two bytes of data beyond the array.
>
> I mean, yes, it is probably faster, and yes, most structures probably
> contain two more bytes, but... is the uglyness worth the speedup? I'd
> say this should not be done except in very time-critical places...
> Pavel
This code run on every received beacon, almost on every wifi driver (If
i understand what you mean.)
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Oleksij Rempel <linux@rempel-privat.de>
To: Pavel Machek <pavel@ucw.cz>, Julia Lawall <Julia.Lawall@lip6.fr>
Cc: ath9k-devel@lists.ath9k.org, kernel-janitors@vger.kernel.org,
ath5k-devel@lists.ath5k.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
"John W. Linville" <linville@tuxdriver.com>,
users@rt2x00.serialmonkey.com
Subject: Re: [PATCH 0/11] use ether_addr_equal_64bits
Date: Fri, 17 Jan 2014 23:02:06 +0100 [thread overview]
Message-ID: <52D9A85E.8070306@rempel-privat.de> (raw)
In-Reply-To: <20140117212410.GA13930@amd.pavel.ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]
Am 17.01.2014 22:24, schrieb Pavel Machek:
> On Mon 2013-12-30 19:14:56, Julia Lawall wrote:
>> Ether_addr_equal_64bits is more efficient than ether_addr_equal, and can be
>> used when each argument is an array within a structure that contains at
>> least two bytes of data beyond the array.
>
> I mean, yes, it is probably faster, and yes, most structures probably
> contain two more bytes, but... is the uglyness worth the speedup? I'd
> say this should not be done except in very time-critical places...
> Pavel
This code run on every received beacon, almost on every wifi driver (If
i understand what you mean.)
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Oleksij Rempel <linux@rempel-privat.de>
To: Pavel Machek <pavel@ucw.cz>, Julia Lawall <Julia.Lawall@lip6.fr>
Cc: ath9k-devel@venema.h4ckr.net, kernel-janitors@vger.kernel.org,
ath5k-devel@venema.h4ckr.net, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
"John W. Linville" <linville@tuxdriver.com>,
users@rt2x00.serialmonkey.com
Subject: Re: [PATCH 0/11] use ether_addr_equal_64bits
Date: Fri, 17 Jan 2014 23:02:06 +0100 [thread overview]
Message-ID: <52D9A85E.8070306@rempel-privat.de> (raw)
In-Reply-To: <20140117212410.GA13930@amd.pavel.ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]
Am 17.01.2014 22:24, schrieb Pavel Machek:
> On Mon 2013-12-30 19:14:56, Julia Lawall wrote:
>> Ether_addr_equal_64bits is more efficient than ether_addr_equal, and can be
>> used when each argument is an array within a structure that contains at
>> least two bytes of data beyond the array.
>
> I mean, yes, it is probably faster, and yes, most structures probably
> contain two more bytes, but... is the uglyness worth the speedup? I'd
> say this should not be done except in very time-critical places...
> Pavel
This code run on every received beacon, almost on every wifi driver (If
i understand what you mean.)
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]
next prev parent reply other threads:[~2014-01-17 22:02 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-30 17:24 [PATCH 0/11] use ether_addr_equal_64bits Julia Lawall
2013-12-30 18:14 ` Julia Lawall
2013-12-30 18:14 ` Julia Lawall
2013-12-30 18:14 ` [ath9k-devel] " Julia Lawall
2013-12-30 17:22 ` [PATCH 2/11] ath5k: " Julia Lawall
2013-12-30 18:14 ` Julia Lawall
2013-12-30 18:14 ` Julia Lawall
2013-12-30 17:22 ` [PATCH 8/11] " Julia Lawall
2013-12-30 18:15 ` Julia Lawall
2013-12-30 18:15 ` Julia Lawall
2013-12-30 18:15 ` [ath9k-devel] " Julia Lawall
2013-12-30 17:22 ` [PATCH 7/11] iwlegacy: " Julia Lawall
2013-12-30 18:15 ` Julia Lawall
2013-12-30 17:22 ` [PATCH 6/11] rtlwifi: " Julia Lawall
2013-12-30 18:15 ` Julia Lawall
2013-12-30 21:08 ` Larry Finger
2013-12-30 21:08 ` Larry Finger
2013-12-30 17:23 ` [PATCH 5/11] mwl8k: " Julia Lawall
2013-12-30 18:15 ` Julia Lawall
2013-12-30 17:23 ` [PATCH 4/11] " Julia Lawall
2013-12-30 18:15 ` Julia Lawall
2013-12-30 18:56 ` Johannes Berg
2013-12-30 18:56 ` Johannes Berg
2013-12-30 19:58 ` Julia Lawall
2013-12-30 19:58 ` Julia Lawall
2013-12-30 21:25 ` Johannes Berg
2013-12-30 21:25 ` Johannes Berg
2013-12-30 21:57 ` Henrique de Moraes Holschuh
2013-12-30 21:57 ` Henrique de Moraes Holschuh
2013-12-30 23:13 ` Johannes Berg
2013-12-30 23:13 ` Johannes Berg
2013-12-30 23:13 ` Johannes Berg
2013-12-30 23:17 ` Joe Perches
2013-12-30 23:17 ` Joe Perches
2013-12-31 6:32 ` Julia Lawall
2013-12-31 6:32 ` Julia Lawall
2013-12-31 15:54 ` Ben Greear
2013-12-31 15:54 ` Ben Greear
2013-12-31 15:54 ` Ben Greear
2013-12-31 16:09 ` Julia Lawall
2013-12-31 16:09 ` Julia Lawall
2013-12-31 16:27 ` Ben Greear
2013-12-31 16:27 ` Ben Greear
2013-12-31 16:40 ` Julia Lawall
2013-12-31 16:40 ` Julia Lawall
2014-01-06 9:05 ` Johannes Berg
2014-01-06 9:05 ` Johannes Berg
2014-01-06 9:09 ` Julia Lawall
2014-01-06 9:09 ` Julia Lawall
2014-01-06 9:09 ` Julia Lawall
2014-01-06 10:17 ` Johannes Berg
2014-01-06 10:17 ` Johannes Berg
2014-01-06 8:48 ` Julia Lawall
2014-01-06 8:48 ` Julia Lawall
2014-01-06 8:59 ` Joe Perches
2014-01-06 8:59 ` Joe Perches
2014-01-06 9:04 ` Julia Lawall
2014-01-06 9:04 ` Julia Lawall
2014-01-06 9:07 ` Johannes Berg
2014-01-06 9:07 ` Johannes Berg
2014-01-06 9:20 ` Julia Lawall
2014-01-06 9:20 ` Julia Lawall
2013-12-31 6:26 ` Emmanuel Grumbach
2013-12-31 6:26 ` Emmanuel Grumbach
2014-01-06 9:24 ` Geert Uytterhoeven
2014-01-06 9:24 ` Geert Uytterhoeven
2014-01-06 9:35 ` Julia Lawall
2014-01-06 9:35 ` Julia Lawall
2014-01-06 15:18 ` Eric Dumazet
2014-01-06 15:18 ` Eric Dumazet
2014-01-06 10:48 ` Dan Carpenter
2014-01-06 10:48 ` Dan Carpenter
2014-01-17 10:18 ` Dan Carpenter
2014-01-17 10:18 ` Dan Carpenter
2014-01-17 10:18 ` Dan Carpenter
2013-12-30 17:23 ` [PATCH 3/11] mac80211: " Julia Lawall
2013-12-30 18:14 ` Julia Lawall
2013-12-30 18:10 ` Christian Lamparter
2013-12-30 18:10 ` Christian Lamparter
2013-12-30 17:23 ` [PATCH 9/11] ipw2x00: " Julia Lawall
2013-12-30 18:15 ` Julia Lawall
2013-12-30 17:23 ` [PATCH 10/11] at76c50x-usb: " Julia Lawall
2013-12-30 18:15 ` Julia Lawall
2013-12-30 17:24 ` [PATCH 11/11] carl9170: " Julia Lawall
2013-12-30 18:15 ` Julia Lawall
2013-12-30 18:10 ` Christian Lamparter
2013-12-30 18:10 ` Christian Lamparter
2013-12-30 17:24 ` [PATCH 1/11] rt2x00: " Julia Lawall
2013-12-30 18:14 ` Julia Lawall
2013-12-31 16:44 ` Gertjan van Wingerde
2013-12-31 16:44 ` Gertjan van Wingerde
2014-01-17 21:24 ` [ath9k-devel] [PATCH 0/11] " Pavel Machek
2014-01-17 21:24 ` Pavel Machek
2014-01-17 21:24 ` Pavel Machek
2014-01-17 21:24 ` Pavel Machek
2014-01-17 22:02 ` Oleksij Rempel [this message]
2014-01-17 22:02 ` Oleksij Rempel
2014-01-17 22:02 ` Oleksij Rempel
2014-01-17 22:02 ` Oleksij Rempel
2014-01-17 22:43 ` [ath9k-devel] " Pavel Machek
2014-01-17 22:43 ` Pavel Machek
2014-01-17 22:43 ` Pavel Machek
2014-01-17 22:43 ` Pavel Machek
2014-01-17 22:43 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52D9A85E.8070306@rempel-privat.de \
--to=linux@rempel-privat.de \
--cc=ath9k-devel@lists.ath9k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.