[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070817161928.6b6302fd@freepuppy.rosehill.hemminger.net>
Date: Fri, 17 Aug 2007 16:19:28 -0700
From: Stephen Hemminger <shemminger@...ux-foundation.org>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org
Subject: Re: [RFC] restore netdev_priv optimization
On Fri, 17 Aug 2007 16:04:09 -0700 (PDT)
David Miller <davem@...emloft.net> wrote:
> From: Stephen Hemminger <shemminger@...ux-foundation.org>
> Date: Fri, 17 Aug 2007 15:40:22 -0700
>
> > Compile tested only!!!
>
> Obviously. The first loopback transmit is guarenteed to crash.
That is fixable.
> > Fix optimization of netdev_priv() lost by the addition of multiqueue.
> > Move the variable size subqueues to after the constant size priv area.
> >
> > When putting back the old netdev_priv() code, I tried to make it
> > clearer by using roundup() and ALIGN() macros.
> >
> > --- a/include/linux/netdevice.h 2007-08-17 12:08:51.000000000 -0400
> > +++ b/include/linux/netdevice.h 2007-08-17 12:48:03.000000000 -0400
> > @@ -575,16 +575,15 @@ struct net_device
> >
> > /* The TX queue control structures */
> > unsigned int egress_subqueue_count;
> > - struct net_device_subqueue egress_subqueue[1];
> > + struct net_device_subqueue *egress_subqueue;
> > };
>
> This just trades off the dev->priv dereference for a
> dev->egress_subqueue dereference. I bet they occur about equally in
> the data paths, at least on transmit.
The subqueue is only referenced in start/stop queue and that only happens
once per packet on normal tx, and only if multiqueue is used.
The existing multiqueue penalizes all devices, not just multiqueue devices.
> And this also breaks loopback again, which uses a static struct netdev
> in the kernel image, it doesn't use alloc_netdev(), so egress_subqueue
> of loopback will be NULL.
That can be overcome.
--
Stephen Hemminger <shemminger@...ux-foundation.org>
-
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