From: Eric Dumazet <dada1@cosmosbay.com>
To: Dave Boutcher <daveboutcher@gmail.com>
Cc: netdev@vger.kernel.org, "Brandeburg,
Jesse" <jesse.brandeburg@intel.com>,
jeffrey.t.kirsher@intel.com, david.graham@intel.com
Subject: Re: IGMP Join dropping multicast packets
Date: Wed, 18 Mar 2009 08:38:14 +0100 [thread overview]
Message-ID: <49C0A4E6.7030703@cosmosbay.com> (raw)
In-Reply-To: <91bdcedb0903172050td2ef895he48168987ad94472@mail.gmail.com>
Dave Boutcher a écrit :
> On Mon, Mar 16, 2009 at 2:01 PM, Eric Dumazet <dada1@cosmosbay.com> wrote:
>> Dave Boutcher a écrit :
>>> On Sat, Mar 14, 2009 at 9:37 PM, Eric Dumazet <dada1@cosmosbay.com> wrote:
>>>> Dave Boutcher a écrit :
>>>>> I'm running into an interesting problem with joining multiple
>>>>> multicast feeds. If you join multiple multicast feeds using
>>>>> setsockopt(...,IP_ADD_MEMBERSHIP...) it causes packets on UNRELATED
>>>>> multicast feeds to get dropped. We have a multicast feed on a rock
>>>>> solid network, and we were very surprised to see dropped packets. The
>>>>> cause was a different process/program being run by a different user
>>>>> joining a bunch of mulitcast feeds.
>>>> I could not reproduce the problem on my machines (bnx2 adapter), even if changing
>>>> NUMSOCK from 55 to 200 in joiner.c
>>> Thanks for trying Eric. Based on your email I did some more testing
>>> and thus far I've
>>> only recreated this on x86_64 arches, not on i386. Which arch did you
>>> try it on?
>> I tried both, 32 and 64 bit kernels. No problems so far.
>>
>> Could you post a linux kernel .config of a non 'working' machine, and dmesg output ?
>
> Eric, based on your inability to recreate this, I tried on some other
> hardware I had lying around that has an AMD chipset built-in NIC.
> I could not recreate the problem on that hardware. I'm starting to
> think this is an e1000 problem. In both the e1000 and e1000e
> drivers they do the following logic:
>
> /* clear the old settings from the multicast hash table */
>
> for (i = 0; i < mta_reg_count; i++) {
> E1000_WRITE_REG_ARRAY(hw, MTA, i, 0);
> E1000_WRITE_FLUSH();
> }
>
> /* load any remaining addresses into the hash table */
>
> for (; mc_ptr; mc_ptr = mc_ptr->next) {
> hash_value = e1000_hash_mc_addr(hw, mc_ptr->da_addr);
> e1000_mta_set(hw, hash_value);
> }
>
> There's clearly a window where the NIC doesn't have the multicast
> addresses loaded. This may just be broken-as-designed. If anyone
> else happens to have some e1000 hardware and wants to see if you
> can recreate this, I'd be curious.
>
Ouch, you are probably right, this code needs a change.
tg3 for example has a loop bulding hash values in a local array,
then a write of this array on NIC.
for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count;
i++, mclist = mclist->next) {
crc = calc_crc (mclist->dmi_addr, ETH_ALEN);
bit = ~crc & 0x7f;
regidx = (bit & 0x60) >> 5;
bit &= 0x1f;
mc_filter[regidx] |= (1 << bit);
}
tw32(MAC_HASH_REG_0, mc_filter[0]);
tw32(MAC_HASH_REG_1, mc_filter[1]);
tw32(MAC_HASH_REG_2, mc_filter[2]);
tw32(MAC_HASH_REG_3, mc_filter[3]);
}
Other example , on bnx2, same logic :
memset(mc_filter, 0, 4 * NUM_MC_HASH_REGISTERS);
for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count;
i++, mclist = mclist->next) {
crc = ether_crc_le(ETH_ALEN, mclist->dmi_addr);
bit = crc & 0xff;
regidx = (bit & 0xe0) >> 5;
bit &= 0x1f;
mc_filter[regidx] |= (1 << bit);
}
for (i = 0; i < NUM_MC_HASH_REGISTERS; i++) {
REG_WR(bp, BNX2_EMAC_MULTICAST_HASH0 + (i * 4),
mc_filter[i]);
}
> Some other notes just FYI...
>
> - RcvbufErrors in /proc/net/snmp doesn't get incremented when this happens
> - there are no messages in dmesg
> - frames get dropped when the program calls exit() and all the sockets
> get closed
> (and multicast joins dropped) as well as when the ADD_MEMBERSHIPs happen
> - The problem happens even when adding a sleep(1) in between each of the
> ADD_MEMBERSHIP calls.
>
next prev parent reply other threads:[~2009-03-18 7:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-14 20:16 IGMP Join dropping multicast packets Dave Boutcher
2009-03-15 2:37 ` Eric Dumazet
2009-03-16 2:04 ` Dave Boutcher
2009-03-16 19:01 ` Eric Dumazet
2009-03-17 7:08 ` Eric Dumazet
2009-03-18 3:50 ` Dave Boutcher
2009-03-18 7:38 ` Eric Dumazet [this message]
2009-03-18 17:24 ` Brandeburg, Jesse
2009-03-19 1:48 ` Dave Boutcher
2009-03-19 1:51 ` Dave Boutcher
2009-03-20 20:36 ` Brandeburg, Jesse
2009-03-19 5:46 ` 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=49C0A4E6.7030703@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=daveboutcher@gmail.com \
--cc=david.graham@intel.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=netdev@vger.kernel.org \
/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.