All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Javier Cardona <javier@cozybit.com>
Cc: "John W. Linville" <linville@tuxdriver.com>,
	Thomas Pedersen <thomas@cozybit.com>,
	devel@lists.open80211s.org, linux-wireless@vger.kernel.org,
	jlopex@gmail.com
Subject: Re: [PATCH 0/2] QoS headers for mesh
Date: Wed, 07 Sep 2011 20:14:19 +0200	[thread overview]
Message-ID: <1315419259.4002.16.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1315418920.4002.13.camel@jlt3.sipsolutions.net> (sfid-20110907_200849_198439_CB225490)

On Wed, 2011-09-07 at 20:08 +0200, Johannes Berg wrote:
> On Tue, 2011-09-06 at 15:26 -0700, Javier Cardona wrote:
> > Mesh frames are required to have QoS headers to indicate the presence of a Mesh
> > Control Header in the payload.  These patches add QoS headers to mesh frames,
> > but note that they don't implement full QoS support: mesh stations don't
> > currently advertise QoS capabilities.
> 
> Uh, so does mesh want full QoS support or just QoS headers? The latter
> seems a little odd to me. But if it wants QoS how about zd1211rw? I
> don't think that even supports QoS?
> 
> That's one thing that bothers me a little bit about this patchset --
> previously, QoS frames could only happen when the device actually
> supported 4 queues, now this rule seems to be broken. I don't expect
> this to be a major issue, but it certainly is unexpected and will
> probably be forgotten by a lot of people in the future ...

So after looking at this again -- what I'd much rather see instead of
the second patch, and what will also require fewer changes, is *only*
doing the change to ieee80211_set_qos_hdr(). Then, if the peer is a QoS
station, we'll get the right header -- if it isn't then we can't really
mesh with it but we'll accept that for legacy reasons (for now).

I'd rather not send QoS frames to mesh stations that don't advertise QoS
capability, and I'd also rather not have to worry about sending QoS
frames when we don't actually support it locally.

johannes


  reply	other threads:[~2011-09-07 18:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-06 22:26 [PATCH 0/2] QoS headers for mesh Javier Cardona
2011-09-06 22:26 ` [PATCH 1/2] mac80211: Start implementing QoS support for mesh interfaces Javier Cardona
2011-09-06 22:26 ` [PATCH 2/2] mac80211: Mesh data frames must have the QoS header Javier Cardona
2011-09-07 18:08 ` [PATCH 0/2] QoS headers for mesh Johannes Berg
2011-09-07 18:14   ` Johannes Berg [this message]
2011-09-07 18:36     ` Javier Cardona
2011-09-07 18:46       ` Johannes Berg
2011-09-08  3:34       ` Javier Cardona
2011-09-08  7:01         ` Johannes Berg
2011-09-07 18:23   ` Javier Cardona

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=1315419259.4002.16.camel@jlt3.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=devel@lists.open80211s.org \
    --cc=javier@cozybit.com \
    --cc=jlopex@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=thomas@cozybit.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.