From: Alexander Duyck <alexander.duyck@gmail.com>
To: Benjamin Poirier <bpoirier@suse.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
Frank Steiner <steiner-reg@bio.ifi.lmu.de>,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Shannon Nelson <shannon.nelson@intel.com>,
Carolyn Wyborny <carolyn.wyborny@intel.com>,
Don Skidmore <donald.c.skidmore@intel.com>,
Matthew Vick <matthew.vick@intel.com>,
John Ronciak <john.ronciak@intel.com>,
Mitch Williams <mitch.a.williams@intel.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/4] e1000e: Do not read icr in Other interrupt
Date: Wed, 4 Nov 2015 15:26:22 -0800 [thread overview]
Message-ID: <563A941E.1070209@gmail.com> (raw)
In-Reply-To: <20151104231945.GA7111@f1.synalogic.ca>
On 11/04/2015 03:19 PM, Benjamin Poirier wrote:
> On 2015/10/30 12:19, Alexander Duyck wrote:
>> On 10/30/2015 10:31 AM, Benjamin Poirier wrote:
>>> Using eiac instead of reading icr allows us to avoid interference with
>>> rx and tx interrupts in the Other interrupt handler.
>>>
>>> According to the 82574 datasheet section 10.2.4.1, interrupt causes that
>>> trigger the Other interrupt are
>>> 1) Link Status Change.
>>> 2) Receiver Overrun.
>>> 3) MDIO Access Complete.
>>> 4) Small Receive Packet Detected.
>>> 5) Receive ACK Frame Detected.
>>> 6) Manageability Event Detected.
>>>
>>> Causes 3, 4, 5 are related to features which are not enabled by the
>>> driver. Always assume that cause 1 is what triggered the Other interrupt
>>> and set get_link_status. Cause 2 and 6 should be rare enough that the
>>> extra cost of needlessly re-reading the link status is negligible.
>>>
>>> Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
>> You might want to instead use a write of LSC to the ICR instead of just
>> using auto-clear and not enabling LSC. My concern is that you might no
>> longer be getting link status change events at all. An easy test is to just
>> unplug/plug the cable a few times, or run "ethtool -r" on the link partner
>> if connected back to back. You should see messages appear in the dmesg log
>> indicating that the link state changed.
>>
>> In addition you should probably clear the IAME bit in the CTRL_EXT register
>> so that you don't risk masking the interrupts on the ICR read or write.
> Thanks, your concern about not getting LSC events was right. After more
> experimentation I noticed that in order for the Other interrupt to be
> raised for each of these six conditions, the IMS bit for that condition
> must also be set. I've restored setting LSC in IMS. OTOH, I don't see a
> need to clear LSC from ICR. Even without an ICR read or write-to-clear
> to clear the LSC bit, Other interrupts are raised to signal LSC events.
>
> I'll wait for net-next to reopen and send v3.
You probably don't need to wait. The Intel-wired tree operates outside
of Dave's merge window, and it will take some time for the patches to be
validated before the Jeff can submit them to Dave.
- Alex
next prev parent reply other threads:[~2015-11-04 23:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-30 17:31 [PATCH v2 0/4] e1000e msi-x fixes Benjamin Poirier
2015-10-30 17:31 ` [PATCH v2 1/4] e1000e: Remove unreachable code Benjamin Poirier
2015-10-30 17:31 ` [PATCH v2 2/4] e1000e: Do not read icr in Other interrupt Benjamin Poirier
2015-10-30 19:19 ` Alexander Duyck
2015-11-04 23:19 ` Benjamin Poirier
2015-11-04 23:26 ` Alexander Duyck [this message]
2015-10-30 17:31 ` [PATCH v2 3/4] e1000e: Do not write lsc to ics in msi-x mode Benjamin Poirier
2015-10-30 17:31 ` [PATCH v2 4/4] e1000e: Fix msi-x interrupt automask Benjamin Poirier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=563A941E.1070209@gmail.com \
--to=alexander.duyck@gmail.com \
--cc=bpoirier@suse.com \
--cc=carolyn.wyborny@intel.com \
--cc=donald.c.skidmore@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=john.ronciak@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.vick@intel.com \
--cc=mitch.a.williams@intel.com \
--cc=netdev@vger.kernel.org \
--cc=shannon.nelson@intel.com \
--cc=steiner-reg@bio.ifi.lmu.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).