Bug 556476

I've cloned this bug to track RHEL5 and RHEL6 separately. Bug 556563 is the one for RHEL6.

Created attachment 439444 [details]
patchset to update sfc up to v2.6.36-rc1 for RHEL5.6

These patches will update the sfc driver in RHEL5 to the version in v2.6.36-rc1.

They apply on kernel-2.6.18-212.el5 which is available at http://people.redhat.com/jwilson/el5/

The patchset is completely untested, I have just started a Brew build:
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2690223

I uploaded the built kernel to:
http://people.redhat.com/mschmidt/kernel/bz556476/

Could you please test it?

(In reply to comment #3)
> I uploaded the built kernel to:
> http://people.redhat.com/mschmidt/kernel/bz556476/
> 
> Could you please test it?

I've reviewed your backported patches and they looked correct. However, the kernel panics when probing! I am still investigating this.

Created attachment 441318 [details]
extra patches

I've attached a tarball containing the following patches:

- 0000a-vlan-pull-fix.patch
- 0000b-vlan-gro-fix.patch

Networking core fixes for VLAN RX with page buffers. Without these, all 802.1q packets received over an sfc device will be dropped unless the driver is configured to pre-allocate skbs (rx_alloc_method=1). This may be true for RHEL 5.5 as well.

I have not tested the br_netfilter changes in 0000a-vlan-pull-fix.patch so you may wish to remove them.

- 0082a-sfc-Add-power-management-and-wake-on-LAN-support-cleanup.patch

This makes the power management functions identical to upstream and adds wrapper functions like those we use in our out-of-tree driver. Please fold it into 0082-sfc-Add-power-management-and-wake-on-LAN-support.patch

- 0150a-sfc-Create-multiple-TX-queues-not-really.patch

This corrects the number of TX queues used, and fixes the panic I reported previously. Please fold it into 0150-sfc-Create-multiple-TX-queues.patch

- 0166a-sfc-Implement-message-level-control-cleanup.patch

This removes some unnecessary divergence from upstream. Please fold it into 0166-sfc-Implement-message-level-control.patch

There is still a performance-killing bug affecting VLAN TX which I will try to track down and fix tomorrow.

Awesome! Thank you, Ben.

Note for self: new Brew task 2715961

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

(In reply to comment #5)
> There is still a performance-killing bug affecting VLAN TX which I will try to
> track down and fix tomorrow.

Hello Ben,
do you have any progress on the VLAN TX performance bug?

Created attachment 442930 [details]
net: Fix test for VLAN TX checksum offload capability

(In reply to comment #8)
> (In reply to comment #5)
> > There is still a performance-killing bug affecting VLAN TX which I will try to
> > track down and fix tomorrow.
> 
> Hello Ben,
> do you have any progress on the VLAN TX performance bug?

I started back on this today. There's another fix to the networking
core needed to make VLAN TX acceleration work properly, which I'm
attaching now.

Given that the SFC9000 controllers support {TCP,UDP}/IPv6 checksum offload as well as IPv4, I think we can include NETIF_F_HW_CSUM in their features. This is what we do in the OOT version of this driver. That should also remove the need for this last patch.

Created attachment 442955 [details]
patchset to update sfc up to v2.6.36-rc1 for RHEL5.6 (bwh)

Here's the final patch series I've ended up with.

Thank you very much. I'm going to review your modifications and then post the series to our internal mailing list.

Posted:
http://post-office.corp.redhat.com/archives/rhkernel-list/2010-September/msg00293.html

One more thing: The patch
"linux-2.6-misc-add-thread-core-_siblings_list-to-sys.patch" renames the macros topology_core_siblings and topology_thread_siblings to topology_core_cpumask and topology_thread_cpumask.

sfc attempts to allocate one set of queues per package, falling back to one per core. It uses the macro topology_core_siblings, if defined, and therefore will always use the fallback now. Also, the topology_*_cpumask macros return a different type from their mainline implementations, so I don't think the renaming makes sense.

@solarflare, please confirm that you expect to test and verify this request is complete with RHEL 5.6.0 beta bits when they are available via RHN.

Otherwise, we will need to arrange for delivery of hardware before we can accept this into the 5.6 release

I would also like to understand whether there is an Issue Tracker associated with this request or if this request is not being pushed through our standard support request workflows?

(In reply to comment #16)
> @solarflare, please confirm that you expect to test and verify this request is
> complete with RHEL 5.6.0 beta bits when they are available via RHN.

I expect to do that anyway.

> Otherwise, we will need to arrange for delivery of hardware before we can
> accept this into the 5.6 release

We do have an outstanding order to send hardware to Michal. This has unfortunately been delayed but I understand he should receive it next week.

> I would also like to understand whether there is an Issue Tracker associated
> with this request or if this request is not being pushed through our standard
> support request workflows?

I'm not aware of any support request.

Okay, I ask because normally Feature requests come through our support group. 

This bug is also possibly labelled incorrectly, I believe it should have FutureFeature in the keywords field.

Good news. The two SFL9021 cards arrived to me already. Thanks!

(In reply to comment #15)
> One more thing: The patch
> "linux-2.6-misc-add-thread-core-_siblings_list-to-sys.patch" renames the macros
> topology_core_siblings and topology_thread_siblings to topology_core_cpumask
> and topology_thread_cpumask.
> 
> sfc attempts to allocate one set of queues per package, falling back to one per
> core. It uses the macro topology_core_siblings, if defined, and therefore will
> always use the fallback now. Also, the topology_*_cpumask macros return a
> different type from their mainline implementations, so I don't think the
> renaming makes sense.

Ben, I have created bug 633388 for this.

in kernel-2.6.18-221.el5
You can download this test kernel from http://people.redhat.com/jwilson/el5

Detailed testing feedback is always welcomed.

The Solarflare test group has completed testing of the sfc driver in kernel-2.6.18-222.el5 (which has the fix for bug 633388) and found no issues with it.

The fix for this bug contains the jiffies related fix required for the ALUA transitioning patch described in bug 619361. 

And we need the ALUA transitioning fix to be backported to 5.5.z. So could we please have this jiffies related fix backported to 5.5.z as well?

(In reply to comment #33)
> The fix for this bug contains the jiffies related fix required for the ALUA
> transitioning patch described in bug 619361. 
> 
> And we need the ALUA transitioning fix to be backported to 5.5.z. So could we
> please have this jiffies related fix backported to 5.5.z as well?

This comment doesn't seem to have anything to do with bug 556476.

I believe Martin is interested in the patch "add round_jiffies_up and related routines" which was added to the RHEL kernel because the updated sfc driver depended on it.

(In reply to comment #35)
> I believe Martin is interested in the patch "add round_jiffies_up and related
> routines" which was added to the RHEL kernel because the updated sfc driver
> depended on it.

Yes, that's right. This 'round_jiffies_up' routine is used in the ALUA transitioning fix described in bug 619361. Hence the request.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0017.html