All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: make-wifi-fast@lists.bufferbloat.net,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 3/3] mac80211: Set lower memory limit for non-VHT devices
Date: Fri, 30 Sep 2016 16:35:49 +0200	[thread overview]
Message-ID: <87h98x5ube.fsf@toke.dk> (raw)
In-Reply-To: <1475239915.17481.63.camel@sipsolutions.net> (Johannes Berg's message of "Fri, 30 Sep 2016 14:51:55 +0200")

Johannes Berg <johannes@sipsolutions.net> writes:

>> > I kinda see the logic here - we really don't need to queue as much
>> > if we can't possibly transmit it out quickly - but it seems to me
>> > we should also throw in some kind of limit that's relative to the
>> > amount of memory you have on the system?
>> 
>> Yes, ideally. That goes for FQ-CoDel as well, BTW. LEDE currently
>> carries a patch for that which just changes the hard-coded default to
>> another hard-coded default. Not sure how to get a good value to use,
>> though; and deciding on how large a fraction of memory to use for
>> packets starts smelling an awful lot like setting policy in the
>> kernel, doesn't it?
>
> Yeah, I agree it does seem awkward.
>
> Perhaps we should instead pick a low limit and let users change it
> more easily (i.e. not debugfs)? I don't know a good answer to this
> either.

Hmm, I'll talk it over with some of the LEDE people who are more used to
dealing with these sorts of memory-constrained devices than I am. Will
send a patch if we come up with a good solution :)

-Toke

      reply	other threads:[~2016-09-30 14:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-23 19:59 [PATCH 0/3] Add memory limits to fq.h and mac80211 TXQ Toke Høiland-Jørgensen
2016-09-23 19:59 ` Toke Høiland-Jørgensen
2016-09-23 19:59 ` [PATCH 1/3] fq.h: Port memory limit mechanism from fq_codel Toke Høiland-Jørgensen
2016-09-23 19:59   ` Toke Høiland-Jørgensen
2016-09-23 19:59 ` [PATCH 2/3] mac80211: Export fq memory limit information in debugfs Toke Høiland-Jørgensen
2016-09-23 19:59   ` Toke Høiland-Jørgensen
2016-09-23 19:59 ` [PATCH 3/3] mac80211: Set lower memory limit for non-VHT devices Toke Høiland-Jørgensen
2016-09-23 19:59   ` Toke Høiland-Jørgensen
2016-09-30 11:33   ` Johannes Berg
2016-09-30 12:41     ` Toke Høiland-Jørgensen
2016-09-30 12:41       ` Toke Høiland-Jørgensen
2016-09-30 12:51       ` Johannes Berg
2016-09-30 14:35         ` Toke Høiland-Jørgensen [this message]

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=87h98x5ube.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.