All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Thomas Graf <tgraf@suug.ch>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>,
	Fabio Estevam <festevam@gmail.com>
Subject: Re: [PATCH v2] ipv6: Don't depend on per socket memory for neighbour discovery messages
Date: Tue, 03 Sep 2013 11:19:14 -0600	[thread overview]
Message-ID: <52261A12.3060203@wwwdotorg.org> (raw)
In-Reply-To: <e4600dac657e1160da7a5e7758dcb973b616a10e.1378207925.git.tgraf@suug.ch>

On 09/03/2013 05:37 AM, Thomas Graf wrote:
> Allocating skbs when sending out neighbour discovery messages
> currently uses sock_alloc_send_skb() based on a per net namespace
> socket and thus share a socket wmem buffer space.
> 
> If a netdevice is temporarily unable to transmit due to carrier
> loss or for other reasons, the queued up ndisc messages will cosnume
> all of the wmem space and will thus prevent from any more skbs to
> be allocated even for netdevices that are able to transmit packets.
> 
> The number of neighbour discovery messages sent is very limited,
> use of alloc_skb() bypasses the socket wmem buffer size enforcement
> while the manual call to skb_set_owner_w() maintains the socket
> reference needed for the IPv6 output path.
> 
> This patch has orginally been posted by Eric Dumazet in a modified
> form.

Tested-by: Stephen Warren <swarren@nvidia.com>

Although I do note something slightly odd:

next-20130830 had an issue, and reverting V1 of this patch solved it.

However, in next-20130903, if I revert the revert of V1 of this patch, I
don't see any issue; it appears that the problem was some interaction
between V1 of this patch and something else in next-20130830.

Either way, this patch doesn't seem to introduce any issue when applied
on top of either next-20130830 with V1 reverted, or on top of
next-20130903, so it's fine.

  parent reply	other threads:[~2013-09-03 17:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-03 11:37 [PATCH v2] ipv6: Don't depend on per socket memory for neighbour discovery messages Thomas Graf
2013-09-03 11:56 ` Hannes Frederic Sowa
2013-09-03 12:11   ` Thomas Graf
2013-09-03 12:18 ` Fabio Estevam
2013-09-03 17:19 ` Stephen Warren [this message]
2013-09-03 17:27   ` Hannes Frederic Sowa
2013-09-03 17:42     ` Stephen Warren
2013-09-03 17:51       ` Eric Dumazet
2013-09-03 18:03         ` Stephen Warren
2013-09-03 18:23           ` Thomas Graf
2013-09-03 18:30             ` Hannes Frederic Sowa
2013-09-03 22:43             ` Hannes Frederic Sowa
2013-09-04 18:41 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52261A12.3060203@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=festevam@gmail.com \
    --cc=hannes@stressinduktion.org \
    --cc=netdev@vger.kernel.org \
    --cc=tgraf@suug.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.