Netdev List
 help / color / mirror / Atom feed
* [PATCH net-next 03/13] driver: atm: remove unnecessary skb NULL check before calling dev_kfree_skb_irq
From: Govindarajulu Varadarajan @ 2013-11-02 13:47 UTC (permalink / raw)
  To: davem, gregkh, linux-usb, linux-kernel, schwidefsky, linville,
	linux-wireless, netdev, IvDoorn, sbhatewara, samuel, chas, roland,
	isdn, jcliburn, benve, ssujith, jeffrey.t.kirsher,
	jesse.brandeburg, shahed.shaikh, joe, apw
  Cc: Govindarajulu Varadarajan
In-Reply-To: <1383400074-30555-1-git-send-email-govindarajulu90@gmail.com>

dev_kfree_skb_irq is protected from NULL. No need to check for NULL while
calling this function.

Signed-off-by: Govindarajulu Varadarajan <govindarajulu90@gmail.com>
---
 drivers/atm/eni.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/atm/eni.c b/drivers/atm/eni.c
index b1955ba..78a4445 100644
--- a/drivers/atm/eni.c
+++ b/drivers/atm/eni.c
@@ -481,7 +481,7 @@ trouble:
 	if (paddr)
 		pci_unmap_single(eni_dev->pci_dev,paddr,skb->len,
 		    PCI_DMA_FROMDEVICE);
-	if (skb) dev_kfree_skb_irq(skb);
+	dev_kfree_skb_irq(skb);
 	return -1;
 }
 
-- 
1.8.4.2

^ permalink raw reply related

* [PATCH net-next 01/13] net: Check skb for NULL in dev_kfree_skb_irq
From: Govindarajulu Varadarajan @ 2013-11-02 13:47 UTC (permalink / raw)
  To: davem, gregkh, linux-usb, linux-kernel, schwidefsky, linville,
	linux-wireless, netdev, IvDoorn, sbhatewara, samuel, chas, roland,
	isdn, jcliburn, benve, ssujith, jeffrey.t.kirsher,
	jesse.brandeburg, shahed.shaikh, joe, apw
  Cc: Govindarajulu Varadarajan
In-Reply-To: <1383400074-30555-1-git-send-email-govindarajulu90@gmail.com>

Signed-off-by: Govindarajulu Varadarajan <govindarajulu90@gmail.com>
---
 net/core/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 0054c8c..63bd44d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2146,7 +2146,7 @@ EXPORT_SYMBOL(__netif_schedule);
 
 void dev_kfree_skb_irq(struct sk_buff *skb)
 {
-	if (atomic_dec_and_test(&skb->users)) {
+	if (skb && atomic_dec_and_test(&skb->users)) {
 		struct softnet_data *sd;
 		unsigned long flags;
 
-- 
1.8.4.2

^ permalink raw reply related

* Re: [PATCH net-next 1/1] ipv6: remove the destination condition on flow label sharing
From: Florent Fourcot @ 2013-11-02 13:37 UTC (permalink / raw)
  To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <20131101214048.GD30284@order.stressinduktion.org>


> Why?
> 
> Maybe I am not the only one up to date with recent advances in flow label
> management but I guess others want to know why, too?
> 

Actually, the good question is "why this restriction before". It
probably comes from the RFC 1809, an informational one:

RFC 1809 says:
> 
>    The specification further requires that all datagrams with the same
>    (non-zero) Flow Label must have the same Destination Address, Hop-
>    by-Hop Options header, Routing Header and Source Address contents.

In standard track RFCs (3697 / 6437), there are no restriction to set a
flow label to only one destination. In the same way, the condition on
IPv6 option is obsolete.


> Please reflect this in your changelog.
> 

I will send a V2.

^ permalink raw reply

* [PATCH net-next 01/11] openvswitch: Move flow table rehashing to flow install.
From: Jesse Gross @ 2013-11-02  7:43 UTC (permalink / raw)
  To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1383378230-59624-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>

From: Pravin B Shelar <pshelar-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>

Rehashing in ovs-workqueue can cause ovs-mutex lock contentions
in case of heavy flow setups where both needs ovs-mutex.  So by
moving rehashing to flow-setup we can eliminate contention.
This also simplify ovs locking and reduces dependence on
workqueue.

Signed-off-by: Pravin B Shelar <pshelar-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
 net/openvswitch/datapath.c | 50 ++++++++++------------------------------------
 net/openvswitch/datapath.h |  2 ++
 2 files changed, 13 insertions(+), 39 deletions(-)

diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 2aa13bd..2e1a9c2 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -60,8 +60,6 @@
 
 
 #define REHASH_FLOW_INTERVAL (10 * 60 * HZ)
-static void rehash_flow_table(struct work_struct *work);
-static DECLARE_DELAYED_WORK(rehash_flow_wq, rehash_flow_table);
 
 int ovs_net_id __read_mostly;
 
@@ -1289,22 +1287,25 @@ static int ovs_flow_cmd_new_or_set(struct sk_buff *skb, struct genl_info *info)
 	/* Check if this is a duplicate flow */
 	flow = ovs_flow_lookup(table, &key);
 	if (!flow) {
+		struct flow_table *new_table = NULL;
 		struct sw_flow_mask *mask_p;
+
 		/* Bail out if we're not allowed to create a new flow. */
 		error = -ENOENT;
 		if (info->genlhdr->cmd == OVS_FLOW_CMD_SET)
 			goto err_unlock_ovs;
 
 		/* Expand table, if necessary, to make room. */
-		if (ovs_flow_tbl_need_to_expand(table)) {
-			struct flow_table *new_table;
-
+		if (ovs_flow_tbl_need_to_expand(table))
 			new_table = ovs_flow_tbl_expand(table);
-			if (!IS_ERR(new_table)) {
-				rcu_assign_pointer(dp->table, new_table);
-				ovs_flow_tbl_destroy(table, true);
-				table = ovsl_dereference(dp->table);
-			}
+		else if (time_after(jiffies, dp->last_rehash + REHASH_FLOW_INTERVAL))
+			new_table = ovs_flow_tbl_rehash(table);
+
+		if (new_table && !IS_ERR(new_table)) {
+			rcu_assign_pointer(dp->table, new_table);
+			ovs_flow_tbl_destroy(table, true);
+			table = ovsl_dereference(dp->table);
+			dp->last_rehash = jiffies;
 		}
 
 		/* Allocate flow. */
@@ -2336,32 +2337,6 @@ error:
 	return err;
 }
 
-static void rehash_flow_table(struct work_struct *work)
-{
-	struct datapath *dp;
-	struct net *net;
-
-	ovs_lock();
-	rtnl_lock();
-	for_each_net(net) {
-		struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
-
-		list_for_each_entry(dp, &ovs_net->dps, list_node) {
-			struct flow_table *old_table = ovsl_dereference(dp->table);
-			struct flow_table *new_table;
-
-			new_table = ovs_flow_tbl_rehash(old_table);
-			if (!IS_ERR(new_table)) {
-				rcu_assign_pointer(dp->table, new_table);
-				ovs_flow_tbl_destroy(old_table, true);
-			}
-		}
-	}
-	rtnl_unlock();
-	ovs_unlock();
-	schedule_delayed_work(&rehash_flow_wq, REHASH_FLOW_INTERVAL);
-}
-
 static int __net_init ovs_init_net(struct net *net)
 {
 	struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
@@ -2419,8 +2394,6 @@ static int __init dp_init(void)
 	if (err < 0)
 		goto error_unreg_notifier;
 
-	schedule_delayed_work(&rehash_flow_wq, REHASH_FLOW_INTERVAL);
-
 	return 0;
 
 error_unreg_notifier:
@@ -2437,7 +2410,6 @@ error:
 
 static void dp_cleanup(void)
 {
-	cancel_delayed_work_sync(&rehash_flow_wq);
 	dp_unregister_genl(ARRAY_SIZE(dp_genl_families));
 	unregister_netdevice_notifier(&ovs_dp_device_notifier);
 	unregister_pernet_device(&ovs_net_ops);
diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h
index 4d109c1..2c15541 100644
--- a/net/openvswitch/datapath.h
+++ b/net/openvswitch/datapath.h
@@ -62,6 +62,7 @@ struct dp_stats_percpu {
  * ovs_mutex and RCU.
  * @stats_percpu: Per-CPU datapath statistics.
  * @net: Reference to net namespace.
+ * @last_rehash: Timestamp of last rehash.
  *
  * Context: See the comment on locking at the top of datapath.c for additional
  * locking information.
@@ -83,6 +84,7 @@ struct datapath {
 	/* Network namespace ref. */
 	struct net *net;
 #endif
+	unsigned long last_rehash;
 };
 
 /**
-- 
1.8.3.2

^ permalink raw reply related

* [GIT net-next] Open vSwitch
From: Jesse Gross @ 2013-11-02  7:43 UTC (permalink / raw)
  To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA

A set of updates for net-next/3.13. Major changes are:
 * Restructure flow handling code to be more logically organized and
   easier to read.
 * Rehashing of the flow table is moved from a workqueue to flow
   installation time. Before, heavy load could block the workqueue for
   excessive periods of time.
 * Additional debugging information is provided to help diagnose megaflows.
 * It's now possible to match on TCP flags.

The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:

  Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jesse/openvswitch.git master

for you to fetch changes up to 8ddd094675cfd453fc9838caa46ea108a4107183:

  openvswitch: Use flow hash during flow lookup operation. (2013-11-01 18:43:46 -0700)

----------------------------------------------------------------
Andy Zhou (1):
      openvswitch: collect mega flow mask stats

Jarno Rajahalme (2):
      openvswitch: Widen TCP flags handling.
      openvswitch: TCP flags matching support.

Pravin B Shelar (6):
      openvswitch: Move flow table rehashing to flow install.
      openvswitch: Restructure datapath.c and flow.c
      openvswitch: Move mega-flow list out of rehashing struct.
      openvswitch: Simplify mega-flow APIs.
      openvswitch: Enable all GSO features on internal port.
      openvswitch: Use flow hash during flow lookup operation.

Wei Yongjun (2):
      openvswitch: remove duplicated include from vport-vxlan.c
      openvswitch: remove duplicated include from vport-gre.c

 include/uapi/linux/openvswitch.h     |   18 +-
 net/openvswitch/Makefile             |    2 +
 net/openvswitch/datapath.c           |  668 ++------------
 net/openvswitch/datapath.h           |    9 +-
 net/openvswitch/flow.c               | 1605 +--------------------------------
 net/openvswitch/flow.h               |  132 +--
 net/openvswitch/flow_netlink.c       | 1630 ++++++++++++++++++++++++++++++++++
 net/openvswitch/flow_netlink.h       |   60 ++
 net/openvswitch/flow_table.c         |  592 ++++++++++++
 net/openvswitch/flow_table.h         |   81 ++
 net/openvswitch/vport-gre.c          |    2 -
 net/openvswitch/vport-internal_dev.c |    2 +-
 net/openvswitch/vport-vxlan.c        |    1 -
 13 files changed, 2511 insertions(+), 2291 deletions(-)
 create mode 100644 net/openvswitch/flow_netlink.c
 create mode 100644 net/openvswitch/flow_netlink.h
 create mode 100644 net/openvswitch/flow_table.c
 create mode 100644 net/openvswitch/flow_table.h

^ permalink raw reply

* Re: [PATCH net-next 00/10] Mellanox driver updates Oct 31 2013
From: David Miller @ 2013-11-02  6:20 UTC (permalink / raw)
  To: ogerlitz; +Cc: netdev, amirv, roland, jackm
In-Reply-To: <1383222569-10930-1-git-send-email-ogerlitz@mellanox.com>

From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Thu, 31 Oct 2013 14:29:19 +0200

> This patch set from Jack Morgenstein does the following:
> 
> 1. Fix MAC/VLAN SRIOV implementation, and add wrapper functions for VLAN allocation
>    and de-allocation (patches 1-6).
> 
> 2. Implements resource quotas when running under SRIOV (patches 7-10).
>    Patch 7 is a small bug fix, and patches 8-10 implement the quotas.
> 
> Quotas are implemented per resource type for VFs and the PF, to prevent
> any entity from simply grabbing all the resources for itself and leaving
> the other entities unable to obtain such resources.
> 
> The series is against net-next commit ba48650 "ipv6: remove the unnecessary statement in find_match()"
> 
> Patch #1 is bug fix which needs to go into -stable of kernels >= 3.10 

You cannot submit via net-next a bug fix that you want to go to -stable.
I've stated this a thousand times.

You MUST submit the bug fix for "net", not "net-next".

I'm tossing this entire series, submit your changes correctly.

Thank you.

^ permalink raw reply

* Re: [PATCH net] net: flow_dissector: fail on evil iph->ihl
From: David Miller @ 2013-11-02  6:16 UTC (permalink / raw)
  To: jasowang; +Cc: edumazet, netdev, linux-kernel, pmatouse, mst, dborkman
In-Reply-To: <1383289270-18952-1-git-send-email-jasowang@redhat.com>

From: Jason Wang <jasowang@redhat.com>
Date: Fri,  1 Nov 2013 15:01:10 +0800

> We don't validate iph->ihl which may lead a dead loop if we meet a IPIP
> skb whose iph->ihl is zero. Fix this by failing immediately when iph->ihl
> is evil (less than 5).
> 
> This issue were introduced by commit ec5efe7946280d1e84603389a1030ccec0a767ae
> (rps: support IPIP encapsulation).
> 
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Petr Matousek <pmatouse@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Daniel Borkmann <dborkman@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>

Applied and queued up for -stable, thanks Jason.

^ permalink raw reply

* Re: pull request (net-next): ipsec-next 2013-11-01
From: David Miller @ 2013-11-02  6:14 UTC (permalink / raw)
  To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1383292257-4634-1-git-send-email-steffen.klassert@secunet.com>

From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Fri,  1 Nov 2013 08:50:53 +0100

> This pull request has a trivial merge conflict between git commit
> e7d8f6c ("xfrm: Add refcount handling to queued policies") and
> git commit 4d53eff ("xfrm: Don't queue retransmitted packets if
> the original is still on the host"). It can be solved as it is
> currently done in linux-next.
> 
> 1) Use vmalloc_node for ipcomp percpu scratches to get proper
>    NUMA affinity, from Eric Dumazet
> 
> 2) Avoid to retransmit packets if the original packet is
>    still in the xfrm hold queue.
> 
> 3) Remove unused padlen field from struct esp_data.
>    From Mathias Krause.
> 
> 4) Remove struct esp_data because now it consists of a single
>    pointer. From Mathias Krause.
> 
> Please pull or let me know if there are problems.

Pulled, thanks a lot.

^ permalink raw reply

* Re: [patch -next] bonding: bond_get_size() returns wrong size
From: David Miller @ 2013-11-02  6:09 UTC (permalink / raw)
  To: dan.carpenter; +Cc: fubar, vfalico, andy, netdev, kernel-janitors, jiri
In-Reply-To: <20131101101844.GA29795@longonot.mountain>

From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri, 1 Nov 2013 13:18:44 +0300

> There is an extra semi-colon so bond_get_size() doesn't return the
> correct value.
> 
> Fixes: ec76aa49855f ('bonding: add Netlink support active_slave option')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

Applied, thanks a lot Dan.

^ permalink raw reply

* Re: [PATCH net-next 00/24] cdc_ncm: many small and mostly trivial fixes
From: David Miller @ 2013-11-02  6:02 UTC (permalink / raw)
  To: bjorn; +Cc: netdev, linux-usb, alexey.orishko
In-Reply-To: <1383301021-16613-1-git-send-email-bjorn@mork.no>

From: Bjørn Mork <bjorn@mork.no>
Date: Fri,  1 Nov 2013 11:16:37 +0100

> This series ended up longer than expected, and it is still not
> complete. There is more to come when time allows...
> 
> Most changes are trivial. Notable non-trivial changes are
>  - removed filtering of identical speed notifications
>  - tx_max calulation is changed to count the pad byte if
>    necessary, and respect the device limit as an absolute
>    upper limit even if it is too low according to the spec
>  - remove the bug preventing SET_MAX_DATAGRAM_SIZE from having
>    any effect
>  - drop the pad-to-max if ZLPs are enabled
>  - the driver specific VERSION is dropped
>  - dev->hard_mtu is set to tx_max instead of max_datagram_size
>    causing usbnet to calculate the qlen based on the real max
>    size of tx skbs
> 
> This series has been tested, along with the previously posted
> cdc_mbim series, on the NCM and MBIM devices I have:
>  - Ericsson F5521gw (NCM)
>  - Huawei E367 (MBIM)
>  - D-Link DWM-156 A7 (MBIM w/ too low dwNtb{In,Out}MaxSize bug)
>  - Sierra Wireless MC7710 (MBIM w/ ZLP and CDC Union bugs)
> 
> Apart from the D-Link modem dropping a lot less oversized
> frames with the fix dedicated to it, there are no end user
> noticable functional changes as a result of this series.  But
> all the non-trivial changes I listed above are of course
> detectable by users looking at that specific area (except maybe
> the removed speed notification, which requires a device sending
> duplicates to be noticable - I don't have any such device).

Looks good, series applied, thanks!

^ permalink raw reply

* Re: [PATCH v2.47 0/4] MPLS actions and matches
From: Ben Pfaff @ 2013-11-02  5:39 UTC (permalink / raw)
  To: Simon Horman
  Cc: dev-yBygre7rU0TnMu66kgdUjQ, Ravi K, netdev-u79uwXL29TY76Z2rM5mHXA,
	Isaku Yamahata
In-Reply-To: <1383203792-9774-1-git-send-email-horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>

On Thu, Oct 31, 2013 at 04:16:28PM +0900, Simon Horman wrote:
> This series implements MPLS actions and matches based on work by
> Ravi K, Leo Alterman, Yamahata-san and Joe Stringer.

Would you mind rebasing this one more time?

^ permalink raw reply

* Re: [PATCH net-next 0/2] cdc_mbim workarounds for firmware bugs
From: David Miller @ 2013-11-02  5:30 UTC (permalink / raw)
  To: bjorn; +Cc: netdev, alexey.orishko, gsuarez
In-Reply-To: <1383231371-8098-1-git-send-email-bjorn@mork.no>

From: Bjørn Mork <bjorn@mork.no>
Date: Thu, 31 Oct 2013 15:56:09 +0100

> The first patch is an attempt to work around a bug which prevents
> some devices from working with IPv6. I guess handling ND in a driver
> can be considered controversial, but it was the best alternative I
> came up with.
> 
> The second is the "final solution" to the well known ZLP bug, which
> as we feared is present in a number of devices using different
> vendor IDs. Enabling this is definitely controversial, but I do not
> see any other possible solution.  The blacklist has become
> unmanagable, and I am pretty sure it is very incomplete due to
> under-reporting.  Devices known to work without ZLPs can be added
> to the whitelist.

This seems fine, both applied, thanks.

^ permalink raw reply

* Re: pull request (net): ipsec 2013-11-01
From: David Miller @ 2013-11-02  5:22 UTC (permalink / raw)
  To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1383294107-7509-1-git-send-email-steffen.klassert@secunet.com>

From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Fri,  1 Nov 2013 09:21:44 +0100

> 1) Fix a possible race on ipcomp scratch buffers because
>    of too early enabled siftirqs. From Michal Kubecek.
> 
> 2) The current xfrm garbage collector threshold is too small
>    for some workloads, resulting in bad performance on these
>    workloads. Increase the threshold from 1024 to 32768.
> 
> 3) Some codepaths might not have a dst_entry attached to the
>    skb when calling xfrm_decode_session(). So add a check
>    to prevent a null pointer dereference in this case.
> 
> Please pull or let me know if there are problems.

Pulled, thanks a lot Steffen!

^ permalink raw reply

* Re: [PATCH 1/4] xfrm: use vmalloc_node() for percpu scratches
From: David Miller @ 2013-11-02  5:21 UTC (permalink / raw)
  To: sergei.shtylyov; +Cc: steffen.klassert, herbert, netdev
In-Reply-To: <5273A67B.9070901@cogentembedded.com>

From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Fri, 01 Nov 2013 17:02:51 +0400

>> @@ -220,8 +220,8 @@ static void ipcomp_free_scratches(void)
>>
>>   static void * __percpu *ipcomp_alloc_scratches(void)
>>   {
>> -	int i;
>>   	void * __percpu *scratches;
>> +	int i;
> 
>    This collateral change is not described in the changelog.

Yes, but I'm not going to block this series just for this.

^ permalink raw reply

* Re: [PATCHv2 net-next 0/7] smsc: replace printk with netdev_ calls
From: David Miller @ 2013-11-02  5:21 UTC (permalink / raw)
  To: mathstuf; +Cc: netdev
In-Reply-To: <1383310416-27177-1-git-send-email-mathstuf@gmail.com>

From: Ben Boeckel <mathstuf@gmail.com>
Date: Fri,  1 Nov 2013 08:53:29 -0400

> Clean up printk calls in smsc network drivers by using netdev_<level>
> instead. Also fixes some whitespace errors (trailing whitespace,
> spaces-between-tabs) noticed while fixing the printk calls. Reindenting files
> was not done.
> 
> I've compile tested them all on x86 by forcing them to at least compile to
> catch obvious errors.

Applied, thanks Ben.

^ permalink raw reply

* Re: [net-next 0/6][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2013-11-02  5:17 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1383314210-24289-1-git-send-email-jeffrey.t.kirsher@intel.com>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri,  1 Nov 2013 06:56:44 -0700

> This series contains updates to e1000, igb, ixgbe and ixgbevf.
> 
> Hong Zhiguo provides a fix for e1000 where tx_ring and adapter->tx_ring
> are already of type "struct e1000_tx_ring" so no need to divide by
> e1000_tx_ring size in the idx calculation.
> 
> Emil provides a fix for ixgbevf to remove a redundant workaround related
> to header split and a fix for ixgbe to resolve an issue where the MTA table
> can be cleared when the interface is reset while in promisc mode.
> 
> Todd provides a fix for igb to prevent ethtool from writing to the iNVM
> in i210/i211 devices.  This issue was reported by Marek Vasut <marex@denx.de>.
> 
> Anton Blanchard provides a fix for ixgbe to reduce memory consumption
> with larger page sizes, seen on PPC.
> 
> Don provides a cleanup in ixgbe to replace the IXGBE_DESC_UNUSED macro with
> the inline function ixgbevf_desc_unused() to make the logic a bit more
> readable.

Pulled, thanks a lot Jeff.

^ permalink raw reply

* Re: [PATCH net-next 2/6] qlcnic: Replace kzalloc() with vzalloc().
From: David Miller @ 2013-11-02  5:14 UTC (permalink / raw)
  To: himanshu.madhani; +Cc: netdev, Dept_NX_Linux_NIC_Driver, manish.chopra
In-Reply-To: <4e485cb2ec05e3cae68fbf59a0f1597a95098a76.1383358893.git.himanshu.madhani@qlogic.com>

From: Himanshu Madhani <himanshu.madhani@qlogic.com>
Date: Fri, 1 Nov 2013 16:51:25 -0400

> From: Manish Chopra <manish.chopra@qlogic.com>
> 
> o Some of the places kzalloc() is not required. Replace it
>   with vzalloc() wherever it is not used appropriately
> 
> Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
> Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>

This commit message is terrible.

In what way is kzalloc() inappropriate for these allocations?

Many of them are quite small, and vzalloc() is completely inappropriate
to use in such cases.

You should only use vzalloc() for HUGE allocations, those which
kzalloc() is unable to satisfy.  Many cases changed here in this
patch do not meet that criteria.

I'm tossing this entire patch series.

^ permalink raw reply

* Re: Pull request: sfc-next 2013-11-01
From: David Miller @ 2013-11-02  5:11 UTC (permalink / raw)
  To: bhutchings; +Cc: linux-net-drivers, netdev
In-Reply-To: <1383356266.1737.42.camel@bwh-desktop.uk.level5networks.com>

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Sat, 2 Nov 2013 01:37:46 +0000

> The following changes since commit ba4865027c11d7ac8e5a33e0624dd415caab2027:
> 
>   ipv6: remove the unnecessary statement in find_match() (2013-10-30 17:06:51 -0400)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-next.git for-davem
> 
> for you to fetch changes up to 2acdb92e85412bf791a3c01f2173695b6e0a3f72:
> 
>   sfc: Fix DMA unmapping issue with firmware assisted TSO (2013-10-31 20:58:14 +0000)
> 
> A single fix by Alexandre Rames for the recent changes to TSO.

Pulled, thanks Ben.

^ permalink raw reply

* Re: [PATCH] bnx2: Use dev_kfree_skb_any() in bnx2_tx_int()
From: David Miller @ 2013-11-02  5:06 UTC (permalink / raw)
  To: bhutchings; +Cc: xiyou.wangcong, mchan, tdmackey, netdev, linux-kernel
In-Reply-To: <1383348890.1737.40.camel@bwh-desktop.uk.level5networks.com>

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 1 Nov 2013 23:34:50 +0000

> As you've said, the ndo_start_xmit and NAPI poll operations are intended
> to be called in softirq context, so everything that interlocks with them
> will use spin_lock_bh().  Calling them from hardirq context obviously
> opens the possibility of a deadlock.  How do you expect anyone to solve
> that?

That's not what I said.

I did not say that it must be invoked in softirq context.

I said that it MUST LOOK like it is being invoked in softirq
context as far as the ->poll() code paths can tell.

But yes, that's hard.

The thing is, ->poll() is atomic.  You never will have poll calls
recurse into eachother.  This is why we strongly encourage all driver
authors to make their ->poll() implementations lockless.

And, wouldn't you know it, tg3 is a driver that does this
properly.

Therefore, there are no netpoll no locking problems, because the poll
implementation takes no locks and therefore doesn't care.

That's why tg3 doesn't have any of these netpoll issues.

^ permalink raw reply

* Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
From: Neil Horman @ 2013-11-02  2:07 UTC (permalink / raw)
  To: Joe Perches
  Cc: David Laight, Ben Hutchings, Doug Ledford, Ingo Molnar,
	Eric Dumazet, linux-kernel, netdev
In-Reply-To: <1383337612.3042.21.camel@joe-AO722>

On Fri, Nov 01, 2013 at 01:26:52PM -0700, Joe Perches wrote:
> On Fri, 2013-11-01 at 15:58 -0400, Neil Horman wrote:
> > On Fri, Nov 01, 2013 at 12:45:29PM -0700, Joe Perches wrote:
> > > On Fri, 2013-11-01 at 13:37 -0400, Neil Horman wrote:
> > > 
> > > > I think it would be better if we just did the prefetch here
> > > > and re-addressed this area when AVX (or addcx/addox) instructions were available
> > > > for testing on hardware.
> > > 
> > > Could there be a difference if only a single software
> > > prefetch was done at the beginning of transfer before
> > > the while loop and hardware prefetches did the rest?
> > > 
> > I wouldn't think so.  If hardware was going to do any prefetching based on
> > memory access patterns it will do so regardless of the leading prefetch, and
> > that first prefetch isn't helpful because we still wind up stalling on the adds
> > while its completing
> 
> I imagine one benefit to be helping prevent
> prefetching beyond the actual data required.
> 
> Maybe some hardware optimizes prefetch stride
> better than 5*64.
> 
> I wonder also if using
> 
> 	if (count > some_length)
> 		prefetch
> 	while (...)
> 
> helps small lengths more than the test/jump cost.
> 
We've already done this and it is in fact the best performing.  I'll be posting
that patch along with ingos request to add do_csum to the perf bench code when I
have that done
Best
Neil

> 

^ permalink raw reply

* [PATCH net-next] sfc: Fix DMA unmapping issue with firmware assisted TSO
From: Ben Hutchings @ 2013-11-02  1:38 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1383356266.1737.42.camel@bwh-desktop.uk.level5networks.com>

From: Alexandre Rames <arames@solarflare.com>

When using firmware assisted TSO, we use a single DMA mapping for
the linear area of a TSO skb.

We still have to segment the super-packet and insert a descriptor
containing the original headers before each segment of payload, so we
can unmap the linear area only after the last segment is completed.
The unmapping information for the linear area is therefore associated
with the last header descriptor.

We calculate the DMA address to unmap from using the map length and
the invariant that the end of the DMA mapping matches the end of
the data referenced by the last descriptor.  But this invariant is
broken when there is TCP payload in the linear area.

Fix this by adding and using an explicit dma_offset field.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
 drivers/net/ethernet/sfc/net_driver.h | 3 +++
 drivers/net/ethernet/sfc/tx.c         | 7 +++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/sfc/net_driver.h b/drivers/net/ethernet/sfc/net_driver.h
index aac22a1..b14a717 100644
--- a/drivers/net/ethernet/sfc/net_driver.h
+++ b/drivers/net/ethernet/sfc/net_driver.h
@@ -141,6 +141,8 @@ struct efx_special_buffer {
  * @len: Length of this fragment.
  *	This field is zero when the queue slot is empty.
  * @unmap_len: Length of this fragment to unmap
+ * @dma_offset: Offset of @dma_addr from the address of the backing DMA mapping.
+ * Only valid if @unmap_len != 0.
  */
 struct efx_tx_buffer {
 	union {
@@ -154,6 +156,7 @@ struct efx_tx_buffer {
 	unsigned short flags;
 	unsigned short len;
 	unsigned short unmap_len;
+	unsigned short dma_offset;
 };
 #define EFX_TX_BUF_CONT		1	/* not last descriptor of packet */
 #define EFX_TX_BUF_SKB		2	/* buffer is last part of skb */
diff --git a/drivers/net/ethernet/sfc/tx.c b/drivers/net/ethernet/sfc/tx.c
index 282692c..c49d1fb 100644
--- a/drivers/net/ethernet/sfc/tx.c
+++ b/drivers/net/ethernet/sfc/tx.c
@@ -65,8 +65,7 @@ static void efx_dequeue_buffer(struct efx_tx_queue *tx_queue,
 {
 	if (buffer->unmap_len) {
 		struct device *dma_dev = &tx_queue->efx->pci_dev->dev;
-		dma_addr_t unmap_addr = (buffer->dma_addr + buffer->len -
-					 buffer->unmap_len);
+		dma_addr_t unmap_addr = buffer->dma_addr - buffer->dma_offset;
 		if (buffer->flags & EFX_TX_BUF_MAP_SINGLE)
 			dma_unmap_single(dma_dev, unmap_addr, buffer->unmap_len,
 					 DMA_TO_DEVICE);
@@ -414,6 +413,7 @@ netdev_tx_t efx_enqueue_skb(struct efx_tx_queue *tx_queue, struct sk_buff *skb)
 		/* Transfer ownership of the unmapping to the final buffer */
 		buffer->flags = EFX_TX_BUF_CONT | dma_flags;
 		buffer->unmap_len = unmap_len;
+		buffer->dma_offset = buffer->dma_addr - unmap_addr;
 		unmap_len = 0;
 
 		/* Get address and size of next fragment */
@@ -980,6 +980,7 @@ static int efx_tso_put_header(struct efx_tx_queue *tx_queue,
 			return -ENOMEM;
 		}
 		buffer->unmap_len = buffer->len;
+		buffer->dma_offset = 0;
 		buffer->flags |= EFX_TX_BUF_MAP_SINGLE;
 	}
 
@@ -1121,6 +1122,7 @@ static void tso_fill_packet_with_fragment(struct efx_tx_queue *tx_queue,
 	if (st->in_len == 0) {
 		/* Transfer ownership of the DMA mapping */
 		buffer->unmap_len = st->unmap_len;
+		buffer->dma_offset = buffer->unmap_len - buffer->len;
 		buffer->flags |= st->dma_flags;
 		st->unmap_len = 0;
 	}
@@ -1219,6 +1221,7 @@ static int tso_start_new_packet(struct efx_tx_queue *tx_queue,
 		if (is_last) {
 			buffer->flags = EFX_TX_BUF_CONT | EFX_TX_BUF_MAP_SINGLE;
 			buffer->unmap_len = st->header_unmap_len;
+			buffer->dma_offset = 0;
 			/* Ensure we only unmap them once in case of a
 			 * later DMA mapping error and rollback
 			 */

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

^ permalink raw reply related

* Pull request: sfc-next 2013-11-01
From: Ben Hutchings @ 2013-11-02  1:37 UTC (permalink / raw)
  To: David Miller; +Cc: linux-net-drivers, netdev

The following changes since commit ba4865027c11d7ac8e5a33e0624dd415caab2027:

  ipv6: remove the unnecessary statement in find_match() (2013-10-30 17:06:51 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-next.git for-davem

for you to fetch changes up to 2acdb92e85412bf791a3c01f2173695b6e0a3f72:

  sfc: Fix DMA unmapping issue with firmware assisted TSO (2013-10-31 20:58:14 +0000)

A single fix by Alexandre Rames for the recent changes to TSO.

Ben.

----------------------------------------------------------------
Alexandre Rames (1):
      sfc: Fix DMA unmapping issue with firmware assisted TSO

 drivers/net/ethernet/sfc/net_driver.h | 3 +++
 drivers/net/ethernet/sfc/tx.c         | 7 +++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

^ permalink raw reply

* Re: [PATCH v3 net-next] net: pkt_sched: PIE AQM scheme
From: Eric Dumazet @ 2013-11-02  0:56 UTC (permalink / raw)
  To: Vijay Subramanian; +Cc: netdev, davem, shemminger, Mythili Prabhu, Dave Taht
In-Reply-To: <1383338722-6000-1-git-send-email-subramanian.vijay@gmail.com>

On Fri, 2013-11-01 at 13:45 -0700, Vijay Subramanian wrote:

> +
> +	if (!drop_early(sch, skb->len)) {
> +		/* we can enqueue the packet */
> +		q->stats.packets_in++;
> +
> +		if (qdisc_qlen(sch) > q->stats.maxq)
> +			q->stats.maxq = qdisc_qlen(sch);
> +
> +		return qdisc_enqueue_tail(skb, sch);

I am not sure why you mix skb->len and qdisc_len(skb)

Also, a default 200 packets limit sounds strange, was it actually tested
on a 10Gb link ?

Other than that, patch seems fine, thanks !

^ permalink raw reply

* Re: [PATCH] bnx2: Use dev_kfree_skb_any() in bnx2_tx_int()
From: Ben Hutchings @ 2013-11-01 23:34 UTC (permalink / raw)
  To: David Miller; +Cc: xiyou.wangcong, mchan, tdmackey, netdev, linux-kernel
In-Reply-To: <20131101.180147.629210014672277622.davem@davemloft.net>

On Fri, 2013-11-01 at 18:01 -0400, David Miller wrote:
> From: Cong Wang <xiyou.wangcong@gmail.com>
> Date: Thu, 31 Oct 2013 21:19:16 -0700
> 
> > 2013年10月30日 下午9:26于 "David Miller" <davem@davemloft.net>写道:
> >>
> >> We have to provide a softint compatible environment for this callback
> >> to run in else everything is completely broken.
> >>
> >> All these drivers can safely assume softirq safe locking is
> >> sufficient, you're suggesting we need to take this hardirq safety and
> >> I'm really not willing to allow things to go that far.  A lot of
> >> effort has been expended precisely to avoid that kind of overhead and
> >> cost.
> > 
> > Alright, I am thinking to move netpoll_poll_dev() to a delayed work.
>  
> What if the printk is outputting a message that will help us discover
> that work queues are deadlocked?
> 
> You can't delay the message, because every layer of indirection you
> add increases the possibility that the message it never seen.  You
> have to do it synchronously.

As you've said, the ndo_start_xmit and NAPI poll operations are intended
to be called in softirq context, so everything that interlocks with them
will use spin_lock_bh().  Calling them from hardirq context obviously
opens the possibility of a deadlock.  How do you expect anyone to solve
that?

I think that most of the time netpoll doesn't actually call the NAPI
poll function, and the driver ndo_start_xmit function doesn't take any
locks, so we don't actually hit the deadlock in practice (on mainline
kernels - RT is a different story).

Obviously, the less machinery netpoll relies on continuing to work, the
better, so it should preferably defer to sofirq context rather than
workqueue context.  I think this means hooking queue_process() into
net_tx_action(), and then cutting out much of the rest of netpoll.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

^ permalink raw reply

* Re: [Bug 63871] New: BUG skbuff_head_cache (Tainted: G        W ): Object padding overwritten
From: Hannes Frederic Sowa @ 2013-11-01 23:08 UTC (permalink / raw)
  To: Andrew Morton; +Cc: netdev, bugzilla-daemon, mikhail.v.gavrilov
In-Reply-To: <20131101155620.b4388760cfb8562430e3039c@linux-foundation.org>

On Fri, Nov 01, 2013 at 03:56:20PM -0700, Andrew Morton wrote:
> 
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
> 
> Possible networking memory scribble?
> 
> On Sun, 27 Oct 2013 16:01:39 +0000 bugzilla-daemon@bugzilla.kernel.org wrote:
> 
> > [12745.265370]  [<ffffffff815df9fe>] __alloc_skb+0x4e/0x2b0
> > [12745.265372]  [<ffffffff815d8de4>] sock_wmalloc+0x34/0x90
> > [12745.265375]  [<ffffffff8163a803>] __ip_append_data.isra.44+0x7c3/0x9c0
> > [12745.265377]  [<ffffffff816385a0>] ? ip_reply_glue_bits+0x60/0x60
> > [12745.265378]  [<ffffffff816384aa>] ? ip_setup_cork+0x7a/0x110
> > [12745.265380]  [<ffffffff8163c4f3>] ip_make_skb+0x113/0x160
> > [12745.265382]  [<ffffffff816385a0>] ? ip_reply_glue_bits+0x60/0x60
> > [12745.265384]  [<ffffffff8162e400>] ? __ip_route_output_key+0x360/0xb20
> > [12745.265386]  [<ffffffff81669faa>] udp_sendmsg+0x2ba/0xb70

Maybe this is the fix for this:

http://patchwork.ozlabs.org/patch/285292/

Greetings,

  Hannes

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox