netdev - Re: [PATCH net-next] rtnetlink & bonding: change args got get_tx

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]

Date:	Wed, 11 Apr 2012 08:20:54 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Ben Hutchings <bhutchings@...arflare.com>,
	Jay Vosburgh <fubar@...ibm.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] rtnetlink & bonding: change args got
 get_tx_queues

On Wed, 11 Apr 2012 07:55:47 +0200
Eric Dumazet <eric.dumazet@...il.com> wrote:

> On Tue, 2012-04-10 at 21:34 -0700, Stephen Hemminger wrote:
> > Change get_tx_queues, drop unsused arg/return value real_tx_queues,
> > and use return by value (with error) rather than call by reference.
> > 
> > Probably bonding should just change to LLTX and the whole get_tx_queues
> > API could disappear!
> 
> Absolutely ;)
> 
> 

It is more complex than that (actually the bonding driver is a mess).
The bonding device is already using Lockless Transmit and transmit queue length
of zero (good), but it then does some queue mapping of it's own which
is unnecessary.

Multiqueue only makes sense if there is a queue, otherwise the skb
can transparently pass through the layered device (vlan, bridge, bond)
and get queued on the real physical device.

Right now, trying to see if there is any impact by just leaving
bond device as single queue.
--
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