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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ