netdev - Re: [PATCH RFC 08/14] net: wireless: mac80211: shrink ieee80211_tx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150302193048.GC9762@breakpoint.cc>
Date:	Mon, 2 Mar 2015 20:30:48 +0100
From:	Florian Westphal <fw@...len.de>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	Florian Westphal <fw@...len.de>, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org
Subject: Re: [PATCH RFC 08/14] net: wireless: mac80211: shrink
 ieee80211_tx_info

Johannes Berg <johannes@...solutions.net> wrote:
> 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).

Indeed, sorry.
archived cover letter: http://marc.info/?l=linux-netdev&m=142531804325076&w=2

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

True.

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

I see.  I cannot comment any further at the moment, I will have to dig
into mac80211 more.

Thanks for your comments!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html