Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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 linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
