Revision tags: v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7 |
|
#
49425dfc |
| 01-Apr-2016 |
Mark Rustad <mark.d.rustad@intel.com> |
ixgbe: Add support for x550em_a 10G MAC type
Add support for x550em_a 10G MAC type to the ixgbe driver. The new MAC includes new firmware commands that need to be used to control PHY and IOSF access
ixgbe: Add support for x550em_a 10G MAC type
Add support for x550em_a 10G MAC type to the ixgbe driver. The new MAC includes new firmware commands that need to be used to control PHY and IOSF access, so that support is also added. The interface supported is a native SFP+ interface.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1 |
|
#
93d05d4a |
| 18-Nov-2015 |
Eric Dumazet <edumazet@google.com> |
net: provide generic busy polling to all NAPI drivers
NAPI drivers no longer need to observe a particular protocol to benefit from busy polling (CONFIG_NET_RX_BUSY_POLL=y)
napi_hash_add() and napi_
net: provide generic busy polling to all NAPI drivers
NAPI drivers no longer need to observe a particular protocol to benefit from busy polling (CONFIG_NET_RX_BUSY_POLL=y)
napi_hash_add() and napi_hash_del() are automatically called from core networking stack, respectively from netif_napi_add() and netif_napi_del()
This patch depends on free_netdev() and netif_napi_del() being called from process context, which seems to be the norm.
Drivers might still prefer to call napi_hash_del() on their own, since they might combine all the rcu grace periods into a single one, knowing their NAPI structures lifetime, while core networking stack has no idea of a possible combining.
Once this patch proves to not bring serious regressions, we will cleanup drivers to either remove napi_hash_del() or provide appropriate rcu grace periods combining.
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5 |
|
#
8ac34f10 |
| 30-Jul-2015 |
Alexander Duyck <alexander.h.duyck@redhat.com> |
ixgbe: Limit lowest interrupt rate for adaptive interrupt moderation to 12K
This patch updates the lowest limit for adaptive interrupt interrupt moderation to roughly 12K interrupts per second.
The
ixgbe: Limit lowest interrupt rate for adaptive interrupt moderation to 12K
This patch updates the lowest limit for adaptive interrupt interrupt moderation to roughly 12K interrupts per second.
The way I came about reaching 12K as the desired interrupt rate is by testing with UDP flows. Specifically I had a simple test that ran a netperf UDP_STREAM test at varying sizes. What I found was as the packet sizes increased the performance fell steadily behind until we were only able to receive at ~4Gb/s with a message size of 65507. A bit of digging found that we were dropping packets for the socket in the network stack, and looking at things further what I found was I could solve it by increasing the interrupt rate, or increasing the rmem_default/rmem_max. What I found was that when the interrupt coalescing resulted in more data being processed per interrupt than could be stored in the socket buffer we started losing packets and the performance dropped. So I reached 12K based on the following math.
rmem_default = 212992 skb->truesize = 2994 212992 / 2994 = 71.14 packets to fill the buffer
packet rate at 1514 packet size is 812744pps 71.14 / 812744 = 87.9us to fill socket buffer
From there it was just a matter of choosing the interrupt rate and providing a bit of wiggle room which is why I decided to go with 12K interrupts per second as that uses a value of 84us.
The data below is based on VM to VM over a direct assigned ixgbe interface. The test run was: netperf -H <ip> -t UDP_STREAM"
Socket Message Elapsed Messages CPU Service Size Size Time Okay Errors Throughput Util Demand bytes bytes secs # # 10^6bits/sec % SS us/KB Before: 212992 65507 60.00 1100662 0 9613.4 10.89 0.557 212992 60.00 473474 4135.4 11.27 0.576
After: 212992 65507 60.00 1100413 0 9611.2 10.73 0.549 212992 60.00 974132 8508.3 11.69 0.598
Using bare metal the data is similar but not as dramatic as the throughput increases from about 8.5Gb/s to 9.5Gb/s.
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4 |
|
#
9a75a1ac |
| 06-Nov-2014 |
Don Skidmore <donald.c.skidmore@intel.com> |
ixgbe: Add new support for X550 MAC's
This patch will add in the new MAC defines and fit it into the switch cases throughout the driver. New functionality and enablement support will be added in fo
ixgbe: Add new support for X550 MAC's
This patch will add in the new MAC defines and fit it into the switch cases throughout the driver. New functionality and enablement support will be added in following patches.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4 |
|
#
d786cf7b |
| 03-Sep-2014 |
Jacob Keller <jacob.e.keller@intel.com> |
ixgbe: add warnings for other disabled features without MSI-X support
When we can't get MSI-X vectors, we disable a few features which require MSI-X vectors. Print warnings just like we do when disa
ixgbe: add warnings for other disabled features without MSI-X support
When we can't get MSI-X vectors, we disable a few features which require MSI-X vectors. Print warnings just like we do when disabling DCB.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
#
5d31b48a |
| 03-Sep-2014 |
Jacob Keller <jacob.e.keller@intel.com> |
ixgbe: use e_dev_warn instead of netif_printk
Again, we should not be directly using netif_printk, as we have our own error print routines that we generate. In addition, instead of using an early re
ixgbe: use e_dev_warn instead of netif_printk
Again, we should not be directly using netif_printk, as we have our own error print routines that we generate. In addition, instead of using an early return we can just use the else block of this one line if statement.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
#
c1c55f63 |
| 03-Sep-2014 |
Jacob Keller <jacob.e.keller@intel.com> |
ixgbe: use e_dev_warn instead of e_err for displaying warning
In this case, disabling DCB is not an error. We can still function, but we just have to let the user know. In addition, since we call th
ixgbe: use e_dev_warn instead of e_err for displaying warning
In this case, disabling DCB is not an error. We can still function, but we just have to let the user know. In addition, since we call this during probe before allocating our netdevice structure, we should use e_dev_warn instead of e_warn.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
#
3bcf3446 |
| 03-Sep-2014 |
Jacob Keller <jacob.e.keller@intel.com> |
ixgbe: determine vector count inside ixgbe_acquire_msix_vectors
Our calculated v_budget doesn't matter except if we allocate MSI-X vectors. We shouldn't need to calculate this outside of the functio
ixgbe: determine vector count inside ixgbe_acquire_msix_vectors
Our calculated v_budget doesn't matter except if we allocate MSI-X vectors. We shouldn't need to calculate this outside of the function, so don't. Instead, only calculate it once we attempt to acquire MSI-X vectors. This helps collocate all of the MSI-X vector code together.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
#
027bb561 |
| 03-Sep-2014 |
Jacob Keller <jacob.e.keller@intel.com> |
ixgbe: move msix_entries allocation into ixgbe_acquire_msix_vectors
We already have to kfree this value if we fail, and this is only part of MSI-X mode, so we should simply allocate the value where
ixgbe: move msix_entries allocation into ixgbe_acquire_msix_vectors
We already have to kfree this value if we fail, and this is only part of MSI-X mode, so we should simply allocate the value where we need it. This is cleaner, and makes it a lot more obvious why we are freeing it inside of ixgbe_acquire_msix_vectors.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
#
d7de3c6e |
| 03-Sep-2014 |
Jacob Keller <jacob.e.keller@intel.com> |
ixgbe: return integer from ixgbe_acquire_msix_vectors
Similar to how ixgbevf handles acquiring MSI-X vectors, we can return an error code instead of relying on the flag being set. This makes it more
ixgbe: return integer from ixgbe_acquire_msix_vectors
Similar to how ixgbevf handles acquiring MSI-X vectors, we can return an error code instead of relying on the flag being set. This makes it more clear that we have failed to setup MSI-X mode, and also will make it easier to consolidate MSI-X related code all into the single function.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
#
493043e5 |
| 03-Sep-2014 |
Jacob Keller <jacob.e.keller@intel.com> |
ixgbe: use e_dev_warn instead of netif_printk
The netif_printk relies on our netdevice structure to be registered already. We may call ixgbe_acquire_msix_vectors prior to registering our netdevice,
ixgbe: use e_dev_warn instead of netif_printk
The netif_printk relies on our netdevice structure to be registered already. We may call ixgbe_acquire_msix_vectors prior to registering our netdevice, so we should not use the netdevice specific printk.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7 |
|
#
adc81090 |
| 25-Jul-2014 |
Alexander Duyck <alexander.h.duyck@intel.com> |
ixgbe: Refactor busy poll socket code to address multiple issues
This change addresses several issues in the current ixgbe implementation of busy poll sockets.
First was the fact that it was possib
ixgbe: Refactor busy poll socket code to address multiple issues
This change addresses several issues in the current ixgbe implementation of busy poll sockets.
First was the fact that it was possible for frames to be delivered out of order if they were held in GRO. This is addressed by flushing the GRO buffers before releasing the q_vector back to the idle state.
The other issue was the fact that we were having to take a spinlock on changing the state to and from idle. To resolve this I have replaced the state value with an atomic and use atomic_cmpxchg to change the value from idle, and a simple atomic set to restore it back to idle after we have acquired it. This allows us to only use a locked operation on acquiring the vector without a need for a locked operation to release it.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
#
eec66731 |
| 21-Aug-2014 |
Jacob Keller <jacob.e.keller@intel.com> |
ixgbe: add comment noting recalculation of queues
Since we previously called ixgbe_set_num_queues just prior to attempting to set our interrupt scheme, it may be non obvious why we have to call it a
ixgbe: add comment noting recalculation of queues
Since we previously called ixgbe_set_num_queues just prior to attempting to set our interrupt scheme, it may be non obvious why we have to call it again inside the function. Add a comment which helps make it more obvious that we are resetting features based on the fact that we do not have MSI-X enabled, and cannot use the previous settings.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1 |
|
#
6ec1b71f |
| 09-Apr-2014 |
Jacob Keller <jacob.e.keller@intel.com> |
ixgbe: fix several concatenated strings to single line
This patch fixes various log strings that are split over multiple lines in the ixgbe driver. This cleans up checkpatch.pl warnings, and makes i
ixgbe: fix several concatenated strings to single line
This patch fixes various log strings that are split over multiple lines in the ixgbe driver. This cleans up checkpatch.pl warnings, and makes it easier to search the code for warning strings displayed to the kernel log.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4 |
|
#
b89aae71 |
| 21-Feb-2014 |
Jacob Keller <jacob.e.keller@intel.com> |
ixgbe: add Linux NICS mailing list to contact info
This patch updates the contact information on the ixgbe driver files so that every file includes the Linux NICS address, as it is still used, but o
ixgbe: add Linux NICS mailing list to contact info
This patch updates the contact information on the ixgbe driver files so that every file includes the Linux NICS address, as it is still used, but only a few of the files mentioned it.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
#
b45e620c |
| 18-Feb-2014 |
Alexander Gordeev <agordeev@redhat.com> |
ixgbe: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two in
ixgbe: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() and pci_enable_msix_range() interfaces.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Jesse Brandeburg <jesse.brandeburg@intel.com> Cc: Bruce Allan <bruce.w.allan@intel.com> Cc: e1000-devel@lists.sourceforge.net Cc: netdev@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v3.14-rc3, v3.14-rc2, v3.14-rc1, v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1 |
|
#
2a47fa45 |
| 06-Nov-2013 |
John Fastabend <john.r.fastabend@intel.com> |
ixgbe: enable l2 forwarding acceleration for macvlans
Now that l2 acceleration ops are in place from the prior patch, enable ixgbe to take advantage of these operations. Allow it to allocate queues
ixgbe: enable l2 forwarding acceleration for macvlans
Now that l2 acceleration ops are in place from the prior patch, enable ixgbe to take advantage of these operations. Allow it to allocate queues for a macvlan so that when we transmit a frame, we can do the switching in hardware inside the ixgbe card, rather than in software.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Signed-off-by: Neil Horman <nhorman@tuxdriver.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: "David S. Miller" <davem@davemloft.net> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v3.12, v3.12-rc7, v3.12-rc6, v3.12-rc5, v3.12-rc4, v3.12-rc3, v3.12-rc2, v3.12-rc1, v3.11, v3.11-rc7, v3.11-rc6, v3.11-rc5, v3.11-rc4, v3.11-rc3, v3.11-rc2, v3.11-rc1, v3.10, v3.10-rc7, v3.10-rc6 |
|
#
5a85e737 |
| 10-Jun-2013 |
Eliezer Tamir <eliezer.tamir@linux.intel.com> |
ixgbe: add support for ndo_ll_poll
Add the ixgbe driver code implementing ndo_ll_poll. Adds ndo_ll_poll method and locking between it and the napi poll. When receiving a packet we use skb_mark_ll to
ixgbe: add support for ndo_ll_poll
Add the ixgbe driver code implementing ndo_ll_poll. Adds ndo_ll_poll method and locking between it and the napi poll. When receiving a packet we use skb_mark_ll to record the napi it came from. Add each napi to the napi_hash right after netif_napi_add().
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Eliezer Tamir <eliezer.tamir@linux.intel.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v3.10-rc5, v3.10-rc4, v3.10-rc3, v3.10-rc2, v3.10-rc1, v3.9, v3.9-rc8, v3.9-rc7, v3.9-rc6, v3.9-rc5, v3.9-rc4, v3.9-rc3, v3.9-rc2, v3.9-rc1, v3.8, v3.8-rc7, v3.8-rc6, v3.8-rc5, v3.8-rc4 |
|
#
fd786b7b |
| 12-Jan-2013 |
Alexander Duyck <alexander.h.duyck@intel.com> |
ixgbe: Add function for setting XPS queue mapping
This change adds support for ixgbe to configure the XPS queue mapping on load. The result of this change is that on open we will now be resetting t
ixgbe: Add function for setting XPS queue mapping
This change adds support for ixgbe to configure the XPS queue mapping on load. The result of this change is that on open we will now be resetting the number of Tx queues, and then setting the default configuration for XPS based on if ATR is enabled or disabled.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Reviewed-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
#
d3cb9869 |
| 15-Jan-2013 |
Alexander Duyck <alexander.h.duyck@intel.com> |
ixgbe: Define FCoE and Flow director limits much sooner to allow for changes
Instead of adjusting the FCoE and Flow director limits based on the number of CPUs we can define them much sooner. This
ixgbe: Define FCoE and Flow director limits much sooner to allow for changes
Instead of adjusting the FCoE and Flow director limits based on the number of CPUs we can define them much sooner. This allows the user to come through later and adjust them once we have updated the code to support the set_channels ethtool operation.
I am still allowing for FCoE and RSS queues to be separated if the number queues is less than the number of CPUs. This essentially treats the two groupings like they are two separate traffic classes.
In addition I am changing the initialization to use the MAX_TX/RX_QUEUES defines instead of trying to compute the value as it will be possible in upcoming patches for the user to request the maximum number of queues.
I have also updated things so that the upper limit on queues is exactly 63 instead of allowing it to go up to 64. The reason for this change is to address the fact thqt the driver only supports up to 63 queue vectors since the hardware supports 64 MSI-X vectors, but one must be reserved for "other" causes.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v3.8-rc3 |
|
#
434c5e39 |
| 07-Jan-2013 |
Don Skidmore <donald.c.skidmore@intel.com> |
ixgbe: update date to 2013
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
Revision tags: v3.8-rc2, v3.8-rc1, v3.7, v3.7-rc8, v3.7-rc7, v3.7-rc6, v3.7-rc5, v3.7-rc4, v3.7-rc3 |
|
#
3af3361e |
| 24-Oct-2012 |
Emil Tantilov <emil.s.tantilov@intel.com> |
ixgbe: fix default setting of TXDCTL.WTHRESH
The q_vector->itr check in ixgbe_configure_tx_ring() was done prior to it being set, which resulted in TXDCTL.WTHRESH always being set to 1 on driver loa
ixgbe: fix default setting of TXDCTL.WTHRESH
The q_vector->itr check in ixgbe_configure_tx_ring() was done prior to it being set, which resulted in TXDCTL.WTHRESH always being set to 1 on driver load, while consequent resets would set it to 8.
This patch moves the setting of q_vector->itr in ixgbe_alloc_q_vector() to make sure that TXDCTL.WTHRESH is set to 8 by default.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v3.7-rc2, v3.7-rc1, v3.6, v3.6-rc7, v3.6-rc6, v3.6-rc5, v3.6-rc4, v3.6-rc3, v3.6-rc2, v3.6-rc1 |
|
#
245f292d |
| 27-Jul-2012 |
Alexander Duyck <alexander.h.duyck@intel.com> |
ixgbe: Initialize q_vector cpu and affinity masks correctly
When enabling DCB the rings belonging to a q_vector on CPU 0 were not reinitializing their DCA registers. Upon closer inspection the issu
ixgbe: Initialize q_vector cpu and affinity masks correctly
When enabling DCB the rings belonging to a q_vector on CPU 0 were not reinitializing their DCA registers. Upon closer inspection the issue was that the q_vector CPU variable was left at 0 resulting in the driver not updating the DCA registers.
In order to guarantee the DCA registers will be updated I am adding a couple line change so that we initialize the CPU variable to -1 which will force a DCA update the first time an interrupt fires on that q_vector.
In addition we were setting the CPU affinity hint to all CPUs when we were not specifying a CPU. Instead we should leave it as all zeros to avoid any possible confusion about the fact that we shouldn't be giving a hint.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v3.5 |
|
#
b724e9f2 |
| 16-Jul-2012 |
Alexander Duyck <alexander.h.duyck@intel.com> |
ixgbe: Use 1TC DCB instead of disabling DCB for MSI and legacy interrupts
This change makes it so that we can use 1TC DCB in the case of MSI and legacy interrupts. The advantage to this is that it
ixgbe: Use 1TC DCB instead of disabling DCB for MSI and legacy interrupts
This change makes it so that we can use 1TC DCB in the case of MSI and legacy interrupts. The advantage to this is that it allows us to fully support FCoE w/ DCB instead of having to drop to link flow control only when using these interrupt modes.
Cc: John Fastabend <john.r.fastabend@intel.com> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v3.5-rc7, v3.5-rc6, v3.5-rc5, v3.5-rc4, v3.5-rc3, v3.5-rc2 |
|
#
39cb681b |
| 06-Jun-2012 |
Alexander Duyck <alexander.h.duyck@intel.com> |
ixgbe: Fix handling of FDIR_HASH flag
This change makes it so that we can use the atr_sample_rate to determine if we are capable of supporting ATR. The advantage to this approach is that it allows u
ixgbe: Fix handling of FDIR_HASH flag
This change makes it so that we can use the atr_sample_rate to determine if we are capable of supporting ATR. The advantage to this approach is that it allows us to now determine the setting of the IXGBE_FLAG_FDIR_HASH_CAPABLE based on the queueing scheme, instead of the queueing scheme being based on the flag.
Using this approach there are essentially 5 conditions that must be checked prior to trying to enable ATR: 1. Is SR-IOV disabled? 2. Are the number of TCs <= 1? 3. Is RSS queueing limit greater than 1? 4. Is atr_sample_rate set? 5. Is Flow Director perfect filtering disabled?
If any of these conditions are enabled they should disable ATR filtering. Note that in the case of conditions 1 through 4 being met we will set things up for ATR queueing, however if test 5 fails we will still leave the queues allocated for use by perfect filters. The reason for this is to allow for us to switch back and forth between ntuple and ATR without needing to reallocate the descriptor rings.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|