* [net-next 0/6 v3][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2011-10-18 0:12 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
The following series contains updates to ixgbe, igbvf and igb.
This version of the series contains the following changes:
- igb fix/add check if subordinate VFs are assigned to VM's
- igbvf fix for trunk VLAN
- ixgbe 2 fixes for ethtool and 1 endianess fix
-v2 update the igb patch to resolve a variable initialization warning
-v3 Drop patch 5 (ixgbe: add hardware time stamping support)
The following are changes since commit fd38f734cb8200529e281338514945fcbff2364b:
igbvf: convert to ndo_fix_features
and are available in the git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
Emil Tantilov (3):
ixgbe: fix endianess when writing driver version to firmware
ixgbe: allow eeprom writes via ethtool
ixgbe: change the eeprom version reported by ethtool
Greg Rose (2):
igbvf: Fix trunk vlan
igb: Check if subordinate VFs are assigned to virtual machines
drivers/net/ethernet/intel/igb/igb.h | 3 +
drivers/net/ethernet/intel/igb/igb_main.c | 177 ++++++++++++++++++----
drivers/net/ethernet/intel/igbvf/netdev.c | 4 +-
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 2 +
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 16 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 84 ++++++++++-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 +-
8 files changed, 246 insertions(+), 50 deletions(-)
--
1.7.6.4
^ permalink raw reply
* [net-next 2/5] igb: Check if subordinate VFs are assigned to virtual machines
From: Jeff Kirsher @ 2011-10-18 0:12 UTC (permalink / raw)
To: davem
Cc: Greg Rose, netdev, gospo, sassmann, Konrad Rzeszutek Wilk,
Christian Benvenuti, Sathya Perla, Dimitris Michailidis,
Jon Mason, James Smart, Jeff Kirsher
In-Reply-To: <1318896767-5374-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Greg Rose <gregory.v.rose@intel.com>
Kvm and the Xen pci-back driver will set a flag in the virtual function
pci device dev_flags when the VF is assigned to a guest VM. Before
destroying subordinate VFs check to see if the flag is set and if so
skip the call to pci_disable_sriov() to avoid system crashes.
Copy the maintainer for the Xen pci-back driver. Also CC'ing
maintainers of all drivers found to call pci_disable_sriov().
V2 - Fix uninitialized variable warning
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Christian Benvenuti <benve@cisco.com>
Cc: Sathya Perla <sathya.perla@emulex.com>
Cc: Dimitris Michailidis <dm@chelsio.com>
Cc: Jon Mason <jdmason@kudzu.us>
Cc: James Smart <james.smart@emulex.com>
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb.h | 3 +
drivers/net/ethernet/intel/igb/igb_main.c | 177 ++++++++++++++++++++++++-----
2 files changed, 150 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index 4c500a7..5594430 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -72,6 +72,8 @@ struct igb_adapter;
#define IGB_MAX_VF_MC_ENTRIES 30
#define IGB_MAX_VF_FUNCTIONS 8
#define IGB_MAX_VFTA_ENTRIES 128
+#define IGB_82576_VF_DEV_ID 0x10CA
+#define IGB_I350_VF_DEV_ID 0x1520
struct vf_data_storage {
unsigned char vf_mac_addresses[ETH_ALEN];
@@ -83,6 +85,7 @@ struct vf_data_storage {
u16 pf_vlan; /* When set, guest VLAN config not allowed. */
u16 pf_qos;
u16 tx_rate;
+ struct pci_dev *vfdev;
};
#define IGB_VF_FLAG_CTS 0x00000001 /* VF is clear to send data */
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index c10cc71..837adbb 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -162,6 +162,9 @@ static int igb_ndo_set_vf_bw(struct net_device *netdev, int vf, int tx_rate);
static int igb_ndo_get_vf_config(struct net_device *netdev, int vf,
struct ifla_vf_info *ivi);
static void igb_check_vf_rate_limit(struct igb_adapter *);
+static int igb_vf_configure(struct igb_adapter *adapter, int vf);
+static int igb_find_enabled_vfs(struct igb_adapter *adapter);
+static int igb_check_vf_assignment(struct igb_adapter *adapter);
#ifdef CONFIG_PM
static int igb_suspend(struct pci_dev *, pm_message_t);
@@ -2232,8 +2235,12 @@ static void __devexit igb_remove(struct pci_dev *pdev)
/* reclaim resources allocated to VFs */
if (adapter->vf_data) {
/* disable iov and allow time for transactions to clear */
- pci_disable_sriov(pdev);
- msleep(500);
+ if (!igb_check_vf_assignment(adapter)) {
+ pci_disable_sriov(pdev);
+ msleep(500);
+ } else {
+ dev_info(&pdev->dev, "VF(s) assigned to guests!\n");
+ }
kfree(adapter->vf_data);
adapter->vf_data = NULL;
@@ -2270,42 +2277,49 @@ static void __devinit igb_probe_vfs(struct igb_adapter * adapter)
{
#ifdef CONFIG_PCI_IOV
struct pci_dev *pdev = adapter->pdev;
+ int old_vfs = igb_find_enabled_vfs(adapter);
+ int i;
- if (adapter->vfs_allocated_count) {
- adapter->vf_data = kcalloc(adapter->vfs_allocated_count,
- sizeof(struct vf_data_storage),
- GFP_KERNEL);
- /* if allocation failed then we do not support SR-IOV */
- if (!adapter->vf_data) {
- adapter->vfs_allocated_count = 0;
- dev_err(&pdev->dev, "Unable to allocate memory for VF "
- "Data Storage\n");
- }
+ if (old_vfs) {
+ dev_info(&pdev->dev, "%d pre-allocated VFs found - override "
+ "max_vfs setting of %d\n", old_vfs, max_vfs);
+ adapter->vfs_allocated_count = old_vfs;
}
- if (pci_enable_sriov(pdev, adapter->vfs_allocated_count)) {
- kfree(adapter->vf_data);
- adapter->vf_data = NULL;
-#endif /* CONFIG_PCI_IOV */
+ if (!adapter->vfs_allocated_count)
+ return;
+
+ adapter->vf_data = kcalloc(adapter->vfs_allocated_count,
+ sizeof(struct vf_data_storage), GFP_KERNEL);
+ /* if allocation failed then we do not support SR-IOV */
+ if (!adapter->vf_data) {
adapter->vfs_allocated_count = 0;
-#ifdef CONFIG_PCI_IOV
- } else {
- unsigned char mac_addr[ETH_ALEN];
- int i;
- dev_info(&pdev->dev, "%d vfs allocated\n",
- adapter->vfs_allocated_count);
- for (i = 0; i < adapter->vfs_allocated_count; i++) {
- random_ether_addr(mac_addr);
- igb_set_vf_mac(adapter, i, mac_addr);
- }
- /* DMA Coalescing is not supported in IOV mode. */
- if (adapter->flags & IGB_FLAG_DMAC)
- adapter->flags &= ~IGB_FLAG_DMAC;
+ dev_err(&pdev->dev, "Unable to allocate memory for VF "
+ "Data Storage\n");
+ goto out;
}
+
+ if (!old_vfs) {
+ if (pci_enable_sriov(pdev, adapter->vfs_allocated_count))
+ goto err_out;
+ }
+ dev_info(&pdev->dev, "%d VFs allocated\n",
+ adapter->vfs_allocated_count);
+ for (i = 0; i < adapter->vfs_allocated_count; i++)
+ igb_vf_configure(adapter, i);
+
+ /* DMA Coalescing is not supported in IOV mode. */
+ adapter->flags &= ~IGB_FLAG_DMAC;
+ goto out;
+err_out:
+ kfree(adapter->vf_data);
+ adapter->vf_data = NULL;
+ adapter->vfs_allocated_count = 0;
+out:
+ return;
#endif /* CONFIG_PCI_IOV */
}
-
/**
* igb_init_hw_timer - Initialize hardware timer used with IEEE 1588 timestamp
* @adapter: board private structure to initialize
@@ -4917,6 +4931,109 @@ static int igb_notify_dca(struct notifier_block *nb, unsigned long event,
}
#endif /* CONFIG_IGB_DCA */
+#ifdef CONFIG_PCI_IOV
+static int igb_vf_configure(struct igb_adapter *adapter, int vf)
+{
+ unsigned char mac_addr[ETH_ALEN];
+ struct pci_dev *pdev = adapter->pdev;
+ struct e1000_hw *hw = &adapter->hw;
+ struct pci_dev *pvfdev;
+ unsigned int device_id;
+ u16 thisvf_devfn;
+
+ random_ether_addr(mac_addr);
+ igb_set_vf_mac(adapter, vf, mac_addr);
+
+ switch (adapter->hw.mac.type) {
+ case e1000_82576:
+ device_id = IGB_82576_VF_DEV_ID;
+ /* VF Stride for 82576 is 2 */
+ thisvf_devfn = (pdev->devfn + 0x80 + (vf << 1)) |
+ (pdev->devfn & 1);
+ break;
+ case e1000_i350:
+ device_id = IGB_I350_VF_DEV_ID;
+ /* VF Stride for I350 is 4 */
+ thisvf_devfn = (pdev->devfn + 0x80 + (vf << 2)) |
+ (pdev->devfn & 3);
+ break;
+ default:
+ device_id = 0;
+ thisvf_devfn = 0;
+ break;
+ }
+
+ pvfdev = pci_get_device(hw->vendor_id, device_id, NULL);
+ while (pvfdev) {
+ if (pvfdev->devfn == thisvf_devfn)
+ break;
+ pvfdev = pci_get_device(hw->vendor_id,
+ device_id, pvfdev);
+ }
+
+ if (pvfdev)
+ adapter->vf_data[vf].vfdev = pvfdev;
+ else
+ dev_err(&pdev->dev,
+ "Couldn't find pci dev ptr for VF %4.4x\n",
+ thisvf_devfn);
+ return pvfdev != NULL;
+}
+
+static int igb_find_enabled_vfs(struct igb_adapter *adapter)
+{
+ struct e1000_hw *hw = &adapter->hw;
+ struct pci_dev *pdev = adapter->pdev;
+ struct pci_dev *pvfdev;
+ u16 vf_devfn = 0;
+ u16 vf_stride;
+ unsigned int device_id;
+ int vfs_found = 0;
+
+ switch (adapter->hw.mac.type) {
+ case e1000_82576:
+ device_id = IGB_82576_VF_DEV_ID;
+ /* VF Stride for 82576 is 2 */
+ vf_stride = 2;
+ break;
+ case e1000_i350:
+ device_id = IGB_I350_VF_DEV_ID;
+ /* VF Stride for I350 is 4 */
+ vf_stride = 4;
+ break;
+ default:
+ device_id = 0;
+ vf_stride = 0;
+ break;
+ }
+
+ vf_devfn = pdev->devfn + 0x80;
+ pvfdev = pci_get_device(hw->vendor_id, device_id, NULL);
+ while (pvfdev) {
+ if (pvfdev->devfn == vf_devfn)
+ vfs_found++;
+ vf_devfn += vf_stride;
+ pvfdev = pci_get_device(hw->vendor_id,
+ device_id, pvfdev);
+ }
+
+ return vfs_found;
+}
+
+static int igb_check_vf_assignment(struct igb_adapter *adapter)
+{
+ int i;
+ for (i = 0; i < adapter->vfs_allocated_count; i++) {
+ if (adapter->vf_data[i].vfdev) {
+ if (adapter->vf_data[i].vfdev->dev_flags &
+ PCI_DEV_FLAGS_ASSIGNED)
+ return true;
+ }
+ }
+ return false;
+}
+
+#endif
static void igb_ping_all_vfs(struct igb_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
--
1.7.6.4
^ permalink raw reply related
* [net-next 1/5] igbvf: Fix trunk vlan
From: Jeff Kirsher @ 2011-10-18 0:12 UTC (permalink / raw)
To: davem; +Cc: Greg Rose, netdev, gospo, sassmann, Jiri Pirko, Jeff Kirsher
In-Reply-To: <1318896767-5374-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Greg Rose <gregory.v.rose@intel.com>
Changes to clean up the VLAN Rx path by Jiri Pirko broke trunk VLAN.
Trunk VLANs in a VF driver are those set using
"ip link set <pfdev> vf <n> <vlanid>"
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
CC: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igbvf/netdev.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index 32b3044..23cc40f 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -102,8 +102,8 @@ static void igbvf_receive_skb(struct igbvf_adapter *adapter,
{
if (status & E1000_RXD_STAT_VP) {
u16 vid = le16_to_cpu(vlan) & E1000_RXD_SPC_VLAN_MASK;
-
- __vlan_hwaccel_put_tag(skb, vid);
+ if (test_bit(vid, adapter->active_vlans))
+ __vlan_hwaccel_put_tag(skb, vid);
}
netif_receive_skb(skb);
}
--
1.7.6.4
^ permalink raw reply related
* Re: [PATCH 2/2] bridge: allow forwarding some link local frames
From: John Fastabend @ 2011-10-18 0:00 UTC (permalink / raw)
To: Ed Swierk
Cc: Brattain, Ross B, Stephen Hemminger, David S. Miller,
netdev@vger.kernel.org
In-Reply-To: <CAF5U64A-o0WHMGZ=x3kRd-bOnscra=oLu8uFju=HB=CF4zNiXQ@mail.gmail.com>
On 10/17/2011 4:36 PM, Ed Swierk wrote:
> On Mon, Oct 17, 2011 at 4:07 PM, Ross Brattain
> <ross.b.brattain@intel.com> wrote:
>> 802.1AB-2009 Section 7.1 Destination address:
>>
>> NOTE 8—The destination MAC address used by a given LLDP agent defines only the scope of transmission and the
>> intended recipient(s) of the LLDPDUs; it plays no part in protocol identification. In particular, the group MAC addresses
>> identified in Table 7-1 are not used exclusively by LLDP; other protocols that require to use a similar transmission scope
>> are free to use the same addresses.
>> ...
>> If you control both end stations you could use the optional group MAC address support, or unicast LLDP.
>>
>> 802.1AB-2009 Section 7.1 Destination address:
>>
>> In addition to the prescribed support for standard group MAC addresses shown in Table 7-1,
>> implementations of LLDP may support the following destination addresses for LLDPDUs:
>> d) Any group MAC address.
>> e) Any individual MAC address.
>> Support for the use of each of these destination addresses, for both transmission and reception of LLDPDUs,
>> is either mandatory, recommended, permitted, or not permitted, according to the type of system in which
>> LLDP is implemented, as shown in Table 7-2.
>
> Thanks for the references. I need to read the updated standards specs
> before jumping to conclusions...
>
>> I have no idea if any LLDP agents support the optional group MAC addresses.
>
> In our application we're both generating and consuming the LLDP
> frames. We're worried about standards conformance to the extent that
> we don't break other tools that might receive the LLDP frames we
> generate. As long as they don't care about the destination MAC address
> of the frames they receive (and they shouldn't), it's definitely
> feasible for us to use the "nearest customer bridge" address
> (01-80-C2-00-00-00) to ensure our LLDP frames traverse Linux bridges.
>
> --Ed
Ed,
Its unclear what you mean by "and they shouldn't". If the other tool
is an LLDP daemon then it will receive the frame and process it as
a nearest customer bridge LLDPDU.
However it looks like your on the right track here. If your adding
a standard TLV you might consider adding support to an existing
agent. For example 'lldpad'.
Thanks,
John.
^ permalink raw reply
* Re: [PATCH] route: fix ICMP redirect validation
From: David Miller @ 2011-10-17 23:43 UTC (permalink / raw)
To: fbl; +Cc: netdev
In-Reply-To: <1317824404-9513-1-git-send-email-fbl@redhat.com>
From: Flavio Leitner <fbl@redhat.com>
Date: Wed, 5 Oct 2011 11:20:04 -0300
> The commit f39925dbde7788cfb96419c0f092b086aa325c0f
> (ipv4: Cache learned redirect information in inetpeer.)
> removed some ICMP packet validations which are required by
> RFC 1122, section 3.2.2.2:
> ...
> A Redirect message SHOULD be silently discarded if the new
> gateway address it specifies is not on the same connected
> (sub-) net through which the Redirect arrived [INTRO:2,
> Appendix A], or if the source of the Redirect is not the
> current first-hop gateway for the specified destination (see
> Section 3.3.1).
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
The reason for putting this into the inetpeer cache was so that we
didn't need to consult the routing cache at all. We're working to
remove it at some point, so every dependency matters.
Can you implement this such that only an inetpeer cache probe is
necessary?
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] bridge: allow forwarding some link local frames
From: Ed Swierk @ 2011-10-17 23:36 UTC (permalink / raw)
To: Ross Brattain; +Cc: Stephen Hemminger, David S. Miller, netdev@vger.kernel.org
In-Reply-To: <20111017160715.000024eb@unknown>
On Mon, Oct 17, 2011 at 4:07 PM, Ross Brattain
<ross.b.brattain@intel.com> wrote:
> 802.1AB-2009 Section 7.1 Destination address:
>
> NOTE 8—The destination MAC address used by a given LLDP agent defines only the scope of transmission and the
> intended recipient(s) of the LLDPDUs; it plays no part in protocol identification. In particular, the group MAC addresses
> identified in Table 7-1 are not used exclusively by LLDP; other protocols that require to use a similar transmission scope
> are free to use the same addresses.
> ...
> If you control both end stations you could use the optional group MAC address support, or unicast LLDP.
>
> 802.1AB-2009 Section 7.1 Destination address:
>
> In addition to the prescribed support for standard group MAC addresses shown in Table 7-1,
> implementations of LLDP may support the following destination addresses for LLDPDUs:
> d) Any group MAC address.
> e) Any individual MAC address.
> Support for the use of each of these destination addresses, for both transmission and reception of LLDPDUs,
> is either mandatory, recommended, permitted, or not permitted, according to the type of system in which
> LLDP is implemented, as shown in Table 7-2.
Thanks for the references. I need to read the updated standards specs
before jumping to conclusions...
> I have no idea if any LLDP agents support the optional group MAC addresses.
In our application we're both generating and consuming the LLDP
frames. We're worried about standards conformance to the extent that
we don't break other tools that might receive the LLDP frames we
generate. As long as they don't care about the destination MAC address
of the frames they receive (and they shouldn't), it's definitely
feasible for us to use the "nearest customer bridge" address
(01-80-C2-00-00-00) to ensure our LLDP frames traverse Linux bridges.
--Ed
^ permalink raw reply
* Re: x25: Fix multiple buffer overruns/overreads
From: David Miller @ 2011-10-17 23:32 UTC (permalink / raw)
To: mattjd; +Cc: netdev, eric.dumazet, andrew.hendry
In-Reply-To: <1318653905-13716-1-git-send-email-mattjd@gmail.com>
From: Matthew Daley <mattjd@gmail.com>
Date: Sat, 15 Oct 2011 00:45:02 -0400
> This patchset fixes several buffer overruns/overreads in the X.25
> packet layer. The first patch fixes a particularly nasty remote-triggerable
> buffer overflow, while the rest fix skb overreads on undersized/fragmented
> skbs.
All applied, thanks Matthew!
^ permalink raw reply
* Re: [PATCH net-next] ipv6: remove a rcu_read_lock in ndisc_constructor
From: David Miller @ 2011-10-17 23:28 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev
In-Reply-To: <1317707015-2432-1-git-send-email-rongqing.li@windriver.com>
From: <rongqing.li@windriver.com>
Date: Tue, 4 Oct 2011 13:43:35 +0800
> From: Roy.Li <rongqing.li@windriver.com>
>
> in6_dev_get(dev) takes a reference on struct inet6_dev, we dont need
> rcu locking in ndisc_constructor()
>
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] MAINTAINERS: can: the mailinglist moved to vger.kernel.org
From: David Miller @ 2011-10-17 23:23 UTC (permalink / raw)
To: mkl; +Cc: linux-can, netdev
In-Reply-To: <1318879920-25280-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 17 Oct 2011 21:31:58 +0200
> Hello,
>
> the BerliOS project will close with the end of the year, so we moved our
> mailinglist to vger.kernel.org, it's now linux-can@vger.kernel.org.
>
> This patch series change the mailinglist in MAINTAINERS and remove all other
> references from the source tree. As David pointed out, automated tool will
> use MAINTAINERS to gather this information.
>
> cheers, Marc
>
> The following changes since commit fd38f734cb8200529e281338514945fcbff2364b:
>
> igbvf: convert to ndo_fix_features (2011-10-16 13:18:47 -0700)
>
> are available in the git repository at:
> git.pengutronix.de:/git/mkl/linux-2.6.git can/mailinglist-for-net-next
That URL prompts me for a password, so I applied these patches by hand
to net-next, thanks.
^ permalink raw reply
* Re: [PATCH v3] net/flow: Fix potential memory leak
From: David Miller @ 2011-10-17 23:19 UTC (permalink / raw)
To: huajun.li.lee; +Cc: eric.dumazet, netdev
In-Reply-To: <CA+v9cxZ=ZYQ_nUXp-8M1Kciia2F6F0MZpq-kKGE4J-ayEGeScw@mail.gmail.com>
From: Huajun Li <huajun.li.lee@gmail.com>
Date: Wed, 28 Sep 2011 16:51:39 +0800
> While preparing net flow caches, once a fail may cause potential
> memory leak , fix it.
>
> Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: net [BUG-FIX][PATCH 1/1] udplite: fast-path computation of checksum coverage
From: David Miller @ 2011-10-17 23:07 UTC (permalink / raw)
To: gerrit; +Cc: netdev
In-Reply-To: <20111017213447.GA4061@gerrit.erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Mon, 17 Oct 2011 15:34:47 -0600
> can you please consider the fix below -- the checksum coverage in
> UDP-Lite had been broken for over half a year; then reported by
> Thomas. I have tested the patch below in various scenarios with IPv4
> and IPv6, on localhost, and between multiple hosts.
Applied, thanks a lot Gerrit.
^ permalink raw reply
* Re: [PATCH 2/2] bridge: allow forwarding some link local frames
From: Ross Brattain @ 2011-10-17 23:07 UTC (permalink / raw)
To: Ed Swierk; +Cc: Stephen Hemminger, David S. Miller, netdev@vger.kernel.org
In-Reply-To: <CAF5U64D36-Kb+KN6kNskE6yaPW6G_Ue8-OcskseKWoBEPQdVUA@mail.gmail.com>
On Mon, 17 Oct 2011 14:09:34 -0700
Ed Swierk <eswierk@bigswitch.com> wrote:
> Interesting, I didn't realize LLDP could use any of those addresses.
>
> I finally got a peek at the hot-off-the-presses IEEE 802.1Q-2011, and
> notice that 01-80-C2-00-00-0E is now assigned as "Individual LAN Scope
> group address, Nearest bridge group address" rather than dedicated to
> LLDP specifically.
>
802.1AB-2009 Section 7.1 Destination address:
NOTE 8—The destination MAC address used by a given LLDP agent defines only the scope of transmission and the
intended recipient(s) of the LLDPDUs; it plays no part in protocol identification. In particular, the group MAC addresses
identified in Table 7-1 are not used exclusively by LLDP; other protocols that require to use a similar transmission scope
are free to use the same addresses.
> Since our application is generating the LLDP frames we could change it
> to use -00 or -03 and let the Linux bridge drop the -0E frames.
>
If you control both end stations you could use the optional group MAC address support, or unicast LLDP.
802.1AB-2009 Section 7.1 Destination address:
In addition to the prescribed support for standard group MAC addresses shown in Table 7-1,
implementations of LLDP may support the following destination addresses for LLDPDUs:
d) Any group MAC address.
e) Any individual MAC address.
Support for the use of each of these destination addresses, for both transmission and reception of LLDPDUs,
is either mandatory, recommended, permitted, or not permitted, according to the type of system in which
LLDP is implemented, as shown in Table 7-2.
I have no idea if any LLDP agents support the optional group MAC addresses.
--
Ross
^ permalink raw reply
* Re: EHEA updates
From: David Miller @ 2011-10-17 23:06 UTC (permalink / raw)
To: cascardo; +Cc: netdev, anton
In-Reply-To: <1318606272-27647-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Date: Fri, 14 Oct 2011 12:30:57 -0300
> This is a rebase of Anton's patches on top of net-next HEAD, commit
> 7ae60b3. Besides the conflicts with the latest patches, some trivia were
> fixed as suggested.
>
> Ben Hutchings' suggestions about doing packet split and NAPI fixes were
> taken into consideration, but not done on this round.
>
> The result was tested between two LPARs and also using a switch, with
> ICMP and TCP tests.
Nice work, all applied, thanks.
^ permalink raw reply
* Re: [net-next 0/6 v2][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2011-10-17 22:53 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <20111017.184922.373702739993889767.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]
On Mon, 2011-10-17 at 15:49 -0700, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Mon, 17 Oct 2011 05:20:56 -0700
>
> > The following series contains updates to ixgbe, igbvf and igb.
> > This version of the series contains the following changes:
> >
> > - igb fix/add check if subordinate VFs are assigned to VM's
> > - igbvf fix for trunk VLAN
> > - ixgbe 2 fixes for ethtool and 1 endianess fix
> >
> > -v2 update the igb patch to resolve a variable initialization warning
> >
> > The following are changes since commit fd38f734cb8200529e281338514945fcbff2364b:
> > igbvf: convert to ndo_fix_features
> > and are available in the git repository at
> > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
>
> Patch #5 adding timestamp offloading for ixgbe has some legitimate
> pushback from Richard Cochran, why don't we defer that patch while that
> discussion transpires?
>
> I'm perfectly fine with the other patches in this series.
>
> Please respin the remaining 5 patches into a pull request and I'll
> take them into net-next, thanks Jeff!
>
Sounds good, I have that ready in an hour or so.
Thanks!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: pull request: wireless-next 2011-10-17
From: David Miller @ 2011-10-17 22:49 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20111017202332.GE8948-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Mon, 17 Oct 2011 16:23:33 -0400
> I neglected to identify the HEAD and sign...
>
> commit 41ebe9cde738a972d05c7282e09f5ed54cff0e8d
Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next 0/6 v2][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2011-10-17 22:49 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1318854062-3628-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 17 Oct 2011 05:20:56 -0700
> The following series contains updates to ixgbe, igbvf and igb.
> This version of the series contains the following changes:
>
> - igb fix/add check if subordinate VFs are assigned to VM's
> - igbvf fix for trunk VLAN
> - ixgbe 2 fixes for ethtool and 1 endianess fix
>
> -v2 update the igb patch to resolve a variable initialization warning
>
> The following are changes since commit fd38f734cb8200529e281338514945fcbff2364b:
> igbvf: convert to ndo_fix_features
> and are available in the git repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
Patch #5 adding timestamp offloading for ixgbe has some legitimate
pushback from Richard Cochran, why don't we defer that patch while that
discussion transpires?
I'm perfectly fine with the other patches in this series.
Please respin the remaining 5 patches into a pull request and I'll
take them into net-next, thanks Jeff!
^ permalink raw reply
* Re: BUG in skb_pull with e1000e, PPTP, and L2TP
From: Bradley Peterson @ 2011-10-17 22:30 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, PJ Waskiewicz,
Alex Duyck, John Ronciak, e1000-devel
In-Reply-To: <20111017152531.144b16a1@nehalam.linuxnetplumber.net>
On Mon, Oct 17, 2011 at 5:25 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Mon, 17 Oct 2011 17:19:53 -0500
> Bradley Peterson <despite@gmail.com> wrote:
>
>> using 3rd
>> party pptp and l2tp modules.
>
> More than likely your 3rd party modules are buggy and
> can't handle all the possible types of skb layout.
> I have seen out of tree code that can't handle non-linear
> skb's. You need to take it up with the those developer.
>
Oh, I should've been more clear -- I am no longer using any 3rd party
modules. That referred to my previous setup with 2.6.22 (I knew
better than to report that). This bug is with 2.6.38 using in-tree
modules.
Bradley Peterson
^ permalink raw reply
* Re: BUG in skb_pull with e1000e, PPTP, and L2TP
From: Stephen Hemminger @ 2011-10-17 22:25 UTC (permalink / raw)
To: Bradley Peterson
Cc: netdev, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, PJ Waskiewicz,
Alex Duyck, John Ronciak, e1000-devel
In-Reply-To: <CAJuWrdtOru6KSNTxXhhQNEZUTaX5KvyF7macx4RZYxMzcAo0KQ@mail.gmail.com>
On Mon, 17 Oct 2011 17:19:53 -0500
Bradley Peterson <despite@gmail.com> wrote:
> using 3rd
> party pptp and l2tp modules.
More than likely your 3rd party modules are buggy and
can't handle all the possible types of skb layout.
I have seen out of tree code that can't handle non-linear
skb's. You need to take it up with the those developer.
^ permalink raw reply
* [PATCH 7/7] mlx4_en: Updating driver version
From: Yevgeny Petrilin @ 2011-10-17 20:18 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Driver version updated to 1.5.4.2
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 89fb57c..d62c65c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -51,8 +51,8 @@
#include "en_port.h"
#define DRV_NAME "mlx4_en"
-#define DRV_VERSION "1.5.4.1"
-#define DRV_RELDATE "March 2011"
+#define DRV_VERSION "1.5.4.2"
+#define DRV_RELDATE "October 2011"
#define MLX4_EN_MSG_LEVEL (NETIF_MSG_LINK | NETIF_MSG_IFDOWN)
--
1.7.7
^ permalink raw reply related
* [PATCH 6/7] mlx4_en: Adding rxhash support
From: Yevgeny Petrilin @ 2011-10-17 20:18 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Moving to Toeplitz function in RSS calculation.
Reporting rxhash in skb.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 9 +++++++++
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index c4c4be4..78d776b 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -1084,7 +1084,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
dev->vlan_features = dev->hw_features;
- dev->hw_features |= NETIF_F_RXCSUM;
+ dev->hw_features |= NETIF_F_RXCSUM | NETIF_F_RXHASH;
dev->features = dev->hw_features | NETIF_F_HIGHDMA |
NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX |
NETIF_F_HW_VLAN_FILTER;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index f42c7a6..ae5feed 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -618,6 +618,9 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
__vlan_hwaccel_put_tag(gro_skb, vid);
}
+ if (dev->features & NETIF_F_RXHASH)
+ gro_skb->rxhash = be32_to_cpu(cqe->immed_rss_invalid);
+
skb_record_rx_queue(gro_skb, cq->ring);
napi_gro_frags(&cq->napi);
@@ -651,6 +654,9 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
skb->protocol = eth_type_trans(skb, dev);
skb_record_rx_queue(skb, cq->ring);
+ if (dev->features & NETIF_F_RXHASH)
+ skb->rxhash = be32_to_cpu(cqe->immed_rss_invalid);
+
if (be32_to_cpu(cqe->vlan_my_qpn) &
MLX4_CQE_VLAN_PRESENT_MASK)
__vlan_hwaccel_put_tag(skb, be16_to_cpu(cqe->sl_vid));
@@ -865,6 +871,9 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
(rss_map->base_qpn));
rss_context->default_qpn = cpu_to_be32(rss_map->base_qpn);
rss_context->flags = rss_mask;
+ rss_context->hash_fn = 1;
+ for (i = 0; i < 10; i++)
+ rss_context->rss_key[i] = random32();
if (priv->mdev->profile.udp_rss)
rss_context->base_qpn_udp = rss_context->default_qpn;
--
1.7.7
^ permalink raw reply related
* [PATCH 5/7] mlx4_en: Recording rx queue for gro packets
From: Yevgeny Petrilin @ 2011-10-17 20:18 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 45b1a3d..f42c7a6 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -618,6 +618,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
__vlan_hwaccel_put_tag(gro_skb, vid);
}
+ skb_record_rx_queue(gro_skb, cq->ring);
napi_gro_frags(&cq->napi);
goto next;
--
1.7.7
^ permalink raw reply related
* [PATCH 4/7] mlx4_en: Checksum counters per ring
From: Yevgeny Petrilin @ 2011-10-17 20:17 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Not updating common counters from data path.
The checksum counters are per ring, summarizing them when collecting statistics.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/en_port.c | 6 ++++++
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 6 +++---
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 3 +++
4 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_port.c b/drivers/net/ethernet/mellanox/mlx4/en_port.c
index 9d27555..03c84cd 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_port.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_port.c
@@ -214,15 +214,21 @@ int mlx4_en_DUMP_ETH_STATS(struct mlx4_en_dev *mdev, u8 port, u8 reset)
stats->rx_packets = 0;
stats->rx_bytes = 0;
+ priv->port_stats.rx_chksum_good = 0;
+ priv->port_stats.rx_chksum_none = 0;
for (i = 0; i < priv->rx_ring_num; i++) {
stats->rx_packets += priv->rx_ring[i].packets;
stats->rx_bytes += priv->rx_ring[i].bytes;
+ priv->port_stats.rx_chksum_good += priv->rx_ring[i].csum_ok;
+ priv->port_stats.rx_chksum_none += priv->rx_ring[i].csum_none;
}
stats->tx_packets = 0;
stats->tx_bytes = 0;
+ priv->port_stats.tx_chksum_offload = 0;
for (i = 0; i < priv->tx_ring_num; i++) {
stats->tx_packets += priv->tx_ring[i].packets;
stats->tx_bytes += priv->tx_ring[i].bytes;
+ priv->port_stats.tx_chksum_offload += priv->tx_ring[i].tx_csum;
}
stats->rx_errors = be64_to_cpu(mlx4_en_stats->PCS) +
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 8ae1eb5..45b1a3d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -587,7 +587,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
if (likely(dev->features & NETIF_F_RXCSUM)) {
if ((cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPOK)) &&
(cqe->checksum == cpu_to_be16(0xffff))) {
- priv->port_stats.rx_chksum_good++;
+ ring->csum_ok++;
/* This packet is eligible for LRO if it is:
* - DIX Ethernet (type interpretation)
* - TCP/IP (v4)
@@ -627,11 +627,11 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
ip_summed = CHECKSUM_UNNECESSARY;
} else {
ip_summed = CHECKSUM_NONE;
- priv->port_stats.rx_chksum_none++;
+ ring->csum_none++;
}
} else {
ip_summed = CHECKSUM_NONE;
- priv->port_stats.rx_chksum_none++;
+ ring->csum_none++;
}
skb = mlx4_en_rx_skb(priv, rx_desc, skb_frags,
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index 6e03de0..f199460 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -695,7 +695,7 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
if (likely(skb->ip_summed == CHECKSUM_PARTIAL)) {
tx_desc->ctrl.srcrb_flags |= cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM |
MLX4_WQE_CTRL_TCP_UDP_CSUM);
- priv->port_stats.tx_chksum_offload++;
+ ring->tx_csum++;
}
if (unlikely(priv->validate_loopback)) {
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 013cda2..89fb57c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -249,6 +249,7 @@ struct mlx4_en_tx_ring {
struct mlx4_srq dummy;
unsigned long bytes;
unsigned long packets;
+ unsigned long tx_csum;
spinlock_t comp_lock;
struct mlx4_bf bf;
bool bf_enabled;
@@ -275,6 +276,8 @@ struct mlx4_en_rx_ring {
void *rx_info;
unsigned long bytes;
unsigned long packets;
+ unsigned long csum_ok;
+ unsigned long csum_none;
};
--
1.7.7
^ permalink raw reply related
* [PATCH 3/7] mlx4_en: Incoming traffic alignment optimizations
From: Yevgeny Petrilin @ 2011-10-17 20:17 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Packet headers are copied to skb linear part (which is IP aligned), so there is no reason for
the scatter entry to be IP aligned.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 12 +++---------
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 2 +-
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index fbf1dcf..8ae1eb5 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -744,15 +744,9 @@ void mlx4_en_calc_rx_buf(struct net_device *dev)
(eff_mtu > buf_size + frag_sizes[i]) ?
frag_sizes[i] : eff_mtu - buf_size;
priv->frag_info[i].frag_prefix_size = buf_size;
- if (!i) {
- priv->frag_info[i].frag_align = NET_IP_ALIGN;
- priv->frag_info[i].frag_stride =
- ALIGN(frag_sizes[i] + NET_IP_ALIGN, SMP_CACHE_BYTES);
- } else {
- priv->frag_info[i].frag_align = 0;
- priv->frag_info[i].frag_stride =
- ALIGN(frag_sizes[i], SMP_CACHE_BYTES);
- }
+ priv->frag_info[i].frag_align = 0;
+ priv->frag_info[i].frag_stride =
+ ALIGN(frag_sizes[i], SMP_CACHE_BYTES);
priv->frag_info[i].last_offset = mlx4_en_last_alloc_offset(
priv, priv->frag_info[i].frag_stride,
priv->frag_info[i].frag_align);
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 3b753f7..013cda2 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -91,7 +91,7 @@
/* Receive fragment sizes; we use at most 4 fragments (for 9600 byte MTU
* and 4K allocations) */
enum {
- FRAG_SZ0 = 512 - NET_IP_ALIGN,
+ FRAG_SZ0 = 2048,
FRAG_SZ1 = 1024,
FRAG_SZ2 = 4096,
FRAG_SZ3 = MLX4_EN_ALLOC_SIZE
--
1.7.7
^ permalink raw reply related
* [PATCH 2/7] mlx4_en: Controlling FCS header removal
From: Yevgeny Petrilin @ 2011-10-17 20:17 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Canceling FCS removal where FW allows for better alignment
of incoming data.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 4 ++++
drivers/net/ethernet/mellanox/mlx4/fw.c | 1 +
include/linux/mlx4/device.h | 1 +
3 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 37cc9e5..fbf1dcf 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -806,6 +806,10 @@ static int mlx4_en_config_rss_qp(struct mlx4_en_priv *priv, int qpn,
qpn, ring->cqn, context);
context->db_rec_addr = cpu_to_be64(ring->wqres.db.dma);
+ /* Cancel FCS removal if FW allows */
+ if (mdev->dev->caps.flags & MLX4_DEV_CAP_FLAG_FCS_KEEP)
+ context->param3 |= cpu_to_be32(1 << 29);
+
err = mlx4_qp_to_ready(mdev->dev, &ring->wqres.mtt, context, qp, state);
if (err) {
mlx4_qp_remove(mdev->dev, qp);
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 7eb8ba8..ed452dd 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -101,6 +101,7 @@ static void dump_dev_cap_flags(struct mlx4_dev *dev, u64 flags)
[25] = "Router support",
[30] = "IBoE support",
[32] = "Unicast loopback support",
+ [34] = "FCS header control",
[38] = "Wake On LAN support",
[40] = "UDP RSS support",
[41] = "Unicast VEP steering support",
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index 53ef894..2366f94 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -75,6 +75,7 @@ enum {
MLX4_DEV_CAP_FLAG_UD_MCAST = 1LL << 21,
MLX4_DEV_CAP_FLAG_IBOE = 1LL << 30,
MLX4_DEV_CAP_FLAG_UC_LOOPBACK = 1LL << 32,
+ MLX4_DEV_CAP_FLAG_FCS_KEEP = 1LL << 34,
MLX4_DEV_CAP_FLAG_WOL = 1LL << 38,
MLX4_DEV_CAP_FLAG_UDP_RSS = 1LL << 40,
MLX4_DEV_CAP_FLAG_VEP_UC_STEER = 1LL << 41,
--
1.7.7
^ permalink raw reply related
* [PATCH 1/7] mlx4: Fix vlan table overflow
From: Yevgeny Petrilin @ 2011-10-17 20:16 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Prevent overflow when trying to register more Vlans then the Vlan table in
HW is configured to.
Need to take into account that the first 2 entries are reserved.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/port.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/port.c b/drivers/net/ethernet/mellanox/mlx4/port.c
index 609e0ec..163a314 100644
--- a/drivers/net/ethernet/mellanox/mlx4/port.c
+++ b/drivers/net/ethernet/mellanox/mlx4/port.c
@@ -65,7 +65,7 @@ void mlx4_init_vlan_table(struct mlx4_dev *dev, struct mlx4_vlan_table *table)
table->entries[i] = 0;
table->refs[i] = 0;
}
- table->max = 1 << dev->caps.log_num_vlans;
+ table->max = (1 << dev->caps.log_num_vlans) - MLX4_VLAN_REGULAR;
table->total = 0;
}
@@ -354,6 +354,13 @@ int mlx4_register_vlan(struct mlx4_dev *dev, u8 port, u16 vlan, int *index)
int free = -1;
mutex_lock(&table->mutex);
+
+ if (table->total == table->max) {
+ /* No free vlan entries */
+ err = -ENOSPC;
+ goto out;
+ }
+
for (i = MLX4_VLAN_REGULAR; i < MLX4_MAX_VLAN_NUM; i++) {
if (free < 0 && (table->refs[i] == 0)) {
free = i;
@@ -375,12 +382,6 @@ int mlx4_register_vlan(struct mlx4_dev *dev, u8 port, u16 vlan, int *index)
goto out;
}
- if (table->total == table->max) {
- /* No free vlan entries */
- err = -ENOSPC;
- goto out;
- }
-
/* Register new MAC */
table->refs[free] = 1;
table->entries[free] = cpu_to_be32(vlan | MLX4_VLAN_VALID);
--
1.7.7
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox