From: John Fastabend <john.r.fastabend@intel.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>,
David Miller <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-net-drivers@solarflare.com"
<linux-net-drivers@solarflare.com>,
Tom Herbert <therbert@google.com>
Subject: Re: [PATCH net-next-2.6] rps: allocate rx queues in register_netdevice only
Date: Fri, 24 Sep 2010 09:54:14 -0700 [thread overview]
Message-ID: <4C9CD7B6.1070201@intel.com> (raw)
In-Reply-To: <1285320110.2503.42.camel@edumazet-laptop>
On 9/24/2010 2:21 AM, Eric Dumazet wrote:
> Le vendredi 24 septembre 2010 à 01:15 -0700, John Fastabend a écrit :
>> On 9/23/2010 8:26 PM, Eric Dumazet wrote:
>>>
>>>> Also, I dont understand why we need to restrict
>>>> netif_set_real_num_rx_queues() to lower the count.
>>>> This wastes memory.
>>>>
>>>> Why dont we allocate dev->_rx once we know the real count, not in
>>>> alloc_netdev_mq() but in register_netdevice() ?
>>>>
>>
>> Eric,
>>
>> At least in the TX case we may not "know" until later how many
>> tx_queues we want to use. For example it could change based on
>> enabling/disabling features or available interrupts. So we use
>> num_tx_queues as the max we ever expect to use and then
>> netif_set_real_num_tx_queues() sets the number we want to use.
>>
>> I presume for rx queues there are similar cases where features and
>> available interrupts may determine how many rx queues are needed.
>>
>> Moving the allocation later could help drivers make better max number
>> of queue decisions. But, I think we still need the
>> netif_set_num_rx_queues() and netif_set_num_tx_queues(). Although this
>> does end up wasting memory as you pointed out.
>>
>
> Note I am not against having netif_set_num_rx_queues() and
> netif_set_num_tx_queues(). My patch was a cleanup, not an alternative.
>
>
> If I take a look at sysfs stuff, on a machine with a bnx2 adapter,
> single queue, I get :
>
> /sys/class/net/eth0/queues/rx-0/rps_cpus
> /sys/class/net/eth0/queues/rx-0/rps_flow_cnt
> /sys/class/net/eth0/queues/rx-1/rps_cpus
> /sys/class/net/eth0/queues/rx-1/rps_flow_cnt
> /sys/class/net/eth0/queues/rx-2/rps_cpus
> /sys/class/net/eth0/queues/rx-2/rps_flow_cnt
> /sys/class/net/eth0/queues/rx-3/rps_cpus
> /sys/class/net/eth0/queues/rx-3/rps_flow_cnt
> /sys/class/net/eth0/queues/rx-4/rps_cpus
> /sys/class/net/eth0/queues/rx-4/rps_flow_cnt
> /sys/class/net/eth0/queues/rx-5/rps_cpus
> /sys/class/net/eth0/queues/rx-5/rps_flow_cnt
> /sys/class/net/eth0/queues/rx-6/rps_cpus
> /sys/class/net/eth0/queues/rx-6/rps_flow_cnt
> /sys/class/net/eth0/queues/rx-7/rps_cpus
> /sys/class/net/eth0/queues/rx-7/rps_flow_cnt
>
> Thats a lot of extra memory and administrator confusion.
>
> We all agree :)
>
>
Thanks for the clarification Eric.
next prev parent reply other threads:[~2010-09-24 16:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-23 20:18 [PATCH net-next-2.6 0/2] net, sfc: Fix number of RX queues Ben Hutchings
2010-09-23 20:19 ` [PATCH net-next-2.6 1/2] net: Allow changing number of RX queues after device allocation Ben Hutchings
2010-09-24 2:48 ` Eric Dumazet
2010-09-24 3:26 ` [PATCH net-next-2.6] rps: allocate rx queues in register_netdevice only Eric Dumazet
2010-09-24 7:07 ` Eric Dumazet
2010-09-24 15:58 ` Tom Herbert
2010-09-24 8:15 ` John Fastabend
2010-09-24 9:21 ` Eric Dumazet
2010-09-24 16:54 ` John Fastabend [this message]
2010-09-27 2:05 ` David Miller
2010-09-24 12:24 ` [PATCH net-next-2.6 1/2] net: Allow changing number of RX queues after device allocation Ben Hutchings
2010-09-24 15:34 ` Tom Herbert
2010-09-23 20:20 ` [PATCH net-next-2.6 2/2] sfc: Use proper functions to set core RX and TX queue counts Ben Hutchings
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=4C9CD7B6.1070201@intel.com \
--to=john.r.fastabend@intel.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=linux-net-drivers@solarflare.com \
--cc=netdev@vger.kernel.org \
--cc=therbert@google.com \
/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.