On 30 March 2016 at 02:57, Dave Taht <dave.taht@xxxxxxxxx> wrote: > As a side note of wifi ideas complementary to codel, please see: > > http://blog.cerowrt.org/post/selective_unprotect/ > > On Tue, Mar 29, 2016 at 12:49 AM, Michal Kazior <michal.kazior@xxxxxxxxx> wrote: [...] >> On the other hand DQL will react also to host system interrupt service >> time. On slow CPUs (typically found on routers and such) you might end >> up grinding the CPU so much you need deeper tx queues to keep the hw >> busy (and therefore keep performance maxed). DQL should automatically >> adjust to that while "txop limit" might not. > > Mmmm.... current multi-core generation arm routers should be fast enough. While this helps it doesn't mean you can magically un-serialize interrupt/txrx completion work. [...] >>>> To sum things up: >>>> - DQL might be able to replace the explicit txop queue limiting >>>> (which requires rate control info) >>> >>> I am pessimistic. Perhaps as a fallback? >> >> At first I was (too) considering DQL as a nice fallback but the more I >> think about the more it makes sense to use it as the main source of >> deriving time slices for tx scheduling. > > I don't really get how dql can be applied per station in it's current forrm. I was thinking of the following scheme: - disable excessive retries in fw (apparently doable via WMI pdev parameter) - deficit-based round-robin over stations - maintain DQL structure per station - when station gets its turn to xmit push frames to fw - keep doing that (with regard to per station DQL limits) until either: - associated software queue becomes empty - 1 timeslice for given station has elapsed - i was thinking of extracting timeslices from DQL or maintaining it separately - try next station - do not submit packets to multiple stations at once (MU will need more work..), i.e. always drain tx completely before switching to next station - each station may need a different timeslice (to squeeze out max burst performance) [...] >>>> PS. I'm not feeling comfortable attaching 1MB attachment to a mailing >>>> list. Is this okay or should I use something else next time? >>> >>> I/you can slam results into the github blogcerowrt repo and then pull >>> out stuff selectively.... >> >> Good idea, thanks! > > You got commit privs. Yep, thanks! Michał -- 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
