All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: "Simon Barber" <simon@devicescape.com>
Cc: "Jiri Benc" <jbenc@suse.cz>,
	linville@tuxdriver.com, netdev@vger.kernel.org
Subject: Re: [PATCH] d80211: add ieee80211_stop_queues()
Date: Wed, 23 Aug 2006 22:57:25 +0200	[thread overview]
Message-ID: <200608232257.25590.mb@bu3sch.de> (raw)
In-Reply-To: <C86180A8C204554D8A3323D8F6B0A29F0165B5E4@dhost002-46.dex002.intermedia.net>

On Wednesday 23 August 2006 22:32, Simon Barber wrote:
> Right - and what I'm proposing is that we don't just count the number of
> frames in the ring - but also count the amount of frame time the ring
> takes too. This way if there are a number of large, slow frames we can
> stop adding more frames into the ring well before we reach the limit on
> the number of frames. 

Ah, now I understand what you are trying to explain. :)
But why do we actually _want_ to stop a DMA ring, if it's
not full (has free descriptors)? I can't see any benefit on
it. Adding frames to the ring is done on the fly without
stopping or otherwise interferring with any running transmissions
queued earlier.
I would say we don't care about the time it takes for the
ring to go into idle on the d80211 level. I think the only thing
we care at d80211 level is: Can we queue another frame?
We have that logic. If a queue is not stopped, we can queue another
frame.

Or do you want to make the qdisc intelligent? Say, it drops
a few beacons, if there are already packets queued for the next
300ms, for example. Do you want to optimize latency of payload
data by dropping low-priority packets while the queue is
heavily loaded?
I can't see another usage for time based DMA ring accounting
in d80211, yet.

-- 
Greetings Michael.

  reply	other threads:[~2006-08-23 20:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-23 11:44 [PATCH] d80211: add ieee80211_stop_queues() Michael Buesch
2006-08-23 19:30 ` Simon Barber
2006-08-23 19:45   ` Michael Buesch
2006-08-23 19:54     ` Simon Barber
2006-08-23 20:04       ` Michael Buesch
2006-08-23 20:10         ` Simon Barber
2006-08-23 20:20           ` Michael Buesch
2006-08-23 20:32             ` Simon Barber
2006-08-23 20:57               ` Michael Buesch [this message]
2006-08-23 21:12                 ` Simon Barber
2006-08-23 22:07                   ` Michael Buesch

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=200608232257.25590.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=jbenc@suse.cz \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    --cc=simon@devicescape.com \
    /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.