netdev - Re: ixgbe select_queue broken in 2.6.28

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] [day] [month] [year] [list]

Message-ID: <Pine.WNT.4.64.0901060909280.6204@ppwaskie-MOBL2.amr.corp.intel.com>
Date:	Tue, 6 Jan 2009 10:40:38 -0800 (Pacific Standard Time)
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
cc:	"davem@...emloft.net" <davem@...emloft.net>,
	"shemminger@...tta.com" <shemminger@...tta.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"Skidmore, Donald C" <donald.c.skidmore@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: ixgbe select_queue broken in 2.6.28

On Tue, 6 Jan 2009, Herbert Xu wrote:

> Waskiewicz Jr, Peter P <peter.p.waskiewicz.jr@...el.com> wrote:
> > 
> > I understand why you want to remove this, but at the same time it is 
> > something that is useful if we don't abuse it.  I know for a fact this 
> > function pointer is very useful for routing performance setups, where 
> > binding a Tx queue to the CPU is very useful.  Jesse actually did the work 
> > on testing and getting good results with this.
> 
> Sure.  But that is not driver-specific.  The only reason to do
> an override is if the hash needs to be driver-specific.  So far
> the only reasons that have been given are deficiencies in the
> current hash, rather than a genuine need by the driver.

I agree with your statement 100%.  I do have a genuine need though, now 
that I understand why the select_queue was being overridden for DCB.  When 
ixgbe is running in DCB mode, traffic will be filtered into the traffic 
classes (i.e. Tx queues) via tc filters.  Since each queue has a specific 
priority in the hardware queueing, it's important that traffic isn't 
distributed across queues without specifically being filtered there.  The 
best way to address this is to have select_queue return Tx queue 0, which 
is the lowest priority queue for DCB.  Then if we exit DCB mode, we return 
select_queue to NULL, so the kernel's hash takes back control.

If that sounds reasonable, I can fix the original problem Stephen pointed 
out that select_queue in DCB isn't using the netdev_ops pointer.  I do 
still believe the existence of this function pointer is necessary; please 
consider the DCB case and let me know if you agree or not.

Cheers,
-PJ Waskiewicz
--
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