linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ivo van Doorn <ivdoorn@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
	Chr <chunkeey@web.de>, Michael Wu <flamingice@sourmilk.net>,
	Daniel Drake <dsd@gentoo.org>,
	Andrea Merello <andreamrl@tiscali.it>
Subject: Re: putting ieee80211_tx_control into skb->cb?
Date: Wed, 30 Apr 2008 19:04:02 +0200	[thread overview]
Message-ID: <200804301904.03670.IvDoorn@gmail.com> (raw)
In-Reply-To: <1209570457.18659.59.camel@johannes.berg>

On Wednesday 30 April 2008, Johannes Berg wrote:
> With my patch to shrink ieee80211_tx_control, I can now put that into
> skb->cb.
> 
> Do we want to use that as the interface to drivers as well? Many drivers
> could benefit from that a lot since we could save all the extra copies
> done here.
> 
> I've grepped all drivers, currently those using skb->cb are:
>  * p54:     only needs 8 bytes
>  * rt2x00:  needs almost all the space (40 bytes)

Latest rt2x00.git needs _all_ space (48 bytes)
However I can trim it down to 40 bytes quite easily,
since mac80211 wasn't using it anyway I wasn't too conservative
about the usage. ;)
I could even trim it down further if I disable the TX/RX dumping
through debugfs as intermediate solution.

>  * adm8211: puts the 802.11 header there
>  * rtl8180: needs a single pointer to control
>  * rtl8187: usb urb, control and hw pointers
>  * zd1211:  control, hw and context pointers
> 
> Notice how four drivers here put the control information in there, which
> needs to be copied by drivers. However, mac80211 only needs the control
> flags later!

Very nice, removing the requirement to store the entire control data would
save a lot of memory for rt2x00. (Currently it has a per-entry copy of the
tx control data).

> First, we put ieee80211_tx_control into skb->cb. The first member of
> that is a 'u32 flags' which is the only thing we need later for TX
> status reporting, so we require that drivers leave that in there.
> 
> Then, we merge the TX status flags into the TX flags so that now the
> driver only needs to set a few flags in skb->cb. Also, we overlay this.
> 
> Hence, we have something like the following structure:
> 
> struct ieee80211_tx_information {
>     u32 flags;
> 
>     union {
>         struct {
>             s8 tx_rate_idx, rts_cts_rate_idx,
>                alt_retry_rate_idx, retry_limit;
>             struct ieee80211_vif *vif;
>             struct ieee80211_key_conf *hw_key;
>             enum ieee80211_band band;
>             u16 aid;
>             u8 antenna_sel_tx;
>             u8 icv_len, iv_len;
>         } txctl;
> 
>         struct {
>             u64 amdpu_ack_map;
>             int ack_signal;
>             u8 ampdu_ack_len;
>             bool excessive_retries; /* should be a flag / removed */
>             u8 retry_count;
>         } status;
> 
>         /* can be used freely by driver after its ops->tx() accepts
>          * the frame and before tx status reporting */
>         u8 drv_data[40] __attribute__((__aligned__(sizeof(void *)));
>     };
> };
> 
> This means that the drivers are free to use everything in skb->cb for
> their own use but should leave the 'u32 flags' intact, and need to make
> sure to copy out all the information they need before putting in new
> information. This fits with all the drivers, rt2x00 needs at most 32
> bytes (40 now, but one is the txcontrol pointer) while we have 44 free.
> Also, if the driver rejects the skb in ops->tx(), it must not have
> modified skb->cb.

For rt2x00 that won't be a problem, it won't touch the skb->cb anyway
until it has performed all checks for queue entry availability.

> The only thing I'm not sure yet is how to handle alignment here. skb->cb
> itself is 8-byte aligned so we probably need to reserve another four
> bytes to get things to 8-byte alignment and then we go down to 40
> available bytes, this is what I did above.

Ivo

  reply	other threads:[~2008-04-30 17:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-30 15:47 putting ieee80211_tx_control into skb->cb? Johannes Berg
2008-04-30 17:04 ` Ivo van Doorn [this message]
2008-04-30 20:10   ` Johannes Berg
2008-05-01  0:34 ` Johannes Berg

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=200804301904.03670.IvDoorn@gmail.com \
    --to=ivdoorn@gmail.com \
    --cc=andreamrl@tiscali.it \
    --cc=chunkeey@web.de \
    --cc=dsd@gentoo.org \
    --cc=flamingice@sourmilk.net \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).