netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Florian Westphal <fw@strlen.de>
Cc: netdev@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH RFC 08/14] net: wireless: mac80211: shrink ieee80211_tx_info
Date: Mon, 02 Mar 2015 20:18:49 +0100	[thread overview]
Message-ID: <1425323929.1906.12.camel@sipsolutions.net> (raw)
In-Reply-To: <20150302190316.GB9762@breakpoint.cc>

On Mon, 2015-03-02 at 20:03 +0100, Florian Westphal wrote:

> Eventually reducing skb size to make it fit into 3 cachelines again even
> on 64bit architectures.  For that 40 bytes need to go.

That seems like a worthy goal I guess (I guess you should've copied a
patch 0/N to us).

> > 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.

Right now it is, mostly, yes.

> Where are to main problems, exactly?

Well, that depends. Right now clearly we're not really using all of it
as you saw (even if this patch moving bits here and there is really
ugly) but there are multiple things:
 1) Of course mac80211 isn't static, it keeps getting developed! Right
now for
    example we need to fix single TCP flow throughput over wifi, and for
that we
    need a timestamp. That won't even fit into skb->cb any more right
now; we'll
    probably be able to get away with (ab)using skb->tstamp or doing
reshuffling
    similar to yours to get some space, but that's just lucky this time.
 2) We're actually out of flags that are kept from TX generation to TX
    destruction and it's almost certain that we'll need to add more
things.

Also, we already do a lot of bit twiddling here, doing it even more
makes the code even harder to follow. It's bad enough as is if you ask
me.

> 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.

Right, and we do that. We've in the past moved out data from here to
elsewhere, but it's extremely tedious and error-prone, and I'm not sure
we have much that we can possibly move now, since we do need to hang on
to SKBs in many cases like client powersaving etc.

> Is there a document somewhere that lists all of the per-skb data that
> mac80211 needs to store (or wants to store)?

Not really, sorry.

> +                                       enum mac80211_tx_control_flags flags:2;
> +                                       /* used for BUILD_BUG_ON validation that ->flags won't
> +                                        * overlap with jiffies below */
> +                                       char flags_end[0];

That "jiffies" should probably say "other members (currently jiffies)"
or something ... I got a bit confused here.

johannes

  reply	other threads:[~2015-03-02 19:18 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
2015-03-02 19:18         ` Johannes Berg [this message]
     [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=1425323929.1906.12.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=fw@strlen.de \
    --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).