Hi Luiz, * Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> [2011-08-03 20:49:19 +0300]: > Hi Peter, > > On Wed, Aug 3, 2011 at 7:25 PM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: > > > > I believe that the existing tx scheduler is already inefficient and that > > this approach significantly compounds that inefficiency. > > > > Consider the following scenarios with 4 ACL connections (keyboard, > > mouse, phone, headset): > > > > For *one* scheduled ACL tx packet, the connection list will be searched > > 35~42 times -- that's 140~168 connection list node visits to find one > > packet! Here's the math: > > (7 - priority of tx packet) x 4 connections => found the packet > > 7 pri levels x 4 connections => no more ACL tx packets > > 7 pri levels x 4 connections => no SCO tx packets > > 7 pri levels x 4 connections => no ESCO tx packets > > 7 pri levels x 4 connections => no LE tx packets > > 7 pri levels x 4 connections => recalc priority > > > > If the connection type doesn't match, it's not going to match at any > > priority level. > > Obviously there are a few things that we might change to not traverse > the list of connection over and over, remember this is an RFC, besides > it 8 priorities (0-7), but we can skip much earlier if connection > doesn't match as you said. Also I guess for SCO/ESCO/LE e doesn't make > much sense to have many queues/priorities, it is basically ACL only, > that simplify a lot already. Maybe 8 is too much, I think it could work with 4. We keep the high priority queue 7 and more 3. A2DP and SCO could have the 6, HID the queue 5, Obex transfers, PAN, AVRCP, etc goes queue 4. Queueing in 3, 2, 1 and 0 could actually queue on 4. Gustavo -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
