[<prev] [next>] [day] [month] [year] [list]
Message-ID: <OF36BA88CF.246FB4F2-ON6525731E.0044EE77-6525731E.004506A3@in.ibm.com>
Date: Fri, 20 Jul 2007 18:03:56 +0530
From: Krishna Kumar2 <krkumar2@...ibm.com>
To: Patrick McHardy <kaber@...sh.net>
Cc: davem@...emloft.net, gaagaan@...il.com,
general@...ts.openfabrics.org, hadi@...erus.ca,
herbert@...dor.apana.org.au, jagana@...ibm.com, jeff@...zik.org,
johnpol@....mipt.ru, kumarkr@...ux.ibm.com, mcarlson@...adcom.com,
mchan@...adcom.com, netdev@...r.kernel.org,
peter.p.waskiewicz.jr@...el.com, rdreier@...co.com,
rick.jones2@...com, Robert.Olsson@...a.slu.se, sri@...ibm.com,
tgraf@...g.ch, xma@...ibm.com
Subject: Re: [PATCH 03/10] dev.c changes.
(My Notes crashed when I hit the Send button, so not sure if this went
out).
__________________
Patrick McHardy <kaber@...sh.net> wrote on 07/20/2007 04:50:37 PM:
> 32 bytes? I count 16, - 4 for the pointer, so its 12 bytes of waste.
> If you'd use it for gso_skb it would come down to 8 bytes. struct
> net_device is a pig already, and there are better ways to reduce this
> than starting to allocating single members with a few bytes IMO.
Currently, this allocated pointer is an indication to let kernel users
(qdisc_restart, setting/resetting tx_batch_skbs) know whether batching
is enabled or disabled. Removing the pointer and making it static means
those users cannot figure out this information . Adding another field to
netdev may be a bad idea, so I am thinking of overloading dev->features
to add a new flag (other than NETIF_F_BATCH_SKBS, since that is a driver
capabilities flag) which can be set/cleared based on NETIF_F_BATCH_SKBS
bit. Does this approach sound OK ?
Thanks,
- KK
-
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