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