netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Baron <jbaron@akamai.com>
To: David Laight <David.Laight@ACULAB.COM>,
	"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 14:46:28 -0400	[thread overview]
Message-ID: <57E18404.1010409@akamai.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB01046DB@AcuExch.aculab.com>



On 09/20/2016 07:30 AM, David Laight wrote:
> From: Jason Baron
>> Sent: 19 September 2016 19:34
> ...
>>
>> sizeof(struct bnx2x_mcast_list_elem) = 24. So there are 170 per
>> page on x86. So if we want to fit 2,048 elements, we need 12 pages.
>
> If you only need to save the mcast addresses you could use a 'heap'
> that requires no overhead per entry and gives you O(log) lookup.
> 6 bytes per entry is 682 in a 4k page.
>
> 	David
>

Indeed, that would save space here.

Based on Yuval's comments it sounds as though he agrees that it makes 
sense to go beyond a page (even if we get 682 per page as you suggest), 
when configuring these mac filters. So we would then have to allocate 
and manage the page pointers. Currently, there is a list_head per entry 
to manage the macs as a linked list. The patch I proposed continues to 
use that same data structure, thus it will not add to the memory 
footprint, it only proposes to break that footprint up into PAGE_SIZE 
chunks.

So I think the change you suggest can be viewed as an additional 
enhancement here, and also note that the memory allocations here are 
short-lived. That is, they only exist in memory until the NIC is 
re-configured.

Thanks,

-Jason

      reply	other threads:[~2016-09-20 18:46 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
2016-09-20 11:30       ` David Laight
2016-09-20 18:46         ` Jason Baron [this message]

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=57E18404.1010409@akamai.com \
    --to=jbaron@akamai.com \
    --cc=Ariel.Elior@qlogic.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=Yuval.Mintz@cavium.com \
    --cc=davem@davemloft.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).