netdev - Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits

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] [day] [month] [year] [list]

Message-ID: <1314303787.2329.1.camel@mojatatu>
Date:	Thu, 25 Aug 2011 16:23:07 -0400
From:	jamal <hadi@...erus.ca>
To:	Tom Herbert <therbert@...gle.com>
Cc:	Johannes Berg <johannes@...solutions.net>, davem@...emloft.net,
	netdev@...r.kernel.org
Subject: Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits

On Thu, 2011-08-25 at 08:29 -0700, Tom Herbert wrote:

> BQL is dynamic, and will increase the queue limit more aggressively
> than decrease it.  So for instance, we can track the largest queue
> needed over 30 seconds which should be stable in the presence even in
> the presence of fluctuating bandwidth.  The thing that worries me is
> rather the HW queues conform to the queue characteristics described in
> the patch.  If transmit completions are random and not regular, BQL
> probably can't function well.
> 

I think thats the challenge ;-> I wouldnt say it is random, but if my
understanding is correct the effect is a factor of number of stations
etc.

> If you'd like to bring this up on some wireless devices that would be
> great, I don't have easy access to any right now, but I can try to
> help otherwise.

I am most curious as well...

cheers,
jamal


--
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