On Wed, 2016-04-06 at 10:39 -0700, Dave Taht wrote:
> > > The hope had been the original codel.h would have been reusable,
> > > which is not the case at present.
> > So what's the strategy for making it happen?
> Strategy? to meander towards a result that gives low latency to all
> stations, no m
On Wed, Apr 6, 2016 at 12:21 AM, Johannes Berg
wrote:
> [removing other lists since they spam me with moderation bounces]
I have added your email address be accepted to the codel,
make-wifi-fast lists. My apologies for the bounces.
The people on those lists generally do not have the time to tack
> On 6 Apr, 2016, at 10:16, Michal Kazior wrote:
>
> When a driver asks mac80211 to dequeue given txq it implies a
> destination station as well. This is important because 802.11
> aggregation can be performed only on groups of packets going to a
> single station on a single tid.
>
> Cake - as
[removing other lists since they spam me with moderation bounces]
> The hope had been the original codel.h would have been reusable,
> which is not the case at present.
So what's the strategy for making it happen? Unless there is one, I
don't see the point in making the code more complicated than
On Wed, 2016-04-06 at 07:35 +0200, Michal Kazior wrote:
> I just wanted to follow the suggested/implied usage of codel code and
> keep modifications to a minimum. I could very well just assimilate it
> if you wish.
I don't really feel all that strongly about it, but I also don't see
the point. It
On 6 April 2016 at 08:03, Jonathan Morton wrote:
>
>> On 6 Apr, 2016, at 08:35, Michal Kazior wrote:
>>
>> Packets can be destined to different stations/txqs. At enqueue time I
>> do a partial hash of a packet to get an "index" which I then use to
>> address a txq_flow from per-radio list (out of
> On 6 Apr, 2016, at 08:35, Michal Kazior wrote:
>
> Packets can be destined to different stations/txqs. At enqueue time I
> do a partial hash of a packet to get an "index" which I then use to
> address a txq_flow from per-radio list (out of 4096 of them). You can
> end up with a situtation like
On 5 April 2016 at 15:57, Johannes Berg wrote:
> On Thu, 2016-03-31 at 12:28 +0200, Michal Kazior wrote:
>
>> +++ b/net/mac80211/codel.h
>> +++ b/net/mac80211/codel_i.h
>
> Do we really need all this code in .h files? It seems very odd to me to
> have all the algorithm implementation there rather
thx for the review!
On Tue, Apr 5, 2016 at 6:57 AM, Johannes Berg wrote:
> On Thu, 2016-03-31 at 12:28 +0200, Michal Kazior wrote:
>
>> +++ b/net/mac80211/codel.h
>> +++ b/net/mac80211/codel_i.h
>
> Do we really need all this code in .h files? It seems very odd to me to
> have all the algorithm i
On Thu, 2016-03-31 at 12:28 +0200, Michal Kazior wrote:
> +++ b/net/mac80211/codel.h
> +++ b/net/mac80211/codel_i.h
Do we really need all this code in .h files? It seems very odd to me to
have all the algorithm implementation there rather than a C file, you
should (can?) only include codel.h into
Qdiscs assume all packets regardless of
destination address are treated equally by
underlying an device link.
This isn't true for wireless where each node is a
link in it's own right with different and varying
signal quality over time.
Existing wireless behavior stuffs device tx queues
with no re
11 matches
Mail list logo
