Bug 77361

Summary: e1000e driver lock pstates in C3 on Haswell with mtu values than 1500
Product: Drivers Reporter: da_audiophile
Component: NetworkAssignee: drivers_network (drivers_network)
Status: RESOLVED INVALID    
Severity: normal CC: alexander.h.duyck, bruce.w.allan, carolyn.wyborny, davidx.m.ertman, da_audiophile, jeffrey.t.kirsher, john.ronciak
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.14.5 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: dmesg on freshly booted system with startup script changing mtu size
output from i7z on idle with standard mtu size of 1500
output from i7z on idle with mtu size of 2000

Description da_audiophile 2014-06-04 21:11:03 UTC
Created attachment 138111 [details]
dmesg on freshly booted system with startup script changing mtu size

I have an H87-based system running an Intel i3-4130T (Haswell) that does not enter the C6 or C7 pstate when I set a non-standard mtu size.  The motherboard has an onboard  Intel Corporation Ethernet Connection I217-V (rev 05) which uses the e1000e driver.

If I boot the system without changing the mtu size (the default is 1500), I am able to enter pstate C7 no problem.  When I change the mtu size to 2000 or 4000, i7z reports my idle pstate as C3.

The condition is reversible if I drop the mtu size back to 1500.  I do not believe this behavior is expected based on my experience with jumboframes on older (Ivybridge) systems.

Glad to post any output upon request.

Attachemnts:
1) dmesg.
2) i7z output with mtu 1500 showing C7 pstate.
3) i7z output with mtu 4000 showing the bug (C3 pstates only).
Comment 1 da_audiophile 2014-06-04 21:12:36 UTC
Created attachment 138121 [details]
output from i7z on idle with standard mtu size of 1500
Comment 2 da_audiophile 2014-06-04 21:12:57 UTC
Created attachment 138131 [details]
output from i7z on idle with mtu size of 2000
Comment 3 Jesse Brandeburg 2014-06-04 21:51:54 UTC
I believe this is by design, the e1000e hardware has issues with jumbo frame reception if the processor enters a long latency sleep state.  Jumbo frames require the cpu to wake up and handle the packet reasonably fast, which is why the code is like it is.

e1000e is calling kernel interfaces to implement the C-state limits.
Comment 4 Dave 2014-06-04 22:19:10 UTC
Jesse is correct.

Also, LTR (Latency Tolerance Reporting) is now implemented in i217/i218 based devices.  When the MTU increases, the tolerance for CPU latency goes down.
Comment 5 da_audiophile 2014-06-04 23:49:50 UTC
Thank you both the quick replies and for the excellent information.  Safe to close this as not a bug.