Re: [net-next 03/10] ixgbe: Drop the TX work limit and instead just leave it to budget

[David Miller <davem@davemloft.net>]

From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Mon, 22 Aug 2011 10:29:51 -0700

> The only problem I was seeing with that was that in certain cases it
> seemed like the TX cleanup could consume enough CPU time to cause
> pretty significant delays in processing the RX cleanup.  This in turn
> was causing single queue bi-directional routing tests to come out
> pretty unbalanced since what seemed to happen is that one CPUs RX work
> would overwhelm the other CPU with the TX processing resulting in an
> unbalanced flow that was something like a 60/40 split between the
> upstream and downstream throughput.

But the problem is that now you're applying the budget to two operations
that have much differing costs.  Freeing up a TX ring packet is probably
on the order of 1/10th the cost of processing an incoming RX ring frame.

I've advocated to not apply the budget at all to TX ring processing.

I can see your delimma with respect to RX ring processing being delayed,
but if that's really happening you can consider whether the TX ring is
simply too large.

In any event can you try something like dampening the cost applied to
budget for TX work (1/2, 1/4, etc.)?  Because as far as I can tell, if
you are really hitting the budget limit on TX then you won't be doing
any RX work on that device until a future NAPI round that depletes the
TX ring work without going over the budget.