From: Oleksij Rempel <linux@rempel-privat.de>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH 05/13] ath9k_htc: add rx header converter to make it usable by ath9k
Date: Mon, 03 Feb 2014 14:11:48 +0100 [thread overview]
Message-ID: <52EF9594.40303@rempel-privat.de> (raw)
In-Reply-To: <52EF8699.2000305@openwrt.org>
Am 03.02.2014 13:07, schrieb Felix Fietkau:
> On 2014-02-03 12:22, Oleksij Rempel wrote:
>> Am 03.02.2014 03:09, schrieb Sujith Manoharan:
>>> Oleksij Rempel wrote:
>>>> + rx_stats = kzalloc(sizeof(struct ath_rx_status), GFP_KERNEL);
>>>> + if (unlikely(rx_stats == NULL)) {
>>>> + ath_err(common, "rx_stats allocation filed!\n");
>>>> + goto err_nofree;
>>>> + }
>>>> + rx_status_htc_to_ath(rx_stats, &rxbuf->rxstatus);
>>>> +
>>
>>> This seems a little expensive, since this would happen for every packet,
>>> and a memcpy is already done earlier, for storing the RX status in
>>> rxbuf->rxstatus. Instead of using 'struct ath_htc_rx_status' in
>>> 'struct ath9k_htc_rxbuf', why can't 'struct ath_rx_status' be used ?
>>> The values can be converted and stored directly, avoiding this alloc.
>>
>> Do you mean kzalloc or converter?
>> then memcpy is removed by patch 12/13. Converter is not effective but it
>> should prevent from confusions. At least until FW use same flags and
>> struct ath_rx_status do.
>> But i'm open for other ideas too.
> You should at least keep rx_stats on stack instead of using kzalloc,
> that would make it much faster.
You right, i'll do it.
Beside what is the smallest stack size in kernel i need to count on?
--
Regards,
Oleksij
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 278 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140203/8408640e/attachment.pgp
WARNING: multiple messages have this Message-ID (diff)
From: Oleksij Rempel <linux@rempel-privat.de>
To: Felix Fietkau <nbd@openwrt.org>, Sujith Manoharan <sujith@msujith.org>
Cc: ath9k-devel@lists.ath9k.org, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH 05/13] ath9k_htc: add rx header converter to make it usable by ath9k
Date: Mon, 03 Feb 2014 14:11:48 +0100 [thread overview]
Message-ID: <52EF9594.40303@rempel-privat.de> (raw)
In-Reply-To: <52EF8699.2000305@openwrt.org>
[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]
Am 03.02.2014 13:07, schrieb Felix Fietkau:
> On 2014-02-03 12:22, Oleksij Rempel wrote:
>> Am 03.02.2014 03:09, schrieb Sujith Manoharan:
>>> Oleksij Rempel wrote:
>>>> + rx_stats = kzalloc(sizeof(struct ath_rx_status), GFP_KERNEL);
>>>> + if (unlikely(rx_stats == NULL)) {
>>>> + ath_err(common, "rx_stats allocation filed!\n");
>>>> + goto err_nofree;
>>>> + }
>>>> + rx_status_htc_to_ath(rx_stats, &rxbuf->rxstatus);
>>>> +
>>
>>> This seems a little expensive, since this would happen for every packet,
>>> and a memcpy is already done earlier, for storing the RX status in
>>> rxbuf->rxstatus. Instead of using 'struct ath_htc_rx_status' in
>>> 'struct ath9k_htc_rxbuf', why can't 'struct ath_rx_status' be used ?
>>> The values can be converted and stored directly, avoiding this alloc.
>>
>> Do you mean kzalloc or converter?
>> then memcpy is removed by patch 12/13. Converter is not effective but it
>> should prevent from confusions. At least until FW use same flags and
>> struct ath_rx_status do.
>> But i'm open for other ideas too.
> You should at least keep rx_stats on stack instead of using kzalloc,
> that would make it much faster.
You right, i'll do it.
Beside what is the smallest stack size in kernel i need to count on?
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 278 bytes --]
next prev parent reply other threads:[~2014-02-03 13:11 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-29 19:05 [ath9k-devel] [PATCH 00/13] eliminate some ath9k_htc code Oleksij Rempel
2014-01-29 19:05 ` Oleksij Rempel
2014-01-29 19:05 ` [ath9k-devel] [PATCH 01/13] ath: add last_rssi to ath_common Oleksij Rempel
2014-01-29 19:05 ` Oleksij Rempel
2014-01-29 19:06 ` [ath9k-devel] [PATCH 02/13] ath9k: move ath9k_process_rssi to common.c Oleksij Rempel
2014-01-29 19:06 ` Oleksij Rempel
2014-01-29 19:06 ` [ath9k-devel] [PATCH 03/13] ath9k: move ath9k_process_rate " Oleksij Rempel
2014-01-29 19:06 ` Oleksij Rempel
2014-01-29 19:06 ` [ath9k-devel] [PATCH 04/13] ath9k: move ath9k_rx_accept " Oleksij Rempel
2014-01-29 19:06 ` Oleksij Rempel
2014-01-29 19:06 ` [ath9k-devel] [PATCH 05/13] ath9k_htc: add rx header converter to make it usable by ath9k Oleksij Rempel
2014-01-29 19:06 ` Oleksij Rempel
2014-02-03 2:09 ` [ath9k-devel] " Sujith Manoharan
2014-02-03 2:09 ` Sujith Manoharan
2014-02-03 11:22 ` [ath9k-devel] " Oleksij Rempel
2014-02-03 11:22 ` Oleksij Rempel
2014-02-03 12:07 ` [ath9k-devel] " Felix Fietkau
2014-02-03 12:07 ` Felix Fietkau
2014-02-03 13:11 ` Oleksij Rempel [this message]
2014-02-03 13:11 ` Oleksij Rempel
2014-01-29 19:06 ` [ath9k-devel] [PATCH 06/13] ath9k_htc: use ath9k_cmn_process_rssi Oleksij Rempel
2014-01-29 19:06 ` Oleksij Rempel
2014-01-29 19:06 ` [ath9k-devel] [PATCH 07/13] ath9k_htc: use ath9k_cmn_process_rate Oleksij Rempel
2014-01-29 19:06 ` Oleksij Rempel
2014-01-29 19:06 ` [ath9k-devel] [PATCH 08/13] ath9k_htc: use ath9k_cmn_rx_accept Oleksij Rempel
2014-01-29 19:06 ` Oleksij Rempel
2014-01-29 19:07 ` [ath9k-devel] [PATCH 09/13] ath9k_htc: sync rx_status-> related code with ath9k Oleksij Rempel
2014-01-29 19:07 ` Oleksij Rempel
2014-01-29 19:07 ` [ath9k-devel] [PATCH 10/13] ath9k: move ath9k_rx_skb_postprocess to common.c Oleksij Rempel
2014-01-29 19:07 ` Oleksij Rempel
2014-01-29 19:07 ` [ath9k-devel] [PATCH 11/13] ath9k_htc: use ath9k_cmn_rx_skb_postprocess Oleksij Rempel
2014-01-29 19:07 ` Oleksij Rempel
2014-01-29 19:07 ` [ath9k-devel] [PATCH 12/13] ath9k_htc: remove useless memcpy Oleksij Rempel
2014-01-29 19:07 ` Oleksij Rempel
2014-01-29 19:07 ` [ath9k-devel] [PATCH 13/13] ath9k_htc: catch fw panic pattern Oleksij Rempel
2014-01-29 19:07 ` Oleksij Rempel
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=52EF9594.40303@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.