[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4B1428FF.9010100@intel.com>
Date: Mon, 30 Nov 2009 12:20:15 -0800
From: John Fastabend <john.r.fastabend@...el.com>
To: Eric Dumazet <eric.dumazet@...il.com>
CC: David Miller <davem@...emloft.net>,
"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
"robert@...julf.net" <robert@...julf.net>,
"hawk@...u.dk" <hawk@...u.dk>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: ixgbe question
Eric Dumazet wrote:
> David Miller a écrit :
>
>> From: John Fastabend <john.r.fastabend@...el.com>
>> Date: Tue, 24 Nov 2009 13:14:12 +0000
>>
>>
>>> Believe the below patch will break DCB and FCoE though, both features
>>> have the potential to set real_num_tx_queues to greater then the
>>> number of CPUs. This could result in real_num_tx_queues >
>>> num_tx_queues.
>>>
>>> The current solution isn't that great though, maybe we should set to
>>> the minimum of MAX_TX_QUEUES and num_possible_cpus() * 2 + 8.
>>>
>>> That should cover the maximum possible queues for DCB, FCoE and their
>>> combinations.
>>>
>>> general multiq = num_possible_cpus()
>>> DCB = 8 tx queue's
>>> FCoE = 2*num_possible_cpus()
>>> FCoE + DCB = 8 tx queues + num_possible_cpus
>>>
>> Eric, I'm tossing your patch because of this problem, just FYI.
>>
>
> Sure, I guess we need a more generic way to handle this.
>
>
Eric,
I'll resubmit your patch with a small update to fix my concerns soon.
thanks,
john.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists