lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <4B8B7270.4080105@intel.com> Date: Sun, 28 Feb 2010 23:53:20 -0800 From: John Fastabend <john.r.fastabend@...el.com> To: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com> CC: Eric Dumazet <eric.dumazet@...il.com>, "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>, "davem@...emloft.net" <davem@...emloft.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "gospo@...hat.com" <gospo@...hat.com> Subject: Re: [net-next-2.6 PATCH 3/3] ixgbe: Do not allocate too many netdev txqueues Waskiewicz Jr, Peter P wrote: > On Sat, 2010-02-27 at 20:57 -0700, Eric Dumazet wrote: > >> Le samedi 27 février 2010 à 17:02 -0800, Peter P Waskiewicz Jr a écrit : >> >>> On Fri, 2010-02-26 at 06:04 -0800, Eric Dumazet wrote: >>> >>>> Le vendredi 26 février 2010 à 01:15 -0800, Jeff Kirsher a écrit : >>>> >>>>> + if (ii->mac == ixgbe_mac_82598EB) >>>>> + indices = min_t(unsigned int, indices, IXGBE_MAX_RSS_INDICES); >>>>> + else >>>>> + indices = min_t(unsigned int, indices, IXGBE_MAX_FDIR_INDICES); >>>>> + >>>>> + indices = max_t(unsigned int, indices, IXGBE_MAX_DCB_INDICES); >>>>> +#ifdef IXGBE_FCOE >>>>> + indices += min_t(unsigned int, num_possible_cpus(), >>>>> + IXGBE_MAX_FCOE_INDICES); >>>>> +#endif >>>>> + indices = min_t(unsigned int, indices, MAX_TX_QUEUES); >>>>> + netdev = alloc_etherdev_mq(sizeof(struct ixgbe_adapter), indices); >>>>> if (!netdev) { >>>>> err = -ENOMEM; >>>>> goto err_alloc_etherdev; >>>>> >>>>> >>>> Thanks Jeff, but what is the reason for limiting to MAX_TX_QUEUES ? >>>> Is it a hardware issue ? >>>> >>>> >>> MAX_TX_QUEUES is 128, which is the maximum the 82599 device supports in >>> hardware (82598 supports 32 Tx queues). I'm not sure why you'd ever >>> want to have more Tx queues than what you have in the network device. >>> >> I was not sure MAX_TX_QUEUES capping was still necessary after the >> block : >> >> if (ii->mac == ixgbe_mac_82598EB) >> indices = min_t(unsigned int, indices, IXGBE_MAX_RSS_INDICES); >> else >> indices = min_t(unsigned int, indices, >> IXGBE_MAX_FDIR_INDICES); >> >> indices = max_t(unsigned int, indices, IXGBE_MAX_DCB_INDICES); >> #ifdef IXGBE_FCOE >> indices += min_t(unsigned int, num_possible_cpus(), >> IXGBE_MAX_FCOE_INDICES); >> #endif >> >> So I asked to be sure that MAX_TX_QUEUES was not a leftover from the >> previous default allocation. >> >> Thanks >> > > I see what you're getting at now. The most we could have from this > codepath is 72 indices for 82599, and 24 for 82598, so yeah, this is > probably unneeded. > > We can get the patch cleaned up. > > Cheers, > -PJ > > Thanks for catching this. I'll submit another patch to clean this up. Additionally, we can probably remove MAX_TX_QUEUES all together and use the above values instead. No reason to have a tx_ring array larger then we are ever going to use. 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