netdev - Re: IPoIB: Fix multicast packet drops before join is complete

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 10 Jun 2009 13:18:29 +0300
From:	Or Gerlitz <or.gerlitz@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	rdreier@...co.com, cl@...ux-foundation.org, netdev@...r.kernel.org,
	yosefe@...taire.com
Subject: Re: IPoIB: Fix multicast packet drops before join is complete

On Wed, Jun 10, 2009 at 8:12 AM, David Miller <davem@...emloft.net> wrote:
> From: Roland Dreier <rdreier@...co.com>

>> There isn't any corresponding code to block an app during ARP resolution, is there?

> Here the app can send a voluminous amount of application data at the destination and it'll
> mostly drop on the floor currently. ARP doesn't typically toss real application data, this does.

Dave,

If there's no app level flow control around, UDP senders will just send...  so
for --unicast--  the same problem of injecting tons of packets which can get
dropped will come into play under both Ethernet and IB, so the user is limited
by the socket buffer len and the neigh unres_qlen systcl.

Why not apply a similar systcl mechanism for the IB/mcast case so the ipoib
driver level (under the user directive) will have control on how many
packets would
be queued before starting to drop.

Or.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html