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:	Fri, 20 Jul 2007 14:37:06 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Krishna Kumar2 <krkumar2@...ibm.com>
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.

Krishna Kumar2 wrote:
> 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 ?
>   

I guess so. It would be more consistent with things like HW checksumming
etc. though to handle this through ethtool and have the ethtool callbacks
set or clear just the one feature bit. That would mean you don't need
to provide further indication of the device's capabilities to the stack
since only the driver enables or disables the feature.


-
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