From: jamal <[EMAIL PROTECTED]>
Date: Mon, 08 Oct 2007 09:34:50 -0400
> The brain-block i am having is the parallelization aspect of it.
> Whatever scheme it is - it needs to ensure the scheduler works as
> expected. For example, if it was a strict prio scheduler i would expect
> that whatever goe
On Mon, 2007-08-10 at 10:22 -0400, Jeff Garzik wrote:
> Any chance the NIC hardware could provide that guarantee?
If you can get the scheduling/dequeuing to run on one CPU (as we do
today) it should work; alternatively you can totaly bypass the qdisc
subystem and go direct to the hardware for dev
jamal wrote:
On Sun, 2007-07-10 at 21:51 -0700, David Miller wrote:
For these high performance 10Gbit cards it's a load balancing
function, really, as all of the transmit queues go out to the same
physical port so you could:
1) Load balance on CPU number.
2) Load balance on "flow"
3) Load bala
On Sun, 2007-07-10 at 21:51 -0700, David Miller wrote:
> For these high performance 10Gbit cards it's a load balancing
> function, really, as all of the transmit queues go out to the same
> physical port so you could:
>
> 1) Load balance on CPU number.
> 2) Load balance on "flow"
> 3) Load balanc
From: jamal <[EMAIL PROTECTED]>
Date: Mon, 24 Sep 2007 19:38:19 -0400
> How is the policy to define the qdisc queues locked/mapped to tx rings?
For these high performance 10Gbit cards it's a load balancing
function, really, as all of the transmit queues go out to the same
physical port so you co
On Tue, 2007-25-09 at 18:15 -0400, jamal wrote:
> A further optimization i made was to reduce the time it takes to hold
> the tx lock at the driver by moving gunk that doesnt need lock-holding
> into the new method dev->hard_end_xmit() (refer to patch #2)
Sorry, that should have read dev->hard_pr
On Tue, 2007-25-09 at 08:24 -0700, Stephen Hemminger wrote:
> The transmit code path is locked as a code region, rather than just object
> locking
> on the transmit queue or other fine grained object. This leads to moderately
> long
> lock hold times when multiple qdisc's and classification is b
On Tue, 25 Sep 2007 09:15:38 -0400
jamal <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-24-09 at 17:14 -0700, Stephen Hemminger wrote:
>
> > Since we are redoing this,
> > is there any way to make the whole TX path
> > more lockless? The existing model seems to be more of a monitor than
> > a real l
On Mon, 2007-24-09 at 17:14 -0700, Stephen Hemminger wrote:
> Since we are redoing this,
> is there any way to make the whole TX path
> more lockless? The existing model seems to be more of a monitor than
> a real locking model.
What do you mean it is "more of a monitor"?
On the challenge of m
On Mon, 2007-24-09 at 16:47 -0700, Waskiewicz Jr, Peter P wrote:
> We should make sure we're symmetric with the locking on enqueue to
> dequeue. If we use the single device queue lock on enqueue, then
> dequeue will also need to check that lock in addition to the individual
> queue lock. The det
> > I really just need to put my nose to the grindstone and get the
> > patches together and to the list...stay tuned.
> >
> > Thanks,
> > -PJ Waskiewicz
> > -
>
>
> Since we are redoing this, is there any way to make the whole
> TX path more lockless? The existing model seems to be more
> o
On Mon, 24 Sep 2007 16:47:06 -0700
"Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-24-09 at 15:57 -0700, Waskiewicz Jr, Peter P wrote:
> >
> > > I've looked at that as a candidate to use. The lock for
> > enqueue would
> > > be needed when actually placing the skb into the
> On Mon, 2007-24-09 at 15:57 -0700, Waskiewicz Jr, Peter P wrote:
>
> > I've looked at that as a candidate to use. The lock for
> enqueue would
> > be needed when actually placing the skb into the
> appropriate software
> > queue for the qdisc, so it'd be quick.
>
> The enqueue is easy to c
On Mon, 2007-24-09 at 15:57 -0700, Waskiewicz Jr, Peter P wrote:
> I've looked at that as a candidate to use. The lock for enqueue would
> be needed when actually placing the skb into the appropriate software
> queue for the qdisc, so it'd be quick.
The enqueue is easy to comprehend. The single
> The one thing that seems obvious is to use
> dev->hard_prep_xmit() in the patches i posted to select the
> xmit ring. You should be able to do figure out the txmit ring
> without holding any lock.
I've looked at that as a candidate to use. The lock for enqueue would
be needed when actually
On Mon, 2007-24-09 at 12:12 -0700, Waskiewicz Jr, Peter P wrote:
> Hi Jamal,
> I've been (slowly) working on resurrecting the original design
> of my multiqueue patches to address this exact issue of the queue_lock
> being a hot item. I added a queue_lock to each queue in the subqueue
> str
> I have submitted this before; but here it is again.
> Against net-2.6.24 from yesterday for this and all following patches.
>
>
> cheers,
> jamal
Hi Jamal,
I've been (slowly) working on resurrecting the original design
of my multiqueue patches to address this exact issue of the queue_
17 matches
Mail list logo
