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]

Message-Id: <20090610.050122.261415364.davem@davemloft.net>
Date:	Wed, 10 Jun 2009 05:01:22 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	or.gerlitz@...il.com
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

From: Or Gerlitz <or.gerlitz@...il.com>
Date: Wed, 10 Jun 2009 13:18:29 +0300

> 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.

But this generally does not cause problems via ARP, why might that
be?  Because resolution is 1) rare 2) quick.  Both of which do not
apply to this IPoIB case.

> 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.

Sure, but that's just pushing the problem around instead of
solving it.
--
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