bold text

When this was originally implemented, Limelight (sbruno) experienced issues with this feature, as it was conflicting with iflib in some way, so it was then set to off by default.

Driver loads in safe mode even though ice_ddp is loaded:

We'll need to patch this to bring it in line with OOT, but is g2g for now.

Tested with a 1000 iteration ifdown/up loop using both DA and SR, configured normally and using LAGG.

In D18470#396858, @jacob.e.keller_intel.com wrote:

We are seeing tx hangs with UDP using multiple clients when offloads are disabled. Cannot reproduce on 12.0-RELEASE. Reproducible on X520 and X550.

This sounds like it can't reproduce on 12-release, meaning that it's a bug with this patch applied? Is that a correct interpretation of the statement?

Clarification would help here.

In D18470#396629, @sbruno wrote:

In D18470#396626, @jeffrey.e.pieper_intel.com wrote:

We are seeing tx hangs with UDP using multiple clients when offloads are disabled. Cannot reproduce on 12.0-RELEASE. Reproducible on X520 and X550.

Huh? Does this review break things for you? Or are you bringing up a new problem?

We are seeing tx hangs with UDP using multiple clients when offloads are disabled. Cannot reproduce on 12.0-RELEASE. Reproducible on X520 and X550.

We cannot reproduce the panic that was resolved with https://reviews.freebsd.org/D17404, so it looks okay to me.

This patch fixes a kernel panic we are seeing when unloading iavf while passing traffic.

Does not apply against lastest HEAD:

Tested with a RHEL7.4 host w/ KVM using both port and host-based VLANs w/ 9710 MTU.

Several outstanding issues:

I think we need to lower it. 500 significantly impacts 40G performance w/ 9K MTU, especially rx.

This also needs to be rebased again , probably due to: https://reviews.freebsd.org/D15343:

We see constant tx hangs when changing driver settings:

In D15558#328462, @gallatin wrote:

In D15558#328453, @sbruno wrote:

Was this the patch that we discussed on our call? Does this fix your TX checksum problems on IXL?

Yes and Yes.

Unfortunately, I've now proceeded to the "entire box hangs" portion of the game. Even serial console break-to-debugger is ignored. I'm going to try NMIs next..

It was committed on 5-1 and MFC'ed to STABLE on 5-7, so I'm not sure why this wasn't closed.

The panic is still reproducible, it just takes longer. See attached screen cap.

Kernel panic with TCP bi-directional netperf traffic using 2 threads :

In D13885#295301, @sbruno wrote:

Unrelated, is there a use case for FreeBSD Bhyve here? If we had PF support on FreeBSD, could we use pass through to use VFs?

ixv is totally broken. on a FreeBSD host with PCI_IOV, assigning an IP address to a "bare metal" ixv interface{F3125365} causes a kernel panic. On a Linux host, the VF hangs when assigned an IP address and requires a reboot of the VM to recover.

We can throw this at CNL and CFL ( Cannon Lake/Coffee Lake).

looking at the packages from Intel Download Center, I think this is a tool build issue. It looks like file permissions changed between 5.05 and 6.01. In 5.05 the directory structure for nvmupdate is 755, but in 6.01 it is 644, which for some reason 10 doesn't like.

We're seeing instability on X520-QDA1 (QSFP+):

1. Occasionally, ifconfig will report "ifconfig: ix0: no media types?" message instead of the media type.
2. System will "partially" hang on kldunload after the interface has been configured. After this occurs, you can ssh into the system through another interface and the FS is accessible, but ifconfig, top etc. are hung.

Also seeing panics at detach after passing traffic.

In D11727#244936, @sbruno wrote:

I've tested 82599ES in single and LAGG configurations. This all seems good to me.

I'm moving on to test with X550-T2. I have no easy way to test VFs, so that'll need to be exercised.

We need to hold off on committing this. We are investigating some issues that were discovered today.

Ship it

Shouldn't D10293 supersede this anyways?

I believe this review is dependent on D5213...at least that is how it was written. It certain doesn't apply without it. This review adds support for Denverton as well as separating the VF driver from the base driver.

In D9851#209276, @kevin.bowling_kev009.com wrote:

I would like to see this integrated soon, @sbruno has gotten iflib.c leveled up to a good spot and we are running it in production for e1000. @jeffrey.e.pieper_intel.com are you ok with @cramerj_intel.com latest fixes?

This does apply cleanly with D5213 as a dependency.

arc patch fails:

See attachment since Phabricator apparently didn't like the formatting of my paste...

It looks like ixv fails to build on 10/stable:

In D5213#174654, @jeffrey.e.pieper_intel.com wrote:

In D5213#174653, @sbruno wrote:

hrm ... I had the same behavior on an em(4) system when executing an "ifconfig em0 down up" here. Are you sure this is an "iflib" problem?

Considering this doesn't reproduce on ix legacy, I'm pretty sure. The mtu test completes with no errors anyways.

In D5213#174653, @sbruno wrote:

hrm ... I had the same behavior on an em(4) system when executing an "ifconfig em0 down up" here. Are you sure this is an "iflib" problem?

Also, I mentioned this earlier, but PLEASE print the driver version in dmesg at attach as well as in sysctl. It isn't very optimal to have no clue as to what driver version is being used.

There is an issue where a reset can cause the interface to be effectively dead and is only recoverable by reloading the driver. This was found during an mtu test, where the mtu is changed and traffic is ran between each iteration. It can be reproduced with just iterations of ifconfig up/down with ping and netperf between each iteration. See the attached log and repro script.

In D5213#172663, @sbruno wrote:

Preinitialize admin task and add some INVARIANT debugging in case this
doesn't capture why Intel lab testing fails so miserably.

Jeffrey:

Give this a spin and lets see if we can make forward progress with it.

In D5213#172512, @kmacy wrote:

@jeffrey.e.pieper_intel.com are all your test systems multi-socket or just this one?

In D5213#172502, @kmacy wrote:

@jeffrey.e.pieper_intel.com The panic you've hit means that the admin task was not assigned a taskqueue. In all likelihood we're hitting an initialization edge case on the system itself, not that particular adapter.

In D5213#172500, @kmacy wrote:

@jeffrey.e.pieper_intel.com and please post dmesg for the system it crashes on.

Correct.

Another data point:

In D5213#172449, @sbruno wrote:

Jeffrey:

Is this the same or different as reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211771 with the unmodified driver? The wording caught my eye as something we had already discussed a bit.

In D5213#172438, @kmacy wrote:

Is this with the driver in kernel or as a module? And with INVARIANTS or
without?

In D5213#172435, @kmacy wrote:

What svn rev are you using?

Stop the bus, I want to get off...

In D5213#171177, @jeffrey.e.pieper_intel.com wrote:

In D5213#171160, @gallatin wrote:

Jefffrey,

TSO implies checksum offload. If you could reverse the order of your test, that would be helpful. Eg, does +txcsum6 -tso6 work?

Thanks,

Drew

This does in fact appear to be a txcsum6 issue as well; netperf fails with just tso6 disabled, but unless both tso6 and txcsum6 are disabled, throughput is non-existent. With just -txcsum6, netperf passes traffic, but just bare

In D5213#171160, @gallatin wrote:

Jefffrey,

TSO implies checksum offload. If you could reverse the order of your test, that would be helpful. Eg, does +txcsum6 -tso6 work?

Thanks,

Drew

[root@u0805 /]# netperf -H u0807-2_6 -6 -p 12866
^C
[root@u0805 /]# ifconfig ix0 -txcsum6
[root@u0805 /]# ping u0807-2
PING u0807-2 (190.2.8.7): 56 data bytes
64 bytes from 190.2.8.7: icmp_seq=0 ttl=64 time=0.172 ms
64 bytes from 190.2.8.7: icmp_seq=1 ttl=64 time=0.138 ms
^C

• u0807-2 ping statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.138/0.155/0.172/0.017 ms
[root@u0805 /]# netperf -H u0807-2_6 -6 -p 12866
MIGRATED TCP STREAM TEST from ::0 (::) port 0 AF_INET6 to u0807-2_6 () port 0 AF_INET6 : histogram : interval : dirty data : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

Okay, --skip-dependencies did the trick. I'm unsure how to remove the "requested changes" flag.

This is a fresh clone...tried it twice w/ the same results.

Still fall down go boom:

Just let me know when it stops blowing up :)

This doesn't apply with tip of HEAD:

What are the expectations here, timeframe-wise?

We noticed this issue awhile back and it was fixed in 11 but not in 10. We don't see it using our OOT components, only with in-kernel on 10.3. It makes it difficult to perform any modicum of validation w/o being able to load and unload the driver.

ixl seems to have some issues with netmap when loaded as module:

arc is failing to apply this, as it is trying to apply it to stable/10/sys/dev/ixl, but SHOULD be sys/dev/ixl. I had to apply it manually.

I haven't had a chance to test this yet, so you should probably hold off.

Touch-tested on Kaby Lake, i219, ich10/82567, 82579, and 82574L.

Tested basic functionality, stress with netperf with both ixl and ixlv.

In D7391#154103, @sbruno wrote:

As far as I can tell, the error you're experiencing is from Phabricator, not the

In D7391#153674, @jeffrey.e.pieper_intel.com wrote:

The patch generated by Phabricator doesn't 'seem to manually apply to 11-BETA3 due the added files. It "should" just create them, but doesn't:

Hmm... The next patch looks like a unified diff to me...

The text leading up to this was:

Index: sys/dev/ixl/ixl_pf_iov.h

===================================================================

--- sys/dev/ixl/ixl_pf_iov.h

+++ sys/dev/ixl/ixl_pf_iov.h

---

File to patch: sys/dev/ixl/ixl_pf_iov.h
No file found--skip this patch? [n] n
patch: **** can't find sys/dev/ixl/ixl_pf_iov.h

Arc patch applies cleanly to stable/11, but fails to compile. Something in dtrace:

make[5]: make[5]: don't know how to make /diskless/os/FreeBSD/11-BETA3_2016-07-29_FPK/usr/src/sys/cddl/dev/dtrace/amd64/instr_size.c. Stop

the same kernel compiles and boots fine without the patch applied.

Try using arcanist (pkg install php5-arcanist) instead. Phabricator is definitely doing something wrong here.

"arc patch D7391" seems to work fine for me.

The patch generated by Phabricator doesn't 'seem to manually apply to 11-BETA3 due the added files. It "should" just create them, but doesn't: