Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] net sysctl: Add place holder functions for when sysctl support is compiled out of the kernel.
From: Randy Dunlap @ 2012-04-23 22:38 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: David Miller, Stephen Rothwell, linux-next, LKML, netdev
In-Reply-To: <m1lilmt7v5.fsf_-_@fess.ebiederm.org>

On 04/23/2012 03:13 PM, Eric W. Biederman wrote:

> 
> Randy Dunlap <rdunlap@xenotime.net> reported:
>> On 04/23/2012 12:07 AM, Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> Changes since 20120420:
>>
>>
>>
>> ERROR: "unregister_net_sysctl_table" [net/phonet/phonet.ko] undefined!
>> ERROR: "register_net_sysctl" [net/phonet/phonet.ko] undefined!
>>
>> when CONFIG_SYSCTL is not enabled.
> 
> Add static inline stub functions to gracefully handle the case when sysctl
> support is not present.
> 
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>


Yep, that works.

Acked-by: Randy Dunlap <rdunlap@xenotime.net>

Thanks.

> ---
>  include/net/net_namespace.h |   15 ++++++++++++---
>  1 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> index 3ee4a3d..ac9195e 100644
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -284,11 +284,20 @@ struct ctl_table_header;
>  
>  #ifdef CONFIG_SYSCTL
>  extern int net_sysctl_init(void);
> -#else
> -static inline int net_sysctl_init(void) { return 0; }
> -#endif
>  extern struct ctl_table_header *register_net_sysctl(struct net *net,
>  	const char *path, struct ctl_table *table);
>  extern void unregister_net_sysctl_table(struct ctl_table_header *header);
> +#else
> +static inline int net_sysctl_init(void) { return 0; }
> +static inline struct ctl_table_header *register_net_sysctl(struct net *net,
> +	const char *path, struct ctl_table *table)
> +{
> +	return NULL;
> +}
> +static inline void unregister_net_sysctl_table(struct ctl_table_header *header)
> +{
> +}
> +#endif
> +
>  
>  #endif /* __NET_NET_NAMESPACE_H */



-- 
~Randy

^ permalink raw reply

* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Jesse Gross @ 2012-04-23 22:59 UTC (permalink / raw)
  To: Simon Horman
  Cc: dev-yBygre7rU0TnMu66kgdUjQ, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
	netdev-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
	stephen.hemminger-ZtmgI6mnKB3QT0dZR+AlfA,
	shemminger-ZtmgI6mnKB3QT0dZR+AlfA, David Miller
In-Reply-To: <20120423223255.GG580-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>

On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
>> On Mon, Apr 23, 2012 at 2:08 PM, David Miller <davem@davemloft.net> wrote:
>> > From: Jesse Gross <jesse@nicira.com>
>> > Date: Mon, 23 Apr 2012 13:53:42 -0700
>> >
>> >> On Mon, Apr 23, 2012 at 1:13 PM, David Miller <davem@davemloft.net> wrote:
>> >>> From: Jesse Gross <jesse@nicira.com>
>> >>> Date: Mon, 23 Apr 2012 13:08:49 -0700
>> >>>
>> >>>> Assuming that the TCP stack generates large TSO frames on transmit
>> >>>> (which could be the local stack; something sent by a VM; or packets
>> >>>> received, coalesced by GRO and then encapsulated by STT) then you can
>> >>>> just prepend the STT header (possibly slightly adjusting things like
>> >>>> requested MSS, number of segments, etc. slightly).  After that it's
>> >>>> possible to just output the resulting frame through the IP stack like
>> >>>> all tunnels do today.
>> >>>
>> >>> Which seems to potentially suggest a stronger intergration of the STT
>> >>> tunnel transmit path into our IP stack rather than the approach Simon
>> >>> is taking
>> >>
>> >> Did you have something in mind?
>> >
>> > A normal bonafide tunnel netdevice driver like GRE instead of the
>> > openvswitch approach Simon is using.
>>
>> Ahh, yes, that I agree with.  Independent of this, there's work being
>> done to make it so that OVS can use the normal in-tree tunneling code
>> and not need its own.  Once that's done I expect that STT will follow
>> the same model.
>
> Hi Jesse,
>
> I am wondering how firm the plans to on allowing OVS to use in-tree tunnel
> code are. I'm happy to move my efforts over to an in-tree STT implementation
> but ultimately I would like to get STT running in conjunction with OVS.

I would say that it's a firm goal but the implementation probably
still has a ways to go.  Kyle Mestery (CC'ed) has volunteered to work
on this in support of adding VXLAN, which needs some additional
flexibility that this approach would also provide.  You might want to
talk to him to see if there are ways that you guys can work together
on it if you are interested.  Having better integration with upstream
tunneling is definitely a step that OVS needs to make and sooner would
be better than later.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply

* Re: [PATCH RFC 0/2] e1000e: 82574 also needs ASPM L1 completely disabled
From: Jesse Brandeburg @ 2012-04-23 23:11 UTC (permalink / raw)
  To: Chris Boot; +Cc: e1000-devel, netdev, nix, linux-kernel
In-Reply-To: <1335216578-21542-1-git-send-email-bootc@bootc.net>


[-- Attachment #1.1: Type: text/plain, Size: 763 bytes --]

On Mon, 23 Apr 2012 22:29:36 +0100
Chris Boot <bootc@bootc.net> wrote:
> Please note I haven't as-yet tested this code at all, but I do know that
> disabling ASPM L1 on these NICs (using setpci) fixes the hangs that I
> have been seeing on my Supermicro servers with X9SCL-F boards. I hope to
> get the chance to install an updated kernel on my two afftected servers
> later this week.
> 
> Chris Boot (2):
>   e1000e: Disable ASPM L1 on 82574
>   e1000e: Remove special case for 82573/82574 ASPM L1 disablement

Thanks Chris, we are going to take a look over the patches and Jeff
Kirsher should apply them to our internal testing tree.

Please let us know the results of your testing, we will let you know if
we see any issues as well.

Jesse

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

[-- Attachment #2: Type: text/plain, Size: 272 bytes --]

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

[-- Attachment #3: Type: text/plain, Size: 257 bytes --]

_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

^ permalink raw reply

* Re: [PATCH 1/2] e1000e: Disable ASPM L1 on 82574
From: Jeff Kirsher @ 2012-04-23 23:18 UTC (permalink / raw)
  To: Chris Boot; +Cc: e1000-devel, netdev, nix, linux-kernel
In-Reply-To: <1335216578-21542-2-git-send-email-bootc@bootc.net>


[-- Attachment #1.1: Type: text/plain, Size: 617 bytes --]

On Mon, 2012-04-23 at 22:29 +0100, Chris Boot wrote:
> 
> ASPM on the 82574 causes trouble. Currently the driver disables L0s
> for
> this NIC but only disables L1 if the MTU is >1500. This patch simply
> causes L1 to be disabled regardless of the MTU setting.
> 
> Signed-off-by: Chris Boot <bootc@bootc.net>
> Cc: "Wyborny, Carolyn" <carolyn.wyborny@intel.com>
> Cc: Nix <nix@esperi.org.uk>
> Link: https://lkml.org/lkml/2012/3/19/362
> ---
>  drivers/net/ethernet/intel/e1000e/82571.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-) 

I have added the patch to my queue, thanks Chris!

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 272 bytes --]

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

[-- Attachment #3: Type: text/plain, Size: 257 bytes --]

_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

^ permalink raw reply

* Re: [PATCH 2/2] e1000e: Remove special case for 82573/82574 ASPM L1 disablement
From: Jeff Kirsher @ 2012-04-23 23:18 UTC (permalink / raw)
  To: Chris Boot; +Cc: e1000-devel, netdev, nix, linux-kernel
In-Reply-To: <1335216578-21542-3-git-send-email-bootc@bootc.net>


[-- Attachment #1.1: Type: text/plain, Size: 521 bytes --]

On Mon, 2012-04-23 at 22:29 +0100, Chris Boot wrote:
> For the 82573, ASPM L1 gets disabled wholesale so this special-case
> code
> is not required. For the 82574 the previous patch does the same as for
> the 82573, disabling L1 on the adapter. Thus, this code is no longer
> required and can be removed.
> 
> Signed-off-by: Chris Boot <bootc@bootc.net>
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c |    8 --------
>  1 file changed, 8 deletions(-) 

I have added the patch to my queue, thanks Chris!

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 272 bytes --]

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

[-- Attachment #3: Type: text/plain, Size: 257 bytes --]

_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

^ permalink raw reply

* Re: [PATCH] net sysctl: Add place holder functions for when sysctl support is compiled out of the kernel.
From: David Miller @ 2012-04-23 23:24 UTC (permalink / raw)
  To: rdunlap; +Cc: ebiederm, sfr, linux-next, linux-kernel, netdev
In-Reply-To: <4F95D9F5.3040407@xenotime.net>

From: Randy Dunlap <rdunlap@xenotime.net>
Date: Mon, 23 Apr 2012 15:38:45 -0700

> On 04/23/2012 03:13 PM, Eric W. Biederman wrote:
> 
>> 
>> Randy Dunlap <rdunlap@xenotime.net> reported:
>>> On 04/23/2012 12:07 AM, Stephen Rothwell wrote:
>>>
>>>> Hi all,
>>>>
>>>> Changes since 20120420:
>>>
>>>
>>>
>>> ERROR: "unregister_net_sysctl_table" [net/phonet/phonet.ko] undefined!
>>> ERROR: "register_net_sysctl" [net/phonet/phonet.ko] undefined!
>>>
>>> when CONFIG_SYSCTL is not enabled.
>> 
>> Add static inline stub functions to gracefully handle the case when sysctl
>> support is not present.
>> 
>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> 
> 
> Yep, that works.
> 
> Acked-by: Randy Dunlap <rdunlap@xenotime.net>

Applied, thanks everyone.

^ permalink raw reply

* Re: [PATCH 01/16] mm: Serialize access to min_free_kbytes
From: David Rientjes @ 2012-04-23 23:50 UTC (permalink / raw)
  To: Mel Gorman
  Cc: Andrew Morton, Linux-MM, Linux-Netdev, LKML, David Miller,
	Neil Brown, Peter Zijlstra, Mike Christie, Eric B Munson
In-Reply-To: <1334578624-23257-2-git-send-email-mgorman@suse.de>

On Mon, 16 Apr 2012, Mel Gorman wrote:

> There is a race between the min_free_kbytes sysctl, memory hotplug
> and transparent hugepage support enablement.  Memory hotplug uses a
> zonelists_mutex to avoid a race when building zonelists. Reuse it to
> serialise watermark updates.
> 
> [a.p.zijlstra@chello.nl: Older patch fixed the race with spinlock]
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> Reviewed-by: Rik van Riel <riel@redhat.com>

Acked-by: David Rientjes <rientjes@google.com>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: [PATCH 02/16] mm: sl[au]b: Add knowledge of PFMEMALLOC reserve pages
From: David Rientjes @ 2012-04-23 23:51 UTC (permalink / raw)
  To: Mel Gorman
  Cc: Andrew Morton, Linux-MM, Linux-Netdev, LKML, David Miller,
	Neil Brown, Peter Zijlstra, Mike Christie, Eric B Munson
In-Reply-To: <1334578624-23257-3-git-send-email-mgorman@suse.de>

On Mon, 16 Apr 2012, Mel Gorman wrote:

> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 280eabe..0fa2c72 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1463,6 +1463,7 @@ failed:
>  #define ALLOC_HARDER		0x10 /* try to alloc harder */
>  #define ALLOC_HIGH		0x20 /* __GFP_HIGH set */
>  #define ALLOC_CPUSET		0x40 /* check for correct cpuset */
> +#define ALLOC_PFMEMALLOC	0x80 /* Caller has PF_MEMALLOC set */
>  
>  #ifdef CONFIG_FAIL_PAGE_ALLOC
>  
> @@ -2208,16 +2209,22 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
>  	} else if (unlikely(rt_task(current)) && !in_interrupt())
>  		alloc_flags |= ALLOC_HARDER;
>  
> -	if (likely(!(gfp_mask & __GFP_NOMEMALLOC))) {
> -		if (!in_interrupt() &&
> -		    ((current->flags & PF_MEMALLOC) ||
> -		     unlikely(test_thread_flag(TIF_MEMDIE))))
> +	if ((current->flags & PF_MEMALLOC) ||
> +			unlikely(test_thread_flag(TIF_MEMDIE))) {
> +		alloc_flags |= ALLOC_PFMEMALLOC;
> +
> +		if (likely(!(gfp_mask & __GFP_NOMEMALLOC)) && !in_interrupt())
>  			alloc_flags |= ALLOC_NO_WATERMARKS;
>  	}
>  
>  	return alloc_flags;
>  }
>  
> +bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
> +{
> +	return !!(gfp_to_alloc_flags(gfp_mask) & ALLOC_PFMEMALLOC);
> +}
> +
>  static inline struct page *
>  __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
>  	struct zonelist *zonelist, enum zone_type high_zoneidx,
> @@ -2407,8 +2414,16 @@ nopage:
>  got_pg:
>  	if (kmemcheck_enabled)
>  		kmemcheck_pagealloc_alloc(page, order, gfp_mask);
> -	return page;
>  
> +	/*
> +	 * page->pfmemalloc is set when the caller had PFMEMALLOC set or is
> +	 * been OOM killed. The expectation is that the caller is taking
> +	 * steps that will free more memory. The caller should avoid the
> +	 * page being used for !PFMEMALLOC purposes.
> +	 */
> +	page->pfmemalloc = !!(alloc_flags & ALLOC_PFMEMALLOC);
> +
> +	return page;
>  }
>  
>  /*

I think this is slightly inconsistent if the page allocation succeeded 
without needing ALLOC_NO_WATERMARKS, meaning that page was allocated above 
the min watermark.  That's possible if the slowpath's first call to 
get_page_from_freelist() succeeds without needing 
__alloc_pages_high_priority().  So perhaps we need to do something like

	got_pg_memalloc:
		...
		page->pfmemalloc = !!(alloc_flags & ALLOC_PFMEMALLOC);
	got_pg:
		if (kmemcheck_enabled)
			kmemcheck_pagealloc_alloc(page, order, gfp_mask);
		return page;

and use got_pg_memalloc everywhere we currently use got_pg other than the 
when it succeeds with ALLOC_NO_WATERMARKS.

> @@ -2459,6 +2474,8 @@ retry_cpuset:
>  		page = __alloc_pages_slowpath(gfp_mask, order,
>  				zonelist, high_zoneidx, nodemask,
>  				preferred_zone, migratetype);
> +	else
> +		page->pfmemalloc = false;
>  
>  	trace_mm_page_alloc(page, order, gfp_mask, migratetype);
>  

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: linux-next: Tree for Apr 23 (ax.25 sysctl)
From: Eric W. Biederman @ 2012-04-24  0:16 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, linux-next, LKML, netdev, linux-hams,
	Ralf Baechle
In-Reply-To: <4F95828A.8050403@xenotime.net>

Randy Dunlap <rdunlap@xenotime.net> writes:

> On 04/23/2012 12:07 AM, Stephen Rothwell wrote:
>
>> Hi all,
>> 
>> Changes since 20120420:
>
>
>
> include/net/ax25.h:447:75: error: expected ';' before '}' token
>
>
> static inline int ax25_register_dev_sysctl(ax25_dev *ax25_dev) { return 0 };
> static inline void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev) {};
>
> Is this from Eric B.'s sysctl patches?

Sort of.  I made the function per device and return 0.

I missed the inner ';' when I made the change.  The outer '};' has
been there for years and has been weird but harmless.

Patch to fix it in a moment.

Eric


> First function:  move ';' inside braces.
> Second function:  drop the ';'.

^ permalink raw reply

* [PATCH] net ax25: Fix the build when sysctl support is disabled.
From: Eric W. Biederman @ 2012-04-24  0:23 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, linux-next, LKML, netdev, linux-hams,
	Ralf Baechle
In-Reply-To: <4F95828A.8050403@xenotime.net>


Randy Dunlap <rdunlap@xenotime.net> reported:

> On 04/23/2012 12:07 AM, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20120420:
>
>
> include/net/ax25.h:447:75: error: expected ';' before '}' token
>
> static inline int ax25_register_dev_sysctl(ax25_dev *ax25_dev) { return 0 };
> static inline void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev) {};
>
> First function:  move ';' inside braces.
> Second function:  drop the ';'.

Put the semicolons where it makes sense.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 include/net/ax25.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/net/ax25.h b/include/net/ax25.h
index 8a7a122..5d23521 100644
--- a/include/net/ax25.h
+++ b/include/net/ax25.h
@@ -444,8 +444,8 @@ extern void ax25_uid_free(void);
 extern int ax25_register_dev_sysctl(ax25_dev *ax25_dev);
 extern void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev);
 #else
-static inline int ax25_register_dev_sysctl(ax25_dev *ax25_dev) { return 0 };
-static inline void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev) {};
+static inline int ax25_register_dev_sysctl(ax25_dev *ax25_dev) { return 0; }
+static inline void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev) {}
 #endif /* CONFIG_SYSCTL */
 
 #endif
-- 
1.7.2.5


^ permalink raw reply related

* [PATCH] net ax25: Fix the build when sysctl support is disabled.
From: Eric W. Biederman @ 2012-04-24  0:25 UTC (permalink / raw)
  To: David Miller
  Cc: Stephen Rothwell, linux-next, LKML, netdev, linux-hams,
	Ralf Baechle, Randy Dunlap
In-Reply-To: <4F95828A.8050403@xenotime.net>


Randy Dunlap <rdunlap@xenotime.net> reported:

> On 04/23/2012 12:07 AM, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20120420:
>
>
> include/net/ax25.h:447:75: error: expected ';' before '}' token
>
> static inline int ax25_register_dev_sysctl(ax25_dev *ax25_dev) { return 0 };
> static inline void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev) {};
>
> First function:  move ';' inside braces.
> Second function:  drop the ';'.

Put the semicolons where it makes sense.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---

Resent to include David Miller.

 include/net/ax25.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/net/ax25.h b/include/net/ax25.h
index 8a7a122..5d23521 100644
--- a/include/net/ax25.h
+++ b/include/net/ax25.h
@@ -444,8 +444,8 @@ extern void ax25_uid_free(void);
 extern int ax25_register_dev_sysctl(ax25_dev *ax25_dev);
 extern void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev);
 #else
-static inline int ax25_register_dev_sysctl(ax25_dev *ax25_dev) { return 0 };
-static inline void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev) {};
+static inline int ax25_register_dev_sysctl(ax25_dev *ax25_dev) { return 0; }
+static inline void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev) {}
 #endif /* CONFIG_SYSCTL */
 
 #endif
-- 
1.7.2.5

^ permalink raw reply related

* Re: [PATCH net-next] tcp: introduce tcp_try_coalesce
From: Neal Cardwell @ 2012-04-24  1:13 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: David Miller, netdev, Tom Herbert, Maciej Żenczykowski,
	Ilpo Järvinen
In-Reply-To: <1335201102.5205.28.camel@edumazet-glaptop>

On Mon, Apr 23, 2012 at 1:11 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> commit c8628155ece3 (tcp: reduce out_of_order memory use) took care of
> coalescing tcp segments provided by legacy devices (linear skbs)
>
> We extend this idea to fragged skbs, as their truesize can be heavy.
>
> ixgbe for example uses 256+1024+PAGE_SIZE/2 = 3328 bytes per segment.
>
> Use this coalescing strategy for receive queue too.
>
> This contributes to reduce number of tcp collapses, at minimal cost, and
> reduces memory overhead and packets drops.

The mechanics look solid, but I'm a little concerned about the
potential added overhead for the new case where tcp_try_coalesce()
does a skb_copy_bits() for in-order data that it is coalescing at the
end of the sk_receive_queue. Do you have any performance numbers for
this case to help suggest whether this added copy is a concern?

neal

^ permalink raw reply

* Re: [PATCH] net ax25: Fix the build when sysctl support is disabled.
From: Randy Dunlap @ 2012-04-24  1:28 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: David Miller, Stephen Rothwell, linux-next, LKML, netdev,
	linux-hams, Ralf Baechle
In-Reply-To: <m1obqirn5e.fsf_-_@fess.ebiederm.org>

On 04/23/2012 05:25 PM, Eric W. Biederman wrote:

> 
> Randy Dunlap <rdunlap@xenotime.net> reported:
> 
>> On 04/23/2012 12:07 AM, Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> Changes since 20120420:
>>
>>
>> include/net/ax25.h:447:75: error: expected ';' before '}' token
>>
>> static inline int ax25_register_dev_sysctl(ax25_dev *ax25_dev) { return 0 };
>> static inline void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev) {};
>>
>> First function:  move ';' inside braces.
>> Second function:  drop the ';'.
> 
> Put the semicolons where it makes sense.
> 
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>


Acked-by: Randy Dunlap <rdunlap@xenotime.net>

Thanks.

> ---
> 
> Resent to include David Miller.
> 
>  include/net/ax25.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/net/ax25.h b/include/net/ax25.h
> index 8a7a122..5d23521 100644
> --- a/include/net/ax25.h
> +++ b/include/net/ax25.h
> @@ -444,8 +444,8 @@ extern void ax25_uid_free(void);
>  extern int ax25_register_dev_sysctl(ax25_dev *ax25_dev);
>  extern void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev);
>  #else
> -static inline int ax25_register_dev_sysctl(ax25_dev *ax25_dev) { return 0 };
> -static inline void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev) {};
> +static inline int ax25_register_dev_sysctl(ax25_dev *ax25_dev) { return 0; }
> +static inline void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev) {}
>  #endif /* CONFIG_SYSCTL */
>  
>  #endif



-- 
~Randy

^ permalink raw reply

* linux-next: manual merge of the net-next tree with the infiniband tree
From: Stephen Rothwell @ 2012-04-24  2:06 UTC (permalink / raw)
  To: David Miller, netdev-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-next-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Roland Dreier,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA, Parav Pandit, Ajit Khaparde

[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/emulex/benet/be.h between commit c72adfd767af
("be2net: Add functionality to support RoCE driver") from the infiniband
tree and commit 42f11cf20cc5 ("be2net: fix ethtool get settings") from
the net-next tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org

diff --cc drivers/net/ethernet/emulex/benet/be.h
index 7bb2e97,ad69cf8..0000000
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@@ -379,22 -394,7 +396,18 @@@ struct be_adapter 
  	u32 rx_fc;		/* Rx flow control */
  	u32 tx_fc;		/* Tx flow control */
  	bool stats_cmd_sent;
- 	int link_speed;
- 	u8 port_type;
- 	u8 transceiver;
- 	u8 autoneg;
  	u8 generation;		/* BladeEngine ASIC generation */
 +	u32 if_type;
 +	struct {
 +		u8 __iomem *base;	/* Door Bell */
 +		u32 size;
 +		u32 total_size;
 +		u64 io_addr;
 +	} roce_db;
 +	u32 num_msix_roce_vec;
 +	struct ocrdma_dev *ocrdma_dev;
 +	struct list_head entry;
 +
  	u32 flash_status;
  	struct completion flash_compl;
  
@@@ -606,17 -597,5 +620,18 @@@ extern void be_link_status_update(struc
  extern void be_parse_stats(struct be_adapter *adapter);
  extern int be_load_fw(struct be_adapter *adapter, u8 *func);
  extern bool be_is_wol_supported(struct be_adapter *adapter);
+ extern bool be_pause_supported(struct be_adapter *adapter);
 +
 +/*
 + * internal function to initialize-cleanup roce device.
 + */
 +extern void be_roce_dev_add(struct be_adapter *);
 +extern void be_roce_dev_remove(struct be_adapter *);
 +
 +/*
 + * internal function to open-close roce device during ifup-ifdown.
 + */
 +extern void be_roce_dev_open(struct be_adapter *);
 +extern void be_roce_dev_close(struct be_adapter *);
 +
  #endif				/* BE_H */

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH net-next] tcp: introduce tcp_try_coalesce
From: Eric Dumazet @ 2012-04-24  2:13 UTC (permalink / raw)
  To: Neal Cardwell
  Cc: David Miller, netdev, Tom Herbert, Maciej Żenczykowski,
	Ilpo Järvinen
In-Reply-To: <CADVnQyngwym7z_zSi8h2U_1e_wVCwGMPZScywWFWM2AYvxyqjw@mail.gmail.com>

On Mon, 2012-04-23 at 21:13 -0400, Neal Cardwell wrote:
> On Mon, Apr 23, 2012 at 1:11 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > commit c8628155ece3 (tcp: reduce out_of_order memory use) took care of
> > coalescing tcp segments provided by legacy devices (linear skbs)
> >
> > We extend this idea to fragged skbs, as their truesize can be heavy.
> >
> > ixgbe for example uses 256+1024+PAGE_SIZE/2 = 3328 bytes per segment.
> >
> > Use this coalescing strategy for receive queue too.
> >
> > This contributes to reduce number of tcp collapses, at minimal cost, and
> > reduces memory overhead and packets drops.
> 
> The mechanics look solid, but I'm a little concerned about the
> potential added overhead for the new case where tcp_try_coalesce()
> does a skb_copy_bits() for in-order data that it is coalescing at the
> end of the sk_receive_queue. Do you have any performance numbers for
> this case to help suggest whether this added copy is a concern?
> 
> neal

This never happens on connections where performance matters : skb head
can only contains one full mss segment.

This part is only used on wifi devices, where skb head is really fat.

^ permalink raw reply

* Re: [PATCH] net ax25: Fix the build when sysctl support is disabled.
From: David Miller @ 2012-04-24  2:15 UTC (permalink / raw)
  To: rdunlap; +Cc: ebiederm, sfr, linux-next, linux-kernel, netdev, linux-hams, ralf
In-Reply-To: <4F9601CD.2070000@xenotime.net>

From: Randy Dunlap <rdunlap@xenotime.net>
Date: Mon, 23 Apr 2012 18:28:45 -0700

> On 04/23/2012 05:25 PM, Eric W. Biederman wrote:
> 
>> 
>> Randy Dunlap <rdunlap@xenotime.net> reported:
>> 
>>> On 04/23/2012 12:07 AM, Stephen Rothwell wrote:
>>>
>>>> Hi all,
>>>>
>>>> Changes since 20120420:
>>>
>>>
>>> include/net/ax25.h:447:75: error: expected ';' before '}' token
>>>
>>> static inline int ax25_register_dev_sysctl(ax25_dev *ax25_dev) { return 0 };
>>> static inline void ax25_unregister_dev_sysctl(ax25_dev *ax25_dev) {};
>>>
>>> First function:  move ';' inside braces.
>>> Second function:  drop the ';'.
>> 
>> Put the semicolons where it makes sense.
>> 
>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> 
> 
> Acked-by: Randy Dunlap <rdunlap@xenotime.net>

Applied, thanks guys.

^ permalink raw reply

* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Eric Dumazet @ 2012-04-24  2:20 UTC (permalink / raw)
  To: David Miller
  Cc: rick.jones2, netdev, therbert, ncardwell, maze, ycheng,
	ilpo.jarvinen
In-Reply-To: <1335213446.5205.65.camel@edumazet-glaptop>

On Mon, 2012-04-23 at 22:37 +0200, Eric Dumazet wrote:

> We could try to coalesce ACKs before backlogging them. I'll work on
> this.
> 

I did an experiment, and found a basic coalescing was not working in
case of packet loss and SACK storm.

Doing a smart coalescing in this case sounds really complex.

Should we really continue this way ? 


 include/net/tcp.h   |    1 +
 net/ipv4/tcp_ipv4.c |   32 +++++++++++++++++++++++++++++++-
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index fc880e9..de8d847 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1418,6 +1418,7 @@ static inline unsigned int tcp_stream_is_thin(struct tcp_sock *tp)
 	return tp->packets_out < 4 && !tcp_in_initial_slowstart(tp);
 }
 
+extern bool tcp_ack_coalesce(struct sock *sk, struct sk_buff *skb);
 /* /proc */
 enum tcp_seq_states {
 	TCP_SEQ_STATE_LISTENING,
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 0883921..b5a3bac 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1670,6 +1670,36 @@ csum_err:
 }
 EXPORT_SYMBOL(tcp_v4_do_rcv);
 
+/* socket is owned by user.
+ * Before queuing this skb into backlog, try to coalesce it to previous skb.
+ * We only take care of pure ACKS.
+ */
+bool tcp_ack_coalesce(struct sock *sk, struct sk_buff *skb)
+{
+	struct sk_buff *prev = sk->sk_backlog.tail;
+	const struct tcphdr *th, *thp;
+	unsigned int i, thlen;
+
+	if (TCP_SKB_CB(skb)->seq != TCP_SKB_CB(skb)->end_seq ||
+	    !prev ||
+	    TCP_SKB_CB(skb)->seq != TCP_SKB_CB(prev)->end_seq)
+		return false;
+	th = tcp_hdr(skb);
+	thp = tcp_hdr(prev);
+	thlen = th->doff * 4;
+	i = sizeof(th->source) + sizeof(th->dest) +
+	    sizeof(th->seq) + sizeof(th->ack_seq);
+	for (; i < thlen; i += 4) {
+		if (*(u32 *)((u8 *)th + i) != *(u32 *)((u8 *)thp + i))
+			return false;
+	}
+	if (after(TCP_SKB_CB(skb)->ack_seq, TCP_SKB_CB(prev)->ack_seq))
+		TCP_SKB_CB(prev)->ack_seq = TCP_SKB_CB(skb)->ack_seq;
+	consume_skb(skb);
+	return true;
+}
+EXPORT_SYMBOL(tcp_ack_coalesce);
+
 /*
  *	From tcp_input.c
  */
@@ -1752,7 +1782,7 @@ process:
 			if (!tcp_prequeue(sk, skb))
 				ret = tcp_v4_do_rcv(sk, skb);
 		}
-	} else if (unlikely(sk_add_backlog(sk, skb))) {
+	} else if (!tcp_ack_coalesce(sk, skb) && sk_add_backlog(sk, skb)) {
 		bh_unlock_sock(sk);
 		NET_INC_STATS_BH(net, LINUX_MIB_TCPBACKLOGDROP);
 		goto discard_and_relse;

^ permalink raw reply related

* Re: [PATCH v2 1/5] don't attach a task to a dead cgroup
From: KAMEZAWA Hiroyuki @ 2012-04-24  2:20 UTC (permalink / raw)
  To: Glauber Costa
  Cc: Tejun Heo, netdev-u79uwXL29TY76Z2rM5mHXA,
	cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan, David Miller,
	devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <1335209867-1831-2-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>

(2012/04/24 4:37), Glauber Costa wrote:

> Not all external callers of cgroup_attach_task() test to
> see if the cgroup is still live - the internal callers at
> cgroup.c does.
> 
> With this test in cgroup_attach_task, we can assure that
> no tasks are ever moved to a cgroup that is past its
> destruction point and was already marked as dead.
> 
> Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> CC: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> CC: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> CC: Kamezawa Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>


Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>


> ---
>  kernel/cgroup.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index b61b938..932c318 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -1927,6 +1927,9 @@ int cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
>  	struct cgroup_taskset tset = { };
>  	struct css_set *newcg;
>  
> +	if (cgroup_is_removed(cgrp))
> +		return -ENODEV;
> +
>  	/* @tsk either already exited or can't exit until the end */
>  	if (tsk->flags & PF_EXITING)
>  		return -ESRCH;

^ permalink raw reply

* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Simon Horman @ 2012-04-24  2:25 UTC (permalink / raw)
  To: Jesse Gross
  Cc: dev-yBygre7rU0TnMu66kgdUjQ, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
	netdev-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
	stephen.hemminger-ZtmgI6mnKB3QT0dZR+AlfA,
	shemminger-ZtmgI6mnKB3QT0dZR+AlfA, David Miller
In-Reply-To: <CAEP_g=9p0TE59JbrS8QzHj4mEzc-5_hUDzmLRsRxLyUaFX+Z5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Mon, Apr 23, 2012 at 03:59:24PM -0700, Jesse Gross wrote:
> On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
> >> On Mon, Apr 23, 2012 at 2:08 PM, David Miller <davem@davemloft.net> wrote:
> >> > From: Jesse Gross <jesse@nicira.com>
> >> > Date: Mon, 23 Apr 2012 13:53:42 -0700
> >> >
> >> >> On Mon, Apr 23, 2012 at 1:13 PM, David Miller <davem@davemloft.net> wrote:
> >> >>> From: Jesse Gross <jesse@nicira.com>
> >> >>> Date: Mon, 23 Apr 2012 13:08:49 -0700
> >> >>>
> >> >>>> Assuming that the TCP stack generates large TSO frames on transmit
> >> >>>> (which could be the local stack; something sent by a VM; or packets
> >> >>>> received, coalesced by GRO and then encapsulated by STT) then you can
> >> >>>> just prepend the STT header (possibly slightly adjusting things like
> >> >>>> requested MSS, number of segments, etc. slightly).  After that it's
> >> >>>> possible to just output the resulting frame through the IP stack like
> >> >>>> all tunnels do today.
> >> >>>
> >> >>> Which seems to potentially suggest a stronger intergration of the STT
> >> >>> tunnel transmit path into our IP stack rather than the approach Simon
> >> >>> is taking
> >> >>
> >> >> Did you have something in mind?
> >> >
> >> > A normal bonafide tunnel netdevice driver like GRE instead of the
> >> > openvswitch approach Simon is using.
> >>
> >> Ahh, yes, that I agree with.  Independent of this, there's work being
> >> done to make it so that OVS can use the normal in-tree tunneling code
> >> and not need its own.  Once that's done I expect that STT will follow
> >> the same model.
> >
> > Hi Jesse,
> >
> > I am wondering how firm the plans to on allowing OVS to use in-tree tunnel
> > code are. I'm happy to move my efforts over to an in-tree STT implementation
> > but ultimately I would like to get STT running in conjunction with OVS.
> 
> I would say that it's a firm goal but the implementation probably
> still has a ways to go.  Kyle Mestery (CC'ed) has volunteered to work
> on this in support of adding VXLAN, which needs some additional
> flexibility that this approach would also provide.  You might want to
> talk to him to see if there are ways that you guys can work together
> on it if you are interested.  Having better integration with upstream
> tunneling is definitely a step that OVS needs to make and sooner would
> be better than later.

Hi Jesse, Hi Kyle,

that sounds like an excellent plan.

Kyle, do you have any thoughts on how we might best work together on this?
Perhaps there are some patches floating around that I could take a look at?

_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply

* Re: [PATCH v2 3/5] change number_of_cpusets to an atomic
From: KAMEZAWA Hiroyuki @ 2012-04-24  2:25 UTC (permalink / raw)
  To: Glauber Costa
  Cc: Tejun Heo, netdev-u79uwXL29TY76Z2rM5mHXA,
	cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan, David Miller,
	devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <1335209867-1831-4-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>

(2012/04/24 4:37), Glauber Costa wrote:

> This will allow us to call destroy() without holding the
> cgroup_mutex(). Other important updates inside update_flags()
> are protected by the callback_mutex.
> 
> We could protect this variable with the callback_mutex as well,
> as suggested by Li Zefan, but we need to make sure we are protected
> by that mutex at all times, and some of its updates happen inside the
> cgroup_mutex - which means we would deadlock.
> 
> An atomic variable is not expensive, since it is seldom updated,
> and protect us well.
> 
> Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>


Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>

^ permalink raw reply

* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: David Miller @ 2012-04-24  2:27 UTC (permalink / raw)
  To: eric.dumazet
  Cc: rick.jones2, netdev, therbert, ncardwell, maze, ycheng,
	ilpo.jarvinen
In-Reply-To: <1335234012.5205.97.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 24 Apr 2012 04:20:12 +0200

> On Mon, 2012-04-23 at 22:37 +0200, Eric Dumazet wrote:
> 
>> We could try to coalesce ACKs before backlogging them. I'll work on
>> this.
>> 
> 
> I did an experiment, and found a basic coalescing was not working in
> case of packet loss and SACK storm.
> 
> Doing a smart coalescing in this case sounds really complex.
> 
> Should we really continue this way ? 

We can consider it later, but for now let's defer.

I'll apply your sk_add_backlog patches for the time being.

Thanks Eric.

^ permalink raw reply

* Re: [PATCH net-next] tcp: introduce tcp_try_coalesce
From: Eric Dumazet @ 2012-04-24  2:29 UTC (permalink / raw)
  To: Neal Cardwell
  Cc: David Miller, netdev, Tom Herbert, Maciej Żenczykowski,
	Ilpo Järvinen
In-Reply-To: <1335233611.5205.90.camel@edumazet-glaptop>

On Tue, 2012-04-24 at 04:13 +0200, Eric Dumazet wrote:

> This never happens on connections where performance matters : skb head
> can only contains one full mss segment.

By the way, top end hardware uses fragged skbs.

Incidentally this gives better splice() performance (avoids copy of skb
head to pages)

^ permalink raw reply

* Re: [PATCH v1 6/8] dmaengine: enhance network subsystem to support DMA device hotplug
From: Jiang Liu @ 2012-04-24  2:30 UTC (permalink / raw)
  To: Dan Williams
  Cc: Jiang Liu, Vinod Koul, Keping Chen, David S. Miller,
	Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
	Patrick McHardy, netdev, linux-pci, linux-kernel
In-Reply-To: <CABE8wwvi_Yz8AyALr1-uDW9xSgrSqfrYWhB_22NQ2ydTa81+mg@mail.gmail.com>

Hi Dan,
	Thanks for your great comments!
	gerry
On 2012-4-24 2:30, Dan Williams wrote:
> On Mon, Apr 23, 2012 at 6:51 AM, Jiang Liu<liuj97@gmail.com>  wrote:
>> Enhance network subsystem to correctly update DMA channel reference counts,
>> so it won't break DMA device hotplug logic.
>>
>> Signed-off-by: Jiang Liu<liuj97@gmail.com>
>
> This introduces an atomic action on every channel touch, which is more
> expensive than what we had previously.  There has always been a
> concern about the overhead of offload that sometimes makes ineffective
> or a loss compared to cpu copies.  In the cases where net_dma shows
> improvement this will eat into / maybe eliminate that advantage.
Good point, we should avoid pollute a shared cacheline here, otherwise
it may eat the benefits of IOAT acceleration.

>
> Take a look at where dmaengine started [1].  It was from the beginning
> going through contortions to avoid something like this.  We made it
> simpler here [2], but still kept the principle of not dirtying a
> shared cacheline on every channel touch, and certainly not locking it.
Thanks for the great background information, especially the second one.
The check-in log message as below.
 >Why?, beyond reducing complication:
 >1/ Tracking reference counts per-transaction in an efficient manner, as
 >   is currently done, requires a complicated scheme to avoid cache-line
 >   bouncing effects.
The really issue here is polluting shared cachelines here, right?
Will it help to use percpu counter instead of atomic operations here?
I will have a try to use percpu counter for reference count.
BTW, do you have any DMAEngine benchmarks so we could use them to
compare the performance difference?

 >2/ Per-transaction ref-counting gives the false impression that a
 >   dma-driver can be gracefully removed ahead of its user (net, md, or
 >   dma-slave)
 >3/ None of the in-tree dma-drivers talk to hot pluggable hardware, but
Seems the situation has changed now:)
Intel 7500 (Boxboro) chipset supports hotplug. And we are working on
a system, which adopts Boxboro chipset and supports node hotplug.
So we try to enhance the DMAEngine to support IOAT hotplug.

On the other hand, Intel next generation processor Ivybridge has
embedded IOH, so we need to support IOH/IOAT hotplug when supporting
processor hotplug.

 >   if such an engine were built one day we still would not need to >notify
 >   clients of remove events.  The driver can simply return NULL to a
 >   ->prep() request, something that is much easier for a client to 
 >handle.
Could you please help to give more explanations about "The driver can
simply return NULL to a ->prep() request", I have gotten the idea yet.

>
> If you are going to hotplug the entire IOH, then you are probably ok
> with network links going down, so could you just down the links and
> remove the driver with the existing code?
I feel it's a little risky to shut down/restart all network interfaces
for hot-removal of IOH, that may disturb the applications. And there
are also other kinds of clients, such as ASYNC_TX, seems we can't
adopt this method to reclaim DMA channels from ASYNC_TX subsystem.

>
> --
> Dan
>
> [1]: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=c13c826
> [2]: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=6f49a57a
>
> .
>

^ permalink raw reply

* Re: [PATCH v2 4/5] don't take cgroup_mutex in destroy()
From: KAMEZAWA Hiroyuki @ 2012-04-24  2:31 UTC (permalink / raw)
  To: Glauber Costa
  Cc: Tejun Heo, netdev-u79uwXL29TY76Z2rM5mHXA,
	cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan, David Miller,
	devel-GEFAQzZX7r8dnm+yROfE0A, Vivek Goyal
In-Reply-To: <1335209867-1831-5-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>

(2012/04/24 4:37), Glauber Costa wrote:

> Most of the destroy functions are only doing very simple things
> like freeing memory.
> 
> The ones who goes through lists and such, already use its own
> locking for those.
> 
> * The cgroup itself won't go away until we free it, (after destroy)
> * The parent won't go away because we hold a reference count
> * There are no more tasks in the cgroup, and the cgroup is declared
>   dead (cgroup_is_removed() == true)
> 
> [v2: don't cgroup_lock the freezer and blkcg ]
> 
> Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> CC: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> CC: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> CC: Kamezawa Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> CC: Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>  kernel/cgroup.c |    9 ++++-----
>  1 files changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 932c318..976d332 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -869,13 +869,13 @@ static void cgroup_diput(struct dentry *dentry, struct inode *inode)
>  		 * agent */
>  		synchronize_rcu();
>  
> -		mutex_lock(&cgroup_mutex);
>  		/*
>  		 * Release the subsystem state objects.
>  		 */
>  		for_each_subsys(cgrp->root, ss)
>  			ss->destroy(cgrp);
>  
> +		mutex_lock(&cgroup_mutex);
>  		cgrp->root->number_of_cgroups--;
>  		mutex_unlock(&cgroup_mutex);
>  
> @@ -3994,13 +3994,12 @@ static long cgroup_create(struct cgroup *parent, struct dentry *dentry,
>  
>   err_destroy:
>  
> +	mutex_unlock(&cgroup_mutex);
>  	for_each_subsys(root, ss) {
>  		if (cgrp->subsys[ss->subsys_id])
>  			ss->destroy(cgrp);
>  	}
>  
> -	mutex_unlock(&cgroup_mutex);
> -
>  	/* Release the reference count that we took on the superblock */
>  	deactivate_super(sb);
>  
> @@ -4349,9 +4348,9 @@ int __init_or_module cgroup_load_subsys(struct cgroup_subsys *ss)
>  		int ret = cgroup_init_idr(ss, css);
>  		if (ret) {
>  			dummytop->subsys[ss->subsys_id] = NULL;
> +			mutex_unlock(&cgroup_mutex);
>  			ss->destroy(dummytop);
>  			subsys[i] = NULL;
> -			mutex_unlock(&cgroup_mutex);
>  			return ret;
>  		}
>  	}
> @@ -4447,10 +4446,10 @@ void cgroup_unload_subsys(struct cgroup_subsys *ss)
>  	 * pointer to find their state. note that this also takes care of
>  	 * freeing the css_id.
>  	 */
> +	mutex_unlock(&cgroup_mutex);
>  	ss->destroy(dummytop);
>  	dummytop->subsys[ss->subsys_id] = NULL;
>  

I'm not fully sure but...dummytop->subsys[] update can be done without locking ?

Thanks,
-Kame

^ permalink raw reply

* Re: [PATCH net-next 0/3] mlx4_en: Adding BQL support
From: David Miller @ 2012-04-24  2:34 UTC (permalink / raw)
  To: yevgenyp; +Cc: netdev
In-Reply-To: <4F954893.3040401@mellanox.co.il>

From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Mon, 23 Apr 2012 15:18:27 +0300

> This patchset adds Byte Queue Limit support to the mlx4_en driver.
> As a precondition to this I had to change the mode of TX completion handling
> Till now we have handled completions by polling from the xmit context,
> once in every 16 packets.
> Now moving to interrupts, and also added the set/get coalescing option for TX interrupts.

All applied to net-next, thanks.

^ 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