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

[Waskiewicz Jr, Peter P]

> -----Original Message-----
> From: David Miller [mailto:davem@xxxxxxxxxxxxx] 
> Sent: Thursday, March 08, 2007 10:22 PM
> To: Waskiewicz Jr, Peter P
> Cc: netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; 
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/