[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090611.045721.05821546.davem@davemloft.net>
Date: Thu, 11 Jun 2009 04:57:21 -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: Thu, 11 Jun 2009 14:45:28 +0300
> On Wed, Jun 10, 2009 at 3:01 PM, David Miller<davem@...emloft.net> wrote:
>> From: Or Gerlitz <or.gerlitz@...il.com>
>
>>> for --unicast-- the same problem [...] 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.
>
> To be precise, I don't see why ARP resolution is more rare then
> joining to a multicast group on behalf of a sender in IPoIB, they
> both happen on the first and if/when the kernel deletes the
> neighbour.
There are two issues:
1) Ethernet does not have to "resolve" anything for multicast sends.
Therefore this issue is IPoIB specific.
2) ARP's tend to resolve on the DNS request for the site, or the
initial connection attempt. Both of which are single packets,
easily retransmitted, and the dropping of which does not result in
losing significant application data. The multicast case over IPoIB
does drop tons of actual application data.
--
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
Powered by blists - more mailing lists