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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 11 Jun 2007 11:05:06 -0400
From:	jamal <hadi@...erus.ca>
To:	Patrick McHardy <kaber@...sh.net>
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.

On Mon, 2007-11-06 at 16:49 +0200, Patrick McHardy wrote:

> Let me explain with some ASCII art :)

Ok ;-> 

> We have n empty HW queues with a maximum length of m packets per queue:
> 
> [0] empty
> [1] empty
> [2] empty
> ..
> [n-1] empty
> 

Asumming 0 i take it is higher prio than n-1.

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

and packets are being fired on the wire by the driver etc ...

> Now we receive m packets of priorty n:

n-1 (i think?)

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

ok, so 0 is lower prio than n-1 

> To start it again at least
> one packet of queue n - 1 needs to be sent, 

following so far ...

> which (assuming
> strict priority) requires that queues 1 to n - 2 are serviced
> first. 

Ok, so let me revert that; 0 is higher prio than n-1.

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

"possibly long time" is where we diverge ;->
If you throw the burden to the driver (as i am recommending in all my
arguements so far), it should open up sooner based on priorities.
I didnt wanna bring this earlier because it may take the discussion in
the wrong direction. 
So in your example if n-1 shuts down the driver, then it is upto to the
driver to open it up if any higher prio packet makes it out.

> With multiple queue states we'd know that
> queue 0 can still take packets.

And with what i described you dont make any such changes to the core;
the burden is on the driver.

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