netdev - Re: ~3 hours old git tree: Virtual device lo asks to queue packet!

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]

Message-ID: <46A17FA2.8010906@trash.net>
Date:	Sat, 21 Jul 2007 05:38:10 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	David Miller <davem@...emloft.net>
CC:	peter.p.waskiewicz.jr@...el.com, arekm@...en.pl,
	netdev@...r.kernel.org
Subject: Re: ~3 hours old git tree: Virtual device lo asks to queue packet!

David Miller wrote:
> From: Patrick McHardy <kaber@...sh.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.
-
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