On Mon, Mar 04, 2013 at 09:25:33PM +0100, Johannes Berg wrote: > On Mon, 2013-03-04 at 13:23 -0600, Seth Forshee wrote: > > > I've been looking at power save in mac80211 over the past few days with > > an eye towards allowing multiple interface to be supported, as a result > > of comments Johannes made at [1]. It seems like adding driver callbacks > > for PS which are specific to the interface type is contrary to this > > goal. > > Yeah, this is a concern. I didn't really stand in the way of doing mesh > powersave though, and it seemed that the new interface here would > actually be somewhat suitable, since for mesh any kind of powersave code > needs to know when to wake up/sleep. I would've liked to see less > reliance on host timers directly in core mac80211 even for the going to > sleep part though... basically I'm not sure for mesh just having PS > state will cut it. For managed mode this is easy because it only needs > to sync with a single AP, but for mesh that's a bit more complicated and > I think the whole sync should stay in mac80211. In the general case, > just having the TSF might not be enough, but that can be solved as > needed. I read about the basics of mesh PS last week but don't have a firm enough grasp on the details to understand what all would be needed for an implementation. From these patches it looks like at minimum the drivers need the next TBTT. That could be incorporated into something more generic easily enough. It's not the end of the world if these patches go in, it will just have to be sorted out if/when I make some progress on multi-vif PS. I wasn't planning on trying to lift any of the current restrictions on multiple vifs right away anyhow, so it should be manageable. > > The basic idea that's been forming on my mind is add PS states to vifs > > and make the managed, mesh, etc. code manipulate vif PS states rather > > than hw states. Then a PS module would manage the hw state based on the > > aggregate of the vif states. > > Yeah, that about matches what I was thinking. But like I said above, > while this is fairly simple for managed mode, at least as required > today, it's clearly not as simple for mesh. Glad to hear I'm headed down the right path :-) I've been trying to take all modes into consideration, but I had hoped the implementation details of mesh were something I wouldn't have to be immediately concerned with, since as you point out all of this is easier for managed mode. > For managed mode, we also assume that we can send packets while the > device is sleeping, and the device will do the right thing to wake up > for beacons from the AP etc. For mesh, there are many more wakeup > sources, from what I can tell. > > > I don't have a lot of the details worked out yet, and my knowledge of PS > > in mesh networks (and of mesh network operation in general) is pretty > > rudimentary at this point. But afaict any modes which support PS define > > the same two hw states, awake and doze. I wonder whether we should > > instead aim for a single interface into the driver for PS that's capable > > of supporting all interface types. > > Such an interface would probably have to be the interface now defined > for mesh, telling the device when to wake up and go to sleep? But this > interface is rather inefficient for most chipsets... I was thinking something along those lines as well, either the interfaces would be similar to the ones here or the data would be available in ieee80211_conf. Frankly I find having both the PS callback and IEEE80211_CONF_PS confusing, but maybe if I look at the patches more closely it will make sense. Seth -- 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
