From: Jason Baron <jbaron@akamai•com>
To: "Mintz, Yuval" <Yuval.Mintz@cavium•com>,
"davem@davemloft•net" <davem@davemloft•net>
Cc: "netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"Ariel.Elior@qlogic•com" <Ariel.Elior@qlogic•com>
Subject: Re: [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments
Date: Tue, 20 Sep 2016 11:19:44 -0400 [thread overview]
Message-ID: <57E15390.9030306@akamai.com> (raw)
In-Reply-To: <BL2PR07MB2306ECB3DBAB53BFB9CF30EC8DF70@BL2PR07MB2306.namprd07.prod.outlook.com>
On 09/20/2016 11:00 AM, Mintz, Yuval wrote:
>>> The question I rose was whether it actually makes a difference under
>>> such circumstances whether the device would actually filter those
>>> multicast addresses or be completely multicast promiscuous.
>>> e.g., whether it's significant to be filtering out multicast ingress
>>> traffic when you're already allowing 1/2 of all random multicast
>>> packets to be classified for the interface.
>>>
>>
>> Agreed, I think this is the more interesting question here. I thought that we
>> would want to make sure we are using most of the bins before falling back to
>> multicast ingress. The reason being that even if its more expensive for the NIC to
>> do the filtering than the multicast mode, it would be more than made up for by
>> having to drop the traffic higher up the stack. So I think if we can determine the
>> percent of the bins that we want to use, we can then back into the average
>> number of filters required to get there. As I said, I thought we would want to
>> make sure we filled basically all the bins (with a high probability that is) before
>> falling back to multicast, and so I threw out 2,048.
>
> AFAIK configuring multiple filters doesn't incur any performance penalty
> from the adapter side.
> And I agree that from 'offloading' perspective it's probably better to
> filter in HW even if the gain is negligible.
> So for the upper limit - there's not much of a reason to it; The only gain
> would be to prevent driver from allocating lots-and-lots of memory
> temporarily for an unnecessary configuration.
>
Ok. We already have an upper limit to an extent with
/proc/sys/net/ipv4/igmp_max_memberships. And as posted I didn't include
one b/c of the higher level limits already in place.
Thanks,
-Jason
next prev parent reply other threads:[~2016-09-20 15:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-16 21:30 [PATCH net-next 0/2] bnx2x: page allocation failure Jason Baron
2016-09-16 21:30 ` [PATCH net-next 1/2] bnx2x: allocate mac filtering 'mcast_list' in PAGE_SIZE increments Jason Baron
2016-09-16 21:30 ` [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list " Jason Baron
2016-09-18 10:25 ` Mintz, Yuval
2016-09-19 18:33 ` Jason Baron
2016-09-20 7:41 ` Mintz, Yuval
2016-09-20 14:52 ` Jason Baron
2016-09-20 15:00 ` Mintz, Yuval
2016-09-20 15:19 ` Jason Baron [this message]
2016-09-20 11:30 ` David Laight
2016-09-20 18:46 ` Jason Baron
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=57E15390.9030306@akamai.com \
--to=jbaron@akamai$(echo .)com \
--cc=Ariel.Elior@qlogic$(echo .)com \
--cc=Yuval.Mintz@cavium$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox