From: Florian Westphal <fw@strlen.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Florian Westphal <fw@strlen.de>,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH RFC 08/14] net: wireless: mac80211: shrink ieee80211_tx_info
Date: Mon, 2 Mar 2015 20:03:16 +0100 [thread overview]
Message-ID: <20150302190316.GB9762@breakpoint.cc> (raw)
In-Reply-To: <1425322425.1906.4.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> wrote:
> On Mon, 2015-03-02 at 18:40 +0100, Florian Westphal wrote:
> > to make it fit into (future) 44-byte sized skb->cb[].
> >
> > This works, since flags is only used to store values
> > from mac80211_tx_control_flags enum, and these are just 2 bits.
> > We can thus move this to the padding hole inside the union.
> >
> > Also add BUILD_BUG_ON magic to make sure that the new flags
> > field doesn't share storage w. other members of the union.
>
> This is really ugly - what's the point of this?
Eventually reducing skb size to make it fit into 3 cachelines again even
on 64bit architectures. For that 40 bytes need to go.
> Mind you - we are actually acutely out of space and would rather have
> *more*, not less.
:-(
I'm not familiar with mac80211, aside from that it seemed to me
that 40 byte cb would be doable, given enough work.
Where are to main problems, exactly?
I known that pushing something into ->cb is a lot easier than e.g. keeping
extra state on stack, but, IMO cb should really only be used when you
need to associate data strictly with an skb so that this data is still
availabe even when skb gets queued somewehere.
Is there a document somewhere that lists all of the per-skb data that
mac80211 needs to store (or wants to store)?
Thanks,
Florian
next prev parent reply other threads:[~2015-03-02 19:03 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-02 17:40 [PATCH RFC 00/14] shrink skb cb to 44 bytes Florian Westphal
2015-03-02 17:40 ` [PATCH RFC 01/14] net: gro: shrink napi_gro_cb to fit into hypothetical 44-byte sized skb cb Florian Westphal
2015-03-02 17:40 ` [PATCH RFC 02/14] net: sched: reduce qdisc size to 24 byte Florian Westphal
2015-03-02 17:40 ` [PATCH RFC 03/14] ipv6: use flag instead of u16 for hop in inet6_skb_parm Florian Westphal
2015-03-02 17:40 ` [PATCH RFC 04/14] drivers: wireless: rt2x00: move skb_dma to queue entry Florian Westphal
2015-03-02 17:40 ` [PATCH RFC 05/14] drivers: wireless: ar5523: use container_of Florian Westphal
2015-03-03 9:16 ` Pontus Fuchs
2015-03-02 17:40 ` [PATCH RFC 06/14] drivers: wireless: carl9170: shrink carl9170_tx_info Florian Westphal
2015-03-02 17:40 ` [PATCH RFC 07/14] net: wireless: iwlwifi: shrink status private area Florian Westphal
2015-03-02 17:40 ` [PATCH RFC 08/14] net: wireless: mac80211: shrink ieee80211_tx_info Florian Westphal
[not found] ` <1425318028-26531-9-git-send-email-fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org>
2015-03-02 18:53 ` Johannes Berg
2015-03-02 19:03 ` Florian Westphal [this message]
2015-03-02 19:18 ` Johannes Berg
[not found] ` <1425323929.1906.12.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2015-03-02 19:30 ` Florian Westphal
2015-03-02 17:40 ` [PATCH RFC 09/14] net: wireless: mac80211: shrink private driver area Florian Westphal
2015-03-02 18:52 ` Johannes Berg
2015-03-02 17:40 ` [PATCH RFC 10/14] dccp: keep failed options on stack Florian Westphal
2015-03-02 17:40 ` [PATCH RFC 11/14] dccp: reduce size of dccp_skb_cb to 40 bytes Florian Westphal
2015-03-02 17:40 ` [PATCH RFC 12/14] rxrpc: use 32bit jiffies on 64bit platforms, too Florian Westphal
2015-03-02 17:40 ` [PATCH RFC 13/14] net: tcp: don't assert sock_skb_cb_check_size Florian Westphal
2015-03-02 17:40 ` [PATCH RFC 14/14] net: introduce and use KERNEL_MAX_HEADER_PARSE_ADDRLEN Florian Westphal
2015-03-03 17:03 ` Willem de Bruijn
2015-03-03 17:11 ` Florian Westphal
2015-03-02 19:49 ` [PATCH RFC 00/14] shrink skb cb to 44 bytes Eric Dumazet
[not found] ` <1425325763.5130.123.camel-XN9IlZ5yJG9HTL0Zs8A6p/gx64E7kk8eUsxypvmhUTTZJqsBc5GL+g@public.gmane.org>
2015-03-02 20:42 ` Florian Westphal
2015-03-02 21:56 ` Eric Dumazet
2015-03-02 22:17 ` David Miller
2015-03-03 4:02 ` Eric Dumazet
2015-03-03 4:05 ` David Miller
2015-03-03 11:43 ` Florian Westphal
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=20150302190316.GB9762@breakpoint.cc \
--to=fw@strlen.de \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@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).