Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] ipv4: Fix again the time difference calculation
From: David Miller @ 2012-07-19 20:01 UTC (permalink / raw)
  To: ja; +Cc: netdev
In-Reply-To: <1342728165-2046-1-git-send-email-ja@ssi.bg>

From: Julian Anastasov <ja@ssi.bg>
Date: Thu, 19 Jul 2012 23:02:45 +0300

> 	Fix again the diff value in rt_bind_exception
> after collision of two latest patches, my original commit
> actually fixed the same problem.
> 
> Signed-off-by: Julian Anastasov <ja@ssi.bg>

I noticed this too while respinning the routing cache deletion
patches, I'll apply this, thanks.

^ permalink raw reply

* [PATCH] ipv4: Fix again the time difference calculation
From: Julian Anastasov @ 2012-07-19 20:02 UTC (permalink / raw)
  To: David Miller; +Cc: netdev

	Fix again the diff value in rt_bind_exception
after collision of two latest patches, my original commit
actually fixed the same problem.

Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
 net/ipv4/route.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 89e39dc5..9f7ffbe 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1926,7 +1926,7 @@ restart:
 		if (daddr != fnhe_daddr)
 			continue;
 		if (pmtu) {
-			unsigned long diff = jiffies - expires;
+			unsigned long diff = expires - jiffies;
 
 			if (time_before(jiffies, expires)) {
 				rt->rt_pmtu = pmtu;
-- 
1.7.3.4

^ permalink raw reply related

* Re: [PATCH 01/15] ipv4: Delete routing cache.
From: David Miller @ 2012-07-19 19:25 UTC (permalink / raw)
  To: bhutchings; +Cc: netdev
In-Reply-To: <1342725619.2617.47.camel@bwh-desktop.uk.solarflarecom.com>

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 19 Jul 2012 20:20:19 +0100

> On Wed, 2012-07-18 at 11:22 -0700, David Miller wrote:
>> Signed-off-by: David S. Miller <davem@davemloft.net>
> [...]
> 
> I think this deserves a bit of explanation for the benefit of future git
> archaeologists.

I will add something about that to the text, thanks Ben.

^ permalink raw reply

* Re: [PATCH 01/15] ipv4: Delete routing cache.
From: Ben Hutchings @ 2012-07-19 19:20 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20120718.112251.1920518930510675574.davem@davemloft.net>

On Wed, 2012-07-18 at 11:22 -0700, David Miller wrote:
> Signed-off-by: David S. Miller <davem@davemloft.net>
[...]

I think this deserves a bit of explanation for the benefit of future git
archaeologists.

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

* [GIT] net has been merged into net-next
From: David Miller @ 2012-07-19 18:31 UTC (permalink / raw)
  To: netdev; +Cc: jeffrey.t.kirsher


Jeff, please double check my merge work on the ixgbevf driver, and send
me any necessary fixups.

Thanks!

^ permalink raw reply

* Re: [PATCH v3 0/7] TCP Fast Open client
From: Yuchung Cheng @ 2012-07-19 18:26 UTC (permalink / raw)
  To: David Miller; +Cc: hkchu, edumazet, ncardwell, sivasankar, netdev
In-Reply-To: <20120719.105616.2007996793203344140.davem@davemloft.net>

On Thu, Jul 19, 2012 at 10:56 AM, David Miller <davem@davemloft.net> wrote:
> From: Yuchung Cheng <ycheng@google.com>
> Date: Thu, 19 Jul 2012 09:43:04 -0700
>
>> ChangeLog since v2:
>>   - Added seqlock to update Fast Open metrics
>>   - Move TCP magic code in inet_wait_for_connect() to inet_stream_connect()
>>   - Move up MSG_FASTOPEN macro for better header formatting
>>
>> ChangeLog since v1:
>>   - Reduce tons of code by storing Fast Open stats in the TCP metrics :)
>>   - Clarify the purpose of using an experimental option in patch 1/7
>
> Ok I've applied this series and am doing build testing, if nothing
> falls out from that I'll push it out to net-next.
>
> Thanks a lot for doing this work.
And a big THANK YOU for taking this patch too. I hope it works. :)

^ permalink raw reply

* Re: [PATCH v3 3/7] net-tcp: Fast Open client - sending SYN-data
From: Eric Dumazet @ 2012-07-19 18:05 UTC (permalink / raw)
  To: David Miller; +Cc: ycheng, hkchu, edumazet, ncardwell, sivasankar, netdev
In-Reply-To: <20120719.105946.587126825843724015.davem@davemloft.net>

On Thu, 2012-07-19 at 10:59 -0700, David Miller wrote:

> >> Signed-off-by: Yuchung Cheng <ycheng@google.com>
>  ...
> > Eric Dumazet <edumazet@google.com>
> 
> I guess you're trying to ACK this? :-)

Oops yes ;)

Acked-by: Eric Dumazet <edumazet@google.com>

^ permalink raw reply

* Re: [PATCH v3 6/7] net-tcp: Fast Open client - detecting SYN-data drops
From: Eric Dumazet @ 2012-07-19 18:00 UTC (permalink / raw)
  To: Yuchung Cheng; +Cc: davem, hkchu, edumazet, ncardwell, sivasankar, netdev
In-Reply-To: <1342716191-19196-7-git-send-email-ycheng@google.com>

On Thu, 2012-07-19 at 09:43 -0700, Yuchung Cheng wrote:
> On paths with firewalls dropping SYN with data or experimental TCP options,
> Fast Open connections will have experience SYN timeout and bad performance.
> The solution is to track such incidents in the cookie cache and disables
> Fast Open temporarily.
> 
> Since only the original SYN includes data and/or Fast Open option, the
> SYN-ACK has some tell-tale sign (tcp_rcv_fastopen_synack()) to detect
> such drops. If a path has recurring Fast Open SYN drops, Fast Open is
> disabled for 2^(recurring_losses) minutes starting from four minutes up to
> roughly one and half day. sendmsg with MSG_FASTOPEN flag will succeed but
> it behaves as connect() then write().
> 
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> ---

Acked-by: Eric Dumazet <edumazet@google.com>

^ permalink raw reply

* Re: [PATCH v3 3/7] net-tcp: Fast Open client - sending SYN-data
From: David Miller @ 2012-07-19 17:59 UTC (permalink / raw)
  To: eric.dumazet; +Cc: ycheng, hkchu, edumazet, ncardwell, sivasankar, netdev
In-Reply-To: <1342720671.2626.4650.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 19 Jul 2012 19:57:51 +0200

> On Thu, 2012-07-19 at 09:43 -0700, Yuchung Cheng wrote:
>> This patch implements sending SYN-data in tcp_connect(). The data is
>> from tcp_sendmsg() with flag MSG_FASTOPEN (implemented in a later patch).
>> 
>> The length of the cookie in tcp_fastopen_req, init'd to 0, controls the
>> type of the SYN. If the cookie is not cached (len==0), the host sends
>> data-less SYN with Fast Open cookie request option to solicit a cookie
>> from the remote. If cookie is not available (len > 0), the host sends
>> a SYN-data with Fast Open cookie option. If cookie length is negative,
>>   the SYN will not include any Fast Open option (for fall back operations).
>> 
>> To deal with middleboxes that may drop SYN with data or experimental TCP
>> option, the SYN-data is only sent once. SYN retransmits do not include
>> data or Fast Open options. The connection will fall back to regular TCP
>> handshake.
>> 
>> Signed-off-by: Yuchung Cheng <ycheng@google.com>
 ...
> Eric Dumazet <edumazet@google.com>

I guess you're trying to ACK this? :-)

^ permalink raw reply

* Re: [PATCH v3 5/7] net-tcp: Fast Open client - sendmsg(MSG_FASTOPEN)
From: Eric Dumazet @ 2012-07-19 17:59 UTC (permalink / raw)
  To: Yuchung Cheng; +Cc: davem, hkchu, edumazet, ncardwell, sivasankar, netdev
In-Reply-To: <1342716191-19196-6-git-send-email-ycheng@google.com>

On Thu, 2012-07-19 at 09:43 -0700, Yuchung Cheng wrote:
> sendmsg() (or sendto()) with MSG_FASTOPEN is a combo of connect(2)
> and write(2). The application should replace connect() with it to
> send data in the opening SYN packet.
> 
> For blocking socket, sendmsg() blocks until all the data are buffered
> locally and the handshake is completed like connect() call. It
> returns similar errno like connect() if the TCP handshake fails.
> 
> For non-blocking socket, it returns the number of bytes queued (and
> transmitted in the SYN-data packet) if cookie is available. If cookie
> is not available, it transmits a data-less SYN packet with Fast Open
> cookie request option and returns -EINPROGRESS like connect().
> 
> Using MSG_FASTOPEN on connecting or connected socket will result in
> simlar errno like repeating connect() calls. Therefore the application
> should only use this flag on new sockets.
> 
> The buffer size of sendmsg() is independent of the MSS of the connection.
> 
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> ---

Acked-by: Eric Dumazet <edumazet@google.com>

^ permalink raw reply

* Re: [PATCH v3 3/7] net-tcp: Fast Open client - sending SYN-data
From: Eric Dumazet @ 2012-07-19 17:57 UTC (permalink / raw)
  To: Yuchung Cheng; +Cc: davem, hkchu, edumazet, ncardwell, sivasankar, netdev
In-Reply-To: <1342716191-19196-4-git-send-email-ycheng@google.com>

On Thu, 2012-07-19 at 09:43 -0700, Yuchung Cheng wrote:
> This patch implements sending SYN-data in tcp_connect(). The data is
> from tcp_sendmsg() with flag MSG_FASTOPEN (implemented in a later patch).
> 
> The length of the cookie in tcp_fastopen_req, init'd to 0, controls the
> type of the SYN. If the cookie is not cached (len==0), the host sends
> data-less SYN with Fast Open cookie request option to solicit a cookie
> from the remote. If cookie is not available (len > 0), the host sends
> a SYN-data with Fast Open cookie option. If cookie length is negative,
>   the SYN will not include any Fast Open option (for fall back operations).
> 
> To deal with middleboxes that may drop SYN with data or experimental TCP
> option, the SYN-data is only sent once. SYN retransmits do not include
> data or Fast Open options. The connection will fall back to regular TCP
> handshake.
> 
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> ---
>  include/linux/snmp.h  |    1 +
>  include/linux/tcp.h   |    6 ++-
>  include/net/tcp.h     |    9 ++++
>  net/ipv4/af_inet.c    |   10 +++-
>  net/ipv4/proc.c       |    1 +
>  net/ipv4/tcp_output.c |  115 +++++++++++++++++++++++++++++++++++++++++++++----
>  6 files changed, 130 insertions(+), 12 deletions(-)

Eric Dumazet <edumazet@google.com>

^ permalink raw reply

* Re: [PATCH] Crash in tun
From: Max Krasnyansky @ 2012-07-19 17:57 UTC (permalink / raw)
  To: David Miller; +Cc: mikulas, eric.dumazet, netdev
In-Reply-To: <20120719.104721.1649022907880598997.davem@davemloft.net>

On 07/19/2012 10:47 AM, David Miller wrote:
> From: Max Krasnyansky <maxk@qualcomm.com>
> Date: Thu, 19 Jul 2012 10:44:01 -0700
> 
>> btw I don't remember now who added the socket business to tun_struct and why.
> 
> Is GIT really so broken on your computer that you can't find the
> answer to this question in like 5 seconds as I just did?

No. I'm just too lazy these days. Too much surfing I guess :).

> commit 33dccbb050bbe35b88ca8cf1228dcf3e4d4b3554
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date:   Thu Feb 5 21:25:32 2009 -0800
> 
>     tun: Limit amount of queued packets per device
> <snip>     
>     This patch attempts to apply the same bandaid to the tuntap device.
>     It creates a pseudo-socket object which is used to account our
>     packets just as a normal socket does for UDP.  Of course things
>     are a little complex because we're actually reinjecting traffic
>     back into the stack rather than out of the stack.

Thanks for the info. Overall it definitely makes sense. Still feels a bit of an overkill.
i.e. That we need to allocated a socket just for accounting but I guess all the involved
skb primitives are heavily based on that. If there are other use cases like this maybe
it makes sense to factor accounting stuff out of the socket struct?

Max

^ permalink raw reply

* Re: [PATCH v3 0/7] TCP Fast Open client
From: David Miller @ 2012-07-19 17:56 UTC (permalink / raw)
  To: ycheng; +Cc: hkchu, edumazet, ncardwell, sivasankar, netdev
In-Reply-To: <1342716191-19196-1-git-send-email-ycheng@google.com>

From: Yuchung Cheng <ycheng@google.com>
Date: Thu, 19 Jul 2012 09:43:04 -0700

> ChangeLog since v2:
>   - Added seqlock to update Fast Open metrics
>   - Move TCP magic code in inet_wait_for_connect() to inet_stream_connect()
>   - Move up MSG_FASTOPEN macro for better header formatting
> 
> ChangeLog since v1:
>   - Reduce tons of code by storing Fast Open stats in the TCP metrics :)
>   - Clarify the purpose of using an experimental option in patch 1/7

Ok I've applied this series and am doing build testing, if nothing
falls out from that I'll push it out to net-next.

Thanks a lot for doing this work.

^ permalink raw reply

* Re: [PATCH] mlx4_en: map entire pages to increase throughput
From: David Miller @ 2012-07-19 17:53 UTC (permalink / raw)
  To: cascardo; +Cc: netdev, yevgenyp, ogerlitz, amirv, brking, leitao, klebers
In-Reply-To: <1342458113-10384-1-git-send-email-cascardo@linux.vnet.ibm.com>

From: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Date: Mon, 16 Jul 2012 14:01:53 -0300

> In its receive path, mlx4_en driver maps each page chunk that it pushes
> to the hardware and unmaps it when pushing it up the stack. This limits
> throughput to about 3Gbps on a Power7 8-core machine.
> 
> One solution is to map the entire allocated page at once. However, this
> requires that we keep track of every page fragment we give to a
> descriptor. We also need to work with the discipline that all fragments will
> be released (in the sense that it will not be reused by the driver
> anymore) in the order they are allocated to the driver.
> 
> This requires that we don't reuse any fragments, every single one of
> them must be reallocated. We do that by releasing all the fragments that
> are processed and only after finished processing the descriptors, we
> start the refill.
> 
> We also must somehow guarantee that we either refill all fragments in a
> descriptor or none at all, without resorting to giving up a page
> fragment that we would have already given. Otherwise, we would break the
> discipline of only releasing the fragments in the order they were
> allocated.
> 
> This has passed page allocation fault injections (restricted to the
> driver by using required-start and required-end) and device hotplug
> while 16 TCP streams were able to deliver more than 9Gbps.
> 
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>

I have not seen any reasonable objections to this patch, so I have
applied it to net-next, thanks!

^ permalink raw reply

* Re: [PATCH net-next v2] ipv4: tcp: remove per net tcp_sock
From: David Miller @ 2012-07-19 17:51 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev, therbert, wsommerfeld
In-Reply-To: <1342720197.2626.4624.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 19 Jul 2012 19:49:57 +0200

> On Thu, 2012-07-19 at 10:36 -0700, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Thu, 19 Jul 2012 19:34:03 +0200
>> 
>> > v2 : move unicast_sock out of ip_send_unicast_reply() body
>> >      init sk_refcnt to 1, in case some driver get/put a reference on
>> >      socket.
>> 
>> The compiler seems much happier with this, applied, thanks Eric :-)
> 
> Maybe I should install your compiler ;) What is the version you
> currently use ?

On x86-64 I use:

[davem@dokdo net-next]$ gcc --version
gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

and on sparc64 I use gcc-4.7.1 vanilla.

^ permalink raw reply

* Re: [PATCH] sfc: initialize dynamic sysfs attributes for lockdep
From: David Miller @ 2012-07-19 17:51 UTC (permalink / raw)
  To: bhutchings; +Cc: mschmidt, netdev, linux-net-drivers
In-Reply-To: <1342718345.2617.46.camel@bwh-desktop.uk.solarflarecom.com>

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 19 Jul 2012 18:19:05 +0100

> On Thu, 2012-07-19 at 19:04 +0200, Michal Schmidt wrote:
>> Dynamically allocated sysfs attributes must be initialized using
>> sysfs_attr_init(), otherwise lockdep complains:
>> BUG: key <address> not in .data!
>>
>> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
> 
> Acked-by: Ben Hutchings <bhutchings@solarflare.com>

Applied.

^ permalink raw reply

* Re: [PATCH] bridge: update documentation references
From: David Miller @ 2012-07-19 17:50 UTC (permalink / raw)
  To: shemminger; +Cc: netdev
In-Reply-To: <20120719100107.088e5bec@s6510.linuxnetplumber.net>

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 19 Jul 2012 10:01:07 -0700

> Update the references to bridge utilities and web pages
> to current locations
> 
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

Applied.

^ permalink raw reply

* Re: [PATCH v2] net: e100: ucode is optional in some cases
From: David Miller @ 2012-07-19 17:50 UTC (permalink / raw)
  To: bjorn
  Cc: netdev, jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
	carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
	peter.p.waskiewicz.jr, alexander.h.duyck, john.ronciak,
	e1000-devel
In-Reply-To: <1342715320-990-1-git-send-email-bjorn@mork.no>

From: Bjørn Mork <bjorn@mork.no>
Date: Thu, 19 Jul 2012 18:28:40 +0200

>   commit 9ac32e1b firmware: convert e100 driver to request_firmware()
> 
> did a straight conversion of the in-driver ucode to external
> files.  This introduced the possibility of the driver failing
> to enable an interface due to missing ucode. There was no
> evaluation of the importance of the ucode at the time.
> 
> Based on comments in earlier versions of this driver, and in
> the source code for the FreeBSD fxp driver, we can assume that
> the ucode implements the "CPU Cycle Saver" feature on supported
> adapters.  Although generally wanted, this is an optional
> feature. The ucode source is not available, preventing it from
> being included in free distributions. This creates unnecessary
> problems for the end users. Doing a network install based on a
> free distribution installer requires the user to download and
> insert the ucode into the installer.
> 
> Making the ucode optional when possible improves the user
> experience and driver usability.
> 
> The ucode for some adapters include a bugfix, making it
> essential.  We continue to fail for these adapters unless the
> ucode is available.
> 
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
> ---
> v2: removed URLs from the patch, converting them to generic
>     descriptions of the sources of information

Applied.

^ permalink raw reply

* Re: [PATCH net-next] asix: AX88172A driver depends on phylib
From: David Miller @ 2012-07-19 17:50 UTC (permalink / raw)
  To: christian.riesch; +Cc: netdev, fengguang.wu, kernel-janitors
In-Reply-To: <1342699339-13871-1-git-send-email-christian.riesch@omicron.at>

From: Christian Riesch <christian.riesch@omicron.at>
Date: Thu, 19 Jul 2012 14:02:19 +0200

> Since commit 16626b0cc3d5afe250850f96759b241f8a403b52 the asix
> driver depends on the phylib. Select phylib when the asix driver is
> selected.
> 
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Cc: kernel-janitors@vger.kernel.org
> Signed-off-by: Christian Riesch <christian.riesch@omicron.at>

Applied.

^ permalink raw reply

* Re: [PATCH net-next 2/2] asix: Add support for programming the EEPROM
From: David Miller @ 2012-07-19 17:50 UTC (permalink / raw)
  To: christian.riesch; +Cc: netdev, allan, kernel, grundler
In-Reply-To: <1342693387-17945-2-git-send-email-christian.riesch@omicron.at>

From: Christian Riesch <christian.riesch@omicron.at>
Date: Thu, 19 Jul 2012 12:23:07 +0200

> This patch adds the asix_set_eeprom() function to provide support for
> programming the configuration EEPROM via ethtool.
> 
> Signed-off-by: Christian Riesch <christian.riesch@omicron.at>

Applied.

^ permalink raw reply

* Re: [PATCH net-next 1/2] asix: Rework reading from EEPROM
From: David Miller @ 2012-07-19 17:50 UTC (permalink / raw)
  To: christian.riesch; +Cc: netdev, allan, kernel, grundler
In-Reply-To: <1342693387-17945-1-git-send-email-christian.riesch@omicron.at>

From: Christian Riesch <christian.riesch@omicron.at>
Date: Thu, 19 Jul 2012 12:23:06 +0200

> The current code for reading the EEPROM via ethtool in the asix
> driver has a few issues. It cannot handle odd length values
> (accesses must be aligned at 16 bit boundaries) and interprets the
> offset provided by ethtool as 16 bit word offset instead as byte offset.
> 
> The new code for asix_get_eeprom() introduced by this patch is
> modeled after the code in
> drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c
> and provides read access to the entire EEPROM with arbitrary
> offsets and lengths.
> 
> Signed-off-by: Christian Riesch <christian.riesch@omicron.at>

Applied.

^ permalink raw reply

* Re: [PATCHv1] net: stmmac: Add ip version to dts bindings
From: David Miller @ 2012-07-19 17:50 UTC (permalink / raw)
  To: sr
  Cc: dinguyen, netdev, dinh.linux, peppe.cavallaro, shiraz.hashim,
	deepak.sikri, pavel, arnd
In-Reply-To: <201207190925.58789.sr@denx.de>

From: Stefan Roese <sr@denx.de>
Date: Thu, 19 Jul 2012 09:25:58 +0200

> On Thursday 19 July 2012 01:28:26 dinguyen@altera.com wrote:
>> From: Dinh Nguyen <dinguyen@altera.com>
>> 
>> Because there are multiple variants to the stmmac/dwmac driver, the
>> dts bindings should be updated to include version of the IP used.
>> 
>> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> 
> Acked-by: Stefan Roese <sr@denx.de>

Applied.

^ permalink raw reply

* Re: [PATCH] cxgb3: Set vlan_feature on net_device
From: David Miller @ 2012-07-19 17:50 UTC (permalink / raw)
  To: brenohl; +Cc: divy, netdev
In-Reply-To: <1342639748-16276-1-git-send-email-brenohl@br.ibm.com>

From: brenohl@br.ibm.com
Date: Wed, 18 Jul 2012 14:29:08 -0500

> cxgb3 interface has a bad performance when VLAN is set. On my current
> setup, a PowerLinux 7R2, I am able to get around 7 Gbps on a TCP_STREAM
> (8 instances, 4k message).
> With this patch, I am able to reach 9.5 Gbps.
> 
> Signed-off-by: Breno Leitao <brenohl@br.ibm.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next v2] ipv4: tcp: remove per net tcp_sock
From: Eric Dumazet @ 2012-07-19 17:49 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, therbert, wsommerfeld
In-Reply-To: <20120719.103618.2037668049773125073.davem@davemloft.net>

On Thu, 2012-07-19 at 10:36 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 19 Jul 2012 19:34:03 +0200
> 
> > v2 : move unicast_sock out of ip_send_unicast_reply() body
> >      init sk_refcnt to 1, in case some driver get/put a reference on
> >      socket.
> 
> The compiler seems much happier with this, applied, thanks Eric :-)

Maybe I should install your compiler ;) What is the version you
currently use ?

^ permalink raw reply

* Re: [PATCH net-next] ipx: move peII functions
From: David Miller @ 2012-07-19 17:49 UTC (permalink / raw)
  To: shemminger; +Cc: acme, netdev
In-Reply-To: <20120718120948.67611bdd@s6510.linuxnetplumber.net>

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 18 Jul 2012 12:09:48 -0700

> The Ethernet II wrapper is only used by IPX protocol, may have once
> been used by Appletalk but not currently. Therefore it makes sense to 
> move it to the IPX dust bin and drop the exports.
> 
> Build tested only.
> 
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

Applied.

^ 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