netdev - Re: [PATCH] NET: Multiqueue network device support.

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]

Date:	Mon, 11 Jun 2007 16:49:41 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	hadi@...erus.ca
CC:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	davem@...emloft.net, netdev@...r.kernel.org, jeff@...zik.org,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>
Subject: Re: [PATCH] NET: Multiqueue network device support.

jamal wrote:
> On Mon, 2007-11-06 at 16:03 +0200, Patrick McHardy wrote:
> 
>>Read again what I wrote about the n > 2 case. Low priority queues might
>>starve high priority queues when using a single queue state for a
>>maximum of the time it takes to service n - 2 queues with max_qlen - 1
>>packets queued plus the time for a single packet. Thats assuming the
>>worst case of n - 2 queues with max_qlen - 1 packets and the lowest
>>priority queue full, so the queue is stopped until we can send at
>>least one lowest priority packet, which requires to fully service
>>all higher priority queues previously.
> 
> 
> I didnt quiet follow the above - I will try retrieving reading your
> other email to see if i can make sense of it. 


Let me explain with some ASCII art :)

We have n empty HW queues with a maximum length of m packets per queue:

[0] empty
[1] empty
[2] empty
..
[n-1] empty

Now we receive m - 1 packets for each all priorities >= 1 and < n - 1,
so we have:

[0] empty
[1] m - 1 packets
[2] m - 1 packets
..
[n-2] m - 1 packets
[n] empty

Since no queue is completely full, the queue is still active.
Now we receive m packets of priorty n:

[0] empty
[1] m - 1 packets
[2] m - 1 packets
..
[n-2] m - 1 packets
[n-1] m packets

At this point the queue needs to be stopped since the highest
priority queue is entirely full. To start it again at least
one packet of queue n - 1 needs to be sent, which (assuming
strict priority) requires that queues 1 to n - 2 are serviced
first. So any prio 0 packets arriving during this period will
sit in the qdisc and will not reach the device for a possibly
quite long time. With multiple queue states we'd know that
queue 0 can still take packets.

>>Your basic assumption seems to be that the qdisc is still in charge
>>of when packets get sent. This isn't the case if there is another
>>scheduler after the qdisc and there is contention in the second
>>queue.
> 
> 
> My basic assumption is if you use the same scheduler in both the
> hardware and qdisc, configured the same same number of queues and
> mapped the same priorities then you dont need to make any changes
> to the qdisc code. If i have a series of routers through which a packet
> traveses to its destination with the same qos parameters i also achieve
> the same results.


Did my example above convince you that this is not the case?

-
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