> > Could you explain why this is unfair?
>
> The simple answer is the core attempts DRR scheduling (search for the
> paper by Varghese et al for more details)
> If you have multiple users of a resource (network interfaces in this
> case), then the quantum defines their weight. If you use
From: jamal <[EMAIL PROTECTED]>
Date: Fri, 10 Aug 2007 09:55:07 -0400
> On Thu, 2007-09-08 at 09:58 -0700, Roland Dreier wrote:
>
> > Could you explain why this is unfair?
>
> The simple answer is the core attempts DRR scheduling (search for the
> paper by Varghese et al for more details)
> If
On Thu, 2007-09-08 at 09:58 -0700, Roland Dreier wrote:
> Could you explain why this is unfair?
The simple answer is the core attempts DRR scheduling (search for the
paper by Varghese et al for more details)
If you have multiple users of a resource (network interfaces in this
case), then the qu
Hello Roland,
> Shirley, I think it would still be useful to run benchmarks of IPoIB
> on ehca with Dave's NAPI patches, both V5 that changed the "missed
> event" behavior and V6 that didn't. At least I'm curious to know how
> much the difference is.
>
> - R.
The performance difference was hug
> > Dave, could you please hold this portion of the patch for a moment. I will
> > test this patch ASAP. According to our previous experience, this changes
> > significant changes some IPoIB driver performance.
>
> I reverted everything Roland had an issue with, I got tired of arguing
> my p
> > Dave, could you please hold this portion of the patch for a moment. I
> > will test this patch ASAP. According to our previous experience, this
> > changes significant changes some IPoIB driver performance.
> If you adjust your quantum while doing that testing you may find an
> optimal va
David Miller wrote:
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 08 Aug 2007 11:32:34 -0400
Think of a box where you have other network interfaces, the way you
are implementing currently implies you are going to be very unfair to
the other interfaces on the box.
This was the point I was tryin
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 08 Aug 2007 08:10:59 -0400
> Its overdue - just hasnt been anybody who has raised their hands
> to do it. Stephen did at one point.
> Theres a lot of nice insights in that doc that will be nice to inherit.
> Theres also a nice state machine diagram in
>
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 08 Aug 2007 11:32:34 -0400
> Think of a box where you have other network interfaces, the way you
> are implementing currently implies you are going to be very unfair to
> the other interfaces on the box.
This was the point I was trying to make the othe
Dave,
> I reverted everything Roland had an issue with, I got tired of arguing
> my position and doing all of the coding too. He won.
Thanks. I think the reschedule in the IPoIB poll should maintain fairness.
Shirley
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
From: Shirley Ma <[EMAIL PROTECTED]>
Date: Wed, 8 Aug 2007 08:14:13 -0700
> Dave, could you please hold this portion of the patch for a moment. I will
> test this patch ASAP. According to our previous experience, this changes
> significant changes some IPoIB driver performance.
I reverted everyth
On Wed, 2007-08-08 at 08:14 -0700, Shirley Ma wrote:
> Dave, could you please hold this portion of the patch for a moment. I
> will test this patch ASAP. According to our previous experience, this
> changes significant changes some IPoIB driver performance.
>
If you adjust your quantum while doin
On Tue, 2007-07-08 at 17:59 -0700, David Miller wrote:
> I am tempted to suggest we toss the document completely, for
> two reasons:
Its overdue - just hasnt been anybody who has raised their hands
to do it. Stephen did at one point.
Theres a lot of nice insights in that doc that will be nice to
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Tue, 07 Aug 2007 20:56:40 -0700
> First, there's pretty much universal agreement that
> patches should only contain one idea ("separate your changes"), that
> cleanups should not be mixed in with other changes, etc, etc.
Fine I'll revert.
> Although
> > > n = ib_poll_cq(priv->cq, t, priv->ibwc);
> > >
> > > - for (i = 0; i < n; ++i) {
> > > + for (i = 0; i < n; i++) {
> >
> > it might be nicer to avoid noise like this in the patch.
> That one was just too much of an eye sore to ignore
From: jamal <[EMAIL PROTECTED]>
Date: Tue, 07 Aug 2007 08:52:35 -0400
> That doc is out of date on the split of work - it focusses mostly
> describing the original tulip which did not mix rx and tx in the
> napi_poll(). AFAIK, no driver does that today (although i really liked
> that scheme, there
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Tue, 07 Aug 2007 15:37:30 -0700
> >n = ib_poll_cq(priv->cq, t, priv->ibwc);
> >
> > - for (i = 0; i < n; ++i) {
> > + for (i = 0; i < n; i++) {
>
> it might be nicer to avoid noise like this in the patch.
That one
Thanks for looking at ipoib... overall looks fine, just a few comments.
> --- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
> +++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
> @@ -281,63 +281,58 @@ static void ipoib_ib_handle_tx_wc(struct net_device
> *dev, struct ib_wc *wc)
>
On Sun, 2007-05-08 at 23:24 -0700, David Miller wrote:
>
> 3) Attempt to bring NAPI howto as uptodate as is possible for such
>a rotting document. :)
That doc is out of date on the split of work - it focusses mostly
describing the original tulip which did not mix rx and tx in the
napi_poll()
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 6 Aug 2007 11:00:45 -0700
> David Miller wrote:
>
> > 4) NETPOLL put hopefully into a working state.
>
> It's no longer necessary to change the tx locking scheme
> in bnx2.c and tg3.c, right? May be you forgot to revert
> the tx locking change
David Miller wrote:
> 4) NETPOLL put hopefully into a working state.
It's no longer necessary to change the tx locking scheme
in bnx2.c and tg3.c, right? May be you forgot to revert
the tx locking changes you did in V4?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
21 matches
Mail list logo
