sunvnet: Reduce LDC message overhead.
Subsystems (2)
v2 cover sunvnet: Reduce LDC message overhead.
This patchset has an updated version of the v1 changes to reduce the overhead from LDC messages.
Re-submitting both patches for completeness.
- Send the minimum number of start and stop messages between producer and consumer.
Changes since v1 to pull out the unused label again' and the unused retries' variable
- When reading the descriptor rings, don't give up as soon as a dring that is not VIO_DESC_READY is found.
Changes since v1: the `again' label and retries variable belong to this patch.
I understand the Puristic objection to the polling-delay from patch 2/2, but the practical reality is that when there is a burst of data, and performance is actually most critical, the overhead from hastily sending an LDC stop and then processing another LDC start message is far greater than the slight penalty of a small delay when the network traffic is light.
Note that I'm separately working on moving the data handling to a bottom-half or softirq context, where the poll-based delay will be even less critical. We could also consider adding a procfs or ethtool based knob to disable the fudge-factored delay, and avoid the minor polling penalty.
Sowmini Varadhan (2):
Avoid sending superfluous LDC messages.
Re-check for a VIO_DESC_READY data descriptor after short udelay()
drivers/net/ethernet/sun/sunvnet.c | 87 ++++++++++++++++++++++++++++++++++---- drivers/net/ethernet/sun/sunvnet.h | 4 ++ 2 files changed, 83 insertions(+), 8 deletions(-)
Signature · 1 line
1.8.4.2
David Miller
maintainerFrom: Sowmini Varadhan <[email protected]>
Date: Tue, 2 Sep 2014 12:19:36 -0400
Quoted 2 lines
This patchset has an updated version of the v1 changes to reduce the overhead from LDC messages.
Let's hold on these changes until the memory barrier issues brought up by David is resolved.
Quoted 8 lines · David Miller
From: Sowmini Varadhan <[email protected]>
Quoted 2 lines
This patchset has an updated version of the v1 changes to reduce the overhead from LDC messages.
Let's hold on these changes until the memory barrier issues brought up by David is resolved.
On (09/07/14 16:19), David Miller wrote (in the patch 2/2 thread for this set):
Quoted 5 lines
Quoted 3 lines
So what (if any) is the outstanding question about
wmb()at this point?I don't think there is any, thanks.
I'm not sure where we stand with this- do I need to resubmit any/all of those two patches?
--Sowmini
Quoted 3 lines · Sowmini Varadhan
I'm not sure where we stand with this- do I need to resubmit any/all of those two patches?
Dave,
FWIW, I think there may be a memory barrier issue (missing rmb()),
which I'll look into and patch separately, if needed, but I don't think it has anything to do with this patchset.
My original concern about the wmb() placement was wrong, I agree.
+-DLS
Excuse me if I am missing something obvious, but what was the verdict on this? Is there any additional clarification/information I can provide, if this is being mulled over?
--Sowmini
Quoted 22 lines · Sowmini Varadhan
Quoted 8 lines · David Miller
From: Sowmini Varadhan <[email protected]>
Quoted 2 lines
This patchset has an updated version of the v1 changes to reduce the overhead from LDC messages.
Let's hold on these changes until the memory barrier issues brought up by David is resolved.
On (09/07/14 16:19), David Miller wrote (in the patch 2/2 thread for this set):
Quoted 5 lines
Quoted 3 lines
So what (if any) is the outstanding question about
wmb()at this point?I don't think there is any, thanks.
I'm not sure where we stand with this- do I need to resubmit any/all of those two patches?
--Sowmini
David Miller
maintainerFrom: Sowmini Varadhan <[email protected]>
Date: Wed, 10 Sep 2014 10:04:34 -0400
Quoted 3 lines
Excuse me if I am missing something obvious, but what was the verdict on this? Is there any additional clarification/information I can provide, if this is being mulled over?
After the memory barrier stuff has been sorted out, the patches should be submitted again for review.
But I was under the impression that for now we weren't going to be doing the new udelay() things, which defers patch #2 for now.
Quoted 6 lines · David Miller
After the memory barrier stuff has been sorted out, the patches should be submitted again for review.
But I was under the impression that for now we weren't going to be doing the new
udelay()things, which defers patch #2 for now.
ah, ok, I didn't realize the ball was in my court- good that I checked.
I'll re-submit a unified diff without the extra-udelay-stuff as a v3 patch for review tomorrow.
--Sowmini