netdev - Re: [RFC net-next 05/14] Fix intel/ixgbevf

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120619110704.000045b2@unknown>
Date:	Tue, 19 Jun 2012 11:07:04 -0700
From:	Greg Rose <gregory.v.rose@...el.com>
To:	<eilong@...adcom.com>
CC:	Alexander Duyck <alexander.h.duyck@...el.com>,
	Yuval Mintz <yuvalmin@...adcom.com>, <netdev@...r.kernel.org>,
	<davem@...emloft.net>, Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Subject: Re: [RFC net-next 05/14] Fix intel/ixgbevf

On Tue, 19 Jun 2012 19:06:53 +0300
Eilon Greenstein <eilong@...adcom.com> wrote:

> On Tue, 2012-06-19 at 08:39 -0700, Alexander Duyck wrote:
> > On 06/19/2012 08:13 AM, Yuval Mintz wrote:
> > > Signed-off-by: Yuval Mintz <yuvalmin@...adcom.com>
> > > Signed-off-by: Eilon Greenstein <eilong@...adcom.com>
> > >
> > > Cc: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
> > > ---
> > >  drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |    5 +++--
> > >  1 files changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > > b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c index
> > > f69ec42..3ad46c2 100644 ---
> > > a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +++
> > > b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c @@ -2014,7
> > > +2014,7 @@ err_tx_ring_allocation: static int
> > > ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)
> > > { int err = 0;
> > > -	int vector, v_budget;
> > > +	int vector, v_budget, ncpu;
> > >  
> > >  	/*
> > >  	 * It's easy to be greedy for MSI-X vectors, but it
> > > really @@ -2022,8 +2022,9 @@ static int
> > > ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)
> > >  	 * than CPU's.  So let's be conservative and only ask for
> > >  	 * (roughly) twice the number of vectors as there are
> > > CPU's. */
> > > +	ncpu = min_t(int, num_online_cpus(),
> > > DEFAULT_MAX_NUM_RSS_QUEUES); v_budget =
> > > min(adapter->num_rx_queues + adapter->num_tx_queues,
> > > -		       (int)(num_online_cpus() * 2)) +
> > > NON_Q_VECTORS;
> > > +		       ncpu * 2) + NON_Q_VECTORS;
> > >  
> > >  	/* A failure in MSI-X entry allocation isn't fatal, but
> > > it does
> > >  	 * mean we disable MSI-X capabilities of the adapter. */
> > This change is pointless on the ixgbevf driver.  The VF hardware can
> > support at most 4 RSS queues.  As such num_rx_queues + num_tx_queues
> > will never exceed 8 so you are essentially adding a necessary
> > min(x,8).
> 
> It is pointless with the current value, but if someone will edit the
> kernel source code and replace the 8 with a 2, it will become
> meaningful. The compiler will optimize this part, and I think that for
> completion, it is best to keep this reference so a future default
> number change will not be missed.
> 
> Eilon

I don't feel there is any real point to making this change to the
ixgbevf driver.  82599 virtual functions have 3 MSI-X vectors, one of
which is for the mailbox and the other two can be shared with tx/rx
queue pairs or assigned separately to tx or rx queues.  So this code is
pointless no matter what value is set for DEFAULT_MAX_NUM_RSS_QUEUES.
Perhaps the patches to the other drivers in your RFC will have some
effect but this one looks like a no-op for the ixgbevf driver so there
is no reason for it.

- Greg

> 
> 
> --
> 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

--
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