- Avoid determining the MAC class (LEM/EM or IGB) - possibly even multiple times - on every interrupt by using an own set of device methods for the IGB class. This translates to introducing igb_if_intr_{disable,enable}() and igb_if_{rx,tx}_queue_intr_enable() with that IGB-specific code moved out of their EM counterparts and otherwise continuing to use the EM IFDI methods also for IGB. Note that igb_if_intr_{disable,enable}() also issue E1000_WRITE_FLUSH as lost with the conversion of igb(4) to iflib(4). Also note, that the em_if_{disable,enable}_intr() methods are renamed to em_if_intr_{disable,enable}() for consistency with the names used in the interface declaration.
- In em_intr():
- Don't bother to bail out if the interrupt type is "legacy", i. e. INTx or MSI, as iflib(4) doesn't use ift_legacy_intr methods for MSI-X. All other iflib(4)-based drivers avoid this check, too.
- Given that only the MSI-X interrupts have one-shot behavior (by taking advantage of the EIAC register), explicitly disable interrupts. Hence, em_intr() now matches what {em,igb}_irq_fast() previously did (in case of igb(4) supposedly also to work around MSI message reordering errata on certain systems).
- In em_if_intr_disable():
- Clear the EIAC register unconditionally for 82574 and not just in case of MSI-X, matching em_if_intr_enable() and bringing back the last hunk of r206437 lost with the iflib(4) conversion.
- Write to EM_EIAC for clearing said register instead of to the IGB-only E1000_EIAC used ever since the iflib(4) conversion.
Details
Details
- Reviewers
shurd - Group Reviewers
iflib Intel Networking - Commits
- rS349113: MFC: r347222
rS347222: o Avoid determining the MAC class (LEM/EM or IGB) - possibly even multiple
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| sys/dev/e1000/if_em.c | ||
|---|---|---|
| 3440 ↗ | (On Diff #57108) | Well, for the IGB-class of devices (but not the EM ones), using INTx or MSI is a very exceptional thing and MSI-X the typical course of operation. The usual way I indicate the latter to the CPU and/or compiler in the hot path is via predict_true() (or predict_false() for e. g. if (debug) kind of code). |
| 3457 ↗ | (On Diff #57108) | Ditto |
Comment Actions
Ok, I didn't think these functions were hot enough to be worth optimizing, and I'm not sure anything can be optimized around E1000_WRITE_*