[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070817.180006.98552435.davem@davemloft.net>
Date: Fri, 17 Aug 2007 18:00:06 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: shemminger@...ux-foundation.org
Cc: netdev@...r.kernel.org
Subject: Re: [RFC] restore netdev_priv optimization (planb)
From: Stephen Hemminger <shemminger@...ux-foundation.org>
Date: Fri, 17 Aug 2007 17:49:09 -0700
> Fix optimization of netdev_priv() lost by the addition of multiqueue.
>
> Only configurations that define MULITQUEUE need the extra overhead in
> netdevice structure and the loss of the netdev_priv optimization.
>
> Signed-off-by: Stephen Hemminger <shemminger@...ux-foundation.org>
Every distribution vendor is going to turn MULTIQUEUE on. Therefore
%99 of Linux users will not see any gain from your patch.
You're walking around in a dark room and hitting walls every
few seconds. Take a moment and think about how to really deal
with this generically for a second before churning out another
patch.
For example, how about making the multiqueue limit fixed, say at 64
queues, and declare the egress_queues as an array of 64 entries. Then
you can get constant pointer formation for both the netdev priv and
the queues.
This will also basically eliminate all of the alloc_mqueue() logic,
since struct netdev will now always be a fixed size.
And, amazingly, this deals with the loopback issue transparently as
well. :-)
It would also be nice to just get rid of netdev->priv, it will prevent
more misuses like the cxgb3 case, for example.
-
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