netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: David Miller <davem@davemloft.net>
Cc: peter.p.waskiewicz.jr@intel.com, arekm@maven.pl, netdev@vger.kernel.org
Subject: Re: ~3 hours old git tree: Virtual device lo asks to queue packet!
Date: Sat, 21 Jul 2007 05:38:10 +0200	[thread overview]
Message-ID: <46A17FA2.8010906@trash.net> (raw)
In-Reply-To: <20070720.194743.71090882.davem@davemloft.net>

David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Thu, 19 Jul 2007 12:11:10 +0200
> 
> 
>>The easiest fix would be to use egress_subqueue[1] in struct
>>net_device, but I think that may cause warnings with newer gccs
>>when using a constant index that is > 0. OTOH using constant
>>indices doesn't seem to make much sense for the subqueue array.
>>
>>Arkadiusz, does this patch fix the problem?
> 
> 
> I've applied this, but long term we should either:
> 
> 1) Make loopback_dev dynamically allocated just like every
>    other netdev, so make loopback_init() a postcore_initcall()
>    to make sure that is setup early enough.
> 
>    Then have to walk over the tree making everything able
>    to handle the fact that it's a pointer.  Several data
>    structures are compile time initialized to "&loopback_dev"
>    for example, and therefore will have to be transformed into
>    a run-time initialization.
> 
> 2) Pick some arbitrary limit for the queues, and just have that
>    many of them allocated in every netdev.
> 
> I like #2 because it allows us to get back the netdev_priv()
> optimization.


Yes, some constant limit definitely makes sense. The Tx batching
patches motivated me to work through struct net_device with pahole
and I have some patches that rearrange it to save about 64 bytes and
move some members from very unfortunate positions to better ones,
but they still leave two 32 byte holes on SMP (with 64 byte
cachelines). Plugging one of these with a statically sized subqueue
array would be perfect since one of the holes is within the Tx
cachelines anyway (at least for now, until we add subqueue locks ..).

Its 2.6.24 material though, and I very much hope they will clash
with Stephen's plans to introduce struct net_device_ops.

  reply	other threads:[~2007-07-21  3:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-18 20:18 ~3 hours old git tree: Virtual device lo asks to queue packet! Arkadiusz Miskiewicz
2007-07-18 23:06 ` Patrick McHardy
2007-07-19  6:19   ` Arkadiusz Miskiewicz
2007-07-19  9:25     ` Patrick McHardy
2007-07-19 10:11       ` Patrick McHardy
2007-07-19 11:52         ` Arkadiusz Miskiewicz
2007-07-19 13:13           ` Patrick McHardy
2007-07-21  2:47         ` David Miller
2007-07-21  3:38           ` Patrick McHardy [this message]
2007-07-21  5:33             ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46A17FA2.8010906@trash.net \
    --to=kaber@trash.net \
    --cc=arekm@maven.pl \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=peter.p.waskiewicz.jr@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).