Thread (6 messages) flat view 6 messages, 3 authors, 2007-03-09

RE: [PATCH 0/2] NET: Multiple queue network device support REPOST

From: Waskiewicz Jr, Peter P <hidden>
Date: 2007-03-09 06:42:28
Also in: lkml

-----Original Message-----
From: David Miller [mailto:davem@davemloft.net] 
Sent: Thursday, March 08, 2007 10:22 PM
To: Waskiewicz Jr, Peter P
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; 
Leech, Christopher
Subject: Re: [PATCH 0/2] NET: Multiple queue network device 
support REPOST


You didn't address my correction the other day wherein I 
clarified for you that my idea was not to store the queue mapping in
skb->priority but rather to shrink skb->priority to a u16 and
add a new u16 skb->queue_mapping or whatever field to store 
the necessary information.

You're just posting a set of patches using the same approach 
again plus some bug fixes, so there is essentially nothing 
new for anyone to review.

Why ask for feedback if you fail to take any of it into consideration?
:-/
This was taken into consideration, and I did reply that my concern for
doing that could cause stale data in the skb if the queue mapping
changed.  If a qdisc was implemented that could change the band to queue
mapping without having to reload the qdisc, the result could have skb's
heading for the wrong queues until the old data was drained from the
bands.  An example:

->enqueue() - maps queue, commits to skb, adds to band
netif_stop_queue(dev) - event is triggered that could cause a qdisc to
remap bands to queues, drain hardware queues
netif_wake_queue(dev) - reconfiguration is complete, resume transmission
->dequeue() - grab an skb enqueued prior to reconfiguration, read queue
from skb, hard_start_xmit() to the wrong queue
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help