<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/ethernet/intel, branch linux-4.3.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.3.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.3.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2015-10-23T01:06:18Z</updated>
<entry>
<title>i40e: fix annoying message</title>
<updated>2015-10-23T01:06:18Z</updated>
<author>
<name>Jesse Brandeburg</name>
<email>jesse.brandeburg@intel.com</email>
</author>
<published>2015-10-03T00:57:21Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e9e53662d8130dd950885e37dc1d97008e1283f9'/>
<id>urn:sha1:e9e53662d8130dd950885e37dc1d97008e1283f9</id>
<content type='text'>
The driver was printing a message about not being able
to assign VMDq because of a lack of MSI-X vectors.

This was because a line was missing that initialized a variable,
simply a merge error.

Signed-off-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
</entry>
<entry>
<title>i40e: fix stats offsets</title>
<updated>2015-10-23T00:48:21Z</updated>
<author>
<name>Jesse Brandeburg</name>
<email>jesse.brandeburg@intel.com</email>
</author>
<published>2015-10-03T02:09:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=74a6c66565f5f4eda4aaae53e2e325deeedeaca2'/>
<id>urn:sha1:74a6c66565f5f4eda4aaae53e2e325deeedeaca2</id>
<content type='text'>
The code was setting up stats that were not being initialized.
This caused several counters to be displayed incorrectly, due
to indexing beyond the array of strings when printing stats.

Signed-off-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
</entry>
<entry>
<title>i40e/i40evf: set AQ count after memory allocation</title>
<updated>2015-10-07T11:13:50Z</updated>
<author>
<name>Mitch Williams</name>
<email>mitch.a.williams@intel.com</email>
</author>
<published>2015-10-04T00:13:05Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=90d2c056bd85bbb47104c52e08eecf8408163a54'/>
<id>urn:sha1:90d2c056bd85bbb47104c52e08eecf8408163a54</id>
<content type='text'>
The standard way to check if the AQ is enabled is to look at the
count field. So we should only set this field after we have
successfully allocated memory. To do otherwise is to incite
panic among the populace.

Signed-off-by: Mitch Williams &lt;mitch.a.williams@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>i40e: fix offload of GRE tunnels</title>
<updated>2015-10-05T11:31:41Z</updated>
<author>
<name>Jesse Brandeburg</name>
<email>jesse.brandeburg@intel.com</email>
</author>
<published>2015-10-02T01:25:42Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fec31ffffa6e05845ab13908d0ac0d5a10816836'/>
<id>urn:sha1:fec31ffffa6e05845ab13908d0ac0d5a10816836</id>
<content type='text'>
The driver still was not offloading TSO on GRE tunnels because
it forgot to set the GSO_GRE flag, causing lots of retransmits.

This fixes generic GRE traffic (like a tunnel added like below)
whereas before it would get 1Gb/s or less, now on a 10G adapter
it gets 8.7Gb/s.

ip ad ad 11.1.0.2/24 dev ens2f0
ip l set ens2f0 up
ip link add gre2 type gretap remote 11.1.0.1 local 11.1.0.2 dev ens2f0
ip l set gre2 up
ip ad ad 192.168.124.2/24 dev gre2
ping 192.168.124.1
netperf -H 192.168.124.1

Signed-off-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>i40e/i40evf: check for stopped admin queue</title>
<updated>2015-09-29T03:57:14Z</updated>
<author>
<name>Mitch Williams</name>
<email>mitch.a.williams@intel.com</email>
</author>
<published>2015-09-29T00:31:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=43ae93a93e8c95c5e6389dc8e11704712b1ab2e9'/>
<id>urn:sha1:43ae93a93e8c95c5e6389dc8e11704712b1ab2e9</id>
<content type='text'>
It's possible that while we are waiting for the spinlock, another
entity (that owns the spinlock) has shut down the admin queue.
If we then attempt to use the queue, we will panic.

Add a check for this condition on the receive side. This matches
an existing check on the send queue side.

Signed-off-by: Mitch Williams &lt;mitch.a.williams@intel.com&gt;
Acked-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>i40e: fix VLAN inside VXLAN</title>
<updated>2015-09-29T03:56:58Z</updated>
<author>
<name>Jesse Brandeburg</name>
<email>jesse.brandeburg@intel.com</email>
</author>
<published>2015-09-28T18:21:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c4bbac3913c0d649898a0d767728a585869a7d7d'/>
<id>urn:sha1:c4bbac3913c0d649898a0d767728a585869a7d7d</id>
<content type='text'>
Previously to this patch, the hardware was removing
VLAN tags from the inner header of VXLAN packets.  The
hardware configuration can be changed to leave the
packet alone since that is what the linux stack
expects for this type of VLAN in VXLAN packet.

Signed-off-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ixgbe: Resolve "initialized field overwritten" warnings</title>
<updated>2015-09-02T00:20:02Z</updated>
<author>
<name>Mark Rustad</name>
<email>mark.d.rustad@intel.com</email>
</author>
<published>2015-07-29T23:00:38Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=990a2d6ed543bd18b864b8a11f7be3368c67ccea'/>
<id>urn:sha1:990a2d6ed543bd18b864b8a11f7be3368c67ccea</id>
<content type='text'>
Resolve warnings resulting from redundant initialization of the
get_bus_info field in the mac_ops_X550* structures.

Signed-off-by: Mark Rustad &lt;mark.d.rustad@intel.com&gt;
Tested-by: Phil Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
</entry>
<entry>
<title>ixgbe: Remove bimodal SR-IOV disabling</title>
<updated>2015-09-02T00:17:41Z</updated>
<author>
<name>Alex Williamson</name>
<email>alex.williamson@redhat.com</email>
</author>
<published>2015-07-10T21:31:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7837e2867f56ec4435e75af54236732885303694'/>
<id>urn:sha1:7837e2867f56ec4435e75af54236732885303694</id>
<content type='text'>
When unbinding an SR-IOV device with VFs configured from ixgbe, the
driver behaves in one of two ways.  If max_vfs was specified, the
SR-IOV state is disabled, removing the VFs.  The occurs regardless of
whether the VF count was later modified through sysfs.  If however
max_vfs is zero, such as by not specifying the module parameter, the
VFs persist after the PF is unbound from ixgbe.  If the PF is then
bound to vfio-pci to be assigned to a VM, the PF is non-functional.

&gt;From the comment, commit da36b64736cf ("ixgbe: Implement PCI SR-IOV
sysfs callback operation") clearly intended this alternate behavior,
but probably didn't realize the PF doesn't work in this mode.

This bimodal behavior is confusing to users and results in a state
where the PF is broken for other uses unless the user sets
sriov_numvfs to zero prior to unbinding the device.  Remove this
behavior so that VFs are removed and the PF is functional for other
uses after unbind, regardless of the way VFs are enabled.

Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Acked-by: Greg Rose &lt;gregory.v.rose@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
</entry>
<entry>
<title>ixgbe: Add support for reporting 2.5G link speed</title>
<updated>2015-09-02T00:15:20Z</updated>
<author>
<name>Mark Rustad</name>
<email>mark.d.rustad@intel.com</email>
</author>
<published>2015-07-10T21:19:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=454adb008d78e4ecdfec3f2e5e9eb08ee5a60f1a'/>
<id>urn:sha1:454adb008d78e4ecdfec3f2e5e9eb08ee5a60f1a</id>
<content type='text'>
Now that we can do 2.5G link speed, we need to be able to report it.
Also change the nested triadic involved in creating the log message
to instead use a simpler switch statement to set a string pointer.

Signed-off-by: Mark Rustad &lt;mark.d.rustad@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
</entry>
<entry>
<title>ixgbe: fix bounds checking in ixgbe_setup_tc for 82598</title>
<updated>2015-09-02T00:13:00Z</updated>
<author>
<name>Emil Tantilov</name>
<email>emil.s.tantilov@intel.com</email>
</author>
<published>2015-07-09T19:28:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7e3f5c8881ba45eba1c74344b00558920008e6e6'/>
<id>urn:sha1:7e3f5c8881ba45eba1c74344b00558920008e6e6</id>
<content type='text'>
This patch resolves an issue where users were not able to dynamically
set number of queues for 82598 via ethtool -L

Reported-by: Tal Abudi &lt;talabudi@gmail.com&gt;
Signed-off-by: Emil Tantilov &lt;emil.s.tantilov@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
</entry>
</feed>
