From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 18 Oct 2006 07:42:17 +0200
How many people are using DECNET and want to pay the price of this
20 bytes dnports structure ?
I bet you could make that cost get hidden by careful rearrangement
of the struct flow, or adjustment of the implementation.
Hi,
On Tue, Oct 17, 2006 at 11:53:36PM -0700, David Miller wrote:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 18 Oct 2006 07:42:17 +0200
How many people are using DECNET and want to pay the price of this
20 bytes dnports structure ?
Point taken :-) Eric, you also need to add a ||
On Wednesday 18 October 2006 10:20, Steven Whitehouse wrote:
Hi,
On Tue, Oct 17, 2006 at 11:53:36PM -0700, David Miller wrote:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 18 Oct 2006 07:42:17 +0200
How many people are using DECNET and want to pay the price of this
20 bytes
Hi David,
David Miller schrieb:
I don't like these kinds of patches because %99 of people will never
ever realize the savings because distribution vendors will always,
unlaterally, enable everything.
People producing Linux Appliances DO compile their own kernels.
And some distribution
Hi,
Its not used at the moment[*], but would be required for any kind of flow
tracking. The objnum field, could be folded into the objname field I
guess on the basis that objnamel == 0 means objname[0] represents the
objnum, but that doesn't really buy much.
Well, as I privately said
On Wednesday 18 October 2006 14:42, Steven Whitehouse wrote:
Hi,
Its not used at the moment[*], but would be required for any kind of
flow tracking. The objnum field, could be folded into the objname field
I guess on the basis that objnamel == 0 means objname[0] represents the
From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 18 Oct 2006 15:32:22 +0200
OK then. Even on a distro kernel (allyesconfig), size(flow) would
shrink by 20 bytes.
For the time being, why don't we just kill off the unused dnports
bits entirely.
Once the support code to use those bits is written,
David Miller a écrit :
From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 18 Oct 2006 15:32:22 +0200
OK then. Even on a distro kernel (allyesconfig), size(flow) would
shrink by 20 bytes.
For the time being, why don't we just kill off the unused dnports
bits entirely.
Once the support code to
Hi David
Each route entry includes a 'struct flow'. This structure has a current size
of 80 bytes. This patch makes a size reduction depending on
CONFIG_IPV6/CONFIG_IPV6_MODULE/CONFIG_DECNET/CONFIG_IP_ROUTE_FWMARK
For a platform doing IPV4 only, the new size is 36 bytes (instead of 80)
As
In article [EMAIL PROTECTED] (at Wed, 18 Oct 2006 07:08:07 +0200), Eric
Dumazet [EMAIL PROTECTED] says:
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
struct {
struct in6_addr daddr;
struct in6_addr
From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 18 Oct 2006 07:08:07 +0200
Each route entry includes a 'struct flow'. This structure has a
current size of 80 bytes. This patch makes a size reduction
depending on
CONFIG_IPV6/CONFIG_IPV6_MODULE/CONFIG_DECNET/CONFIG_IP_ROUTE_FWMARK
For a
YOSHIFUJI Hideaki / a écrit :
In article [EMAIL PROTECTED] (at Wed, 18 Oct 2006 07:08:07 +0200), Eric Dumazet
[EMAIL PROTECTED] says:
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
struct {
struct in6_addr daddr;
David Miller a écrit :
From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 18 Oct 2006 07:08:07 +0200
Each route entry includes a 'struct flow'. This structure has a
current size of 80 bytes. This patch makes a size reduction
depending on
13 matches
Mail list logo
