Re: [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments

2016-09-20 Thread Jason Baron
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

Re: [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments

2016-09-20 Thread Jason Baron
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

RE: [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments

2016-09-20 Thread Mintz, Yuval
> > 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

Re: [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments

2016-09-20 Thread Jason Baron
On 09/20/2016 03:41 AM, Mintz, Yuval wrote: Currently, we can have high order page allocations that specify GFP_ATOMIC when configuring multicast MAC address filters. For example, we have seen order 2 page allocation failures with ~500 multicast addresses configured. Convert the allocation

RE: [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments

2016-09-20 Thread David Laight
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

RE: [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments

2016-09-20 Thread Mintz, Yuval
> >> Currently, we can have high order page allocations that specify > >> GFP_ATOMIC when configuring multicast MAC address filters. > >> > >> For example, we have seen order 2 page allocation failures with > >> ~500 multicast addresses configured. > >> > >> Convert the allocation for the pending

Re: [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments

2016-09-19 Thread Jason Baron
On 09/18/2016 06:25 AM, Mintz, Yuval wrote: Currently, we can have high order page allocations that specify GFP_ATOMIC when configuring multicast MAC address filters. For example, we have seen order 2 page allocation failures with ~500 multicast addresses configured. Convert the allocation for

RE: [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments

2016-09-18 Thread Mintz, Yuval
> Currently, we can have high order page allocations that specify > GFP_ATOMIC when configuring multicast MAC address filters. > > For example, we have seen order 2 page allocation failures with > ~500 multicast addresses configured. > > Convert the allocation for the pending list to be done in

[PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments

2016-09-16 Thread Jason Baron
Currently, we can have high order page allocations that specify GFP_ATOMIC when configuring multicast MAC address filters. For example, we have seen order 2 page allocation failures with ~500 multicast addresses configured. Convert the allocation for the pending list to be done in PAGE_SIZE