netdev - Re: [PATCH] zd1211rw-mac80211: limit URB buffering in tx path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070501123411.081c43c6@logostar.upir.cz>
Date:	Tue, 1 May 2007 12:34:11 +0200
From:	Jiri Benc <jbenc@...e.cz>
To:	Daniel Drake <dsd@...too.org>
Cc:	linville@...driver.com, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org, kune@...ne-taler.de
Subject: Re: [PATCH] zd1211rw-mac80211: limit URB buffering in tx path

On Tue,  1 May 2007 04:01:00 +0100 (BST), Daniel Drake wrote:
> The old code allowed unlimited buffing of tx frames in URBs
> submitted for transfer to the device. This patch stops the
> ieee80211_hw queue(s) if to many URBs are ready for submit to the
> device. Actually the ZD1211 device supports currently only one
> queue.

This doesn't look correct to me. The limits should be per queue and you
should always stop queues selectively.

The ieee80211_stop_queues/ieee80211_wake_queues are for another purposes
and should be used only rarely - one example is Michael Buesch's comment
about a need to stop sending frames while tuning to a new channel in a
workqueue.

> +/**
> + * wake_queues - wakes all queues
> + * @hw: a &struct ieee80211_hw pointer
> + *
> + * Such a function is not provided by mac80211, so we have to provide them on
> + * our own.
> + */
> +static void wake_queues(struct ieee80211_hw *hw)

It is :-) Look for ieee80211_wake_queues. But as I said, you shouldn't need
that.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html