[Top] [All Lists]

Re: [PATCH][IPv6] separation xfrm_lookup from ip6_dst_lookup

To: YOSHIFUJI Hideaki <yoshfuji@xxxxxxxxxxxxxx>
Subject: Re: [PATCH][IPv6] separation xfrm_lookup from ip6_dst_lookup
From: Kazunori Miyazawa <kazunori@xxxxxxxxxxxx>
Date: Tue, 03 Aug 2004 18:21:10 +0900
Cc: davem@xxxxxxxxxx, herbert@xxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, usagi-core@xxxxxxxxxxxxxx
In-reply-to: <20040803.020015.44364045.yoshfuji@xxxxxxxxxxxxxx>
References: <20040730171205.114f22ba.kazunori@xxxxxxxxxxxx> <20040801195135.16734846.davem@xxxxxxxxxx> <20040803.020015.44364045.yoshfuji@xxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 0.7 (Windows/20040616)
YOSHIFUJI Hideaki wrote:

In article <20040801195135.16734846.davem@xxxxxxxxxx> (at Sun, 1 Aug 2004 19:51:35 -0700), 
"David S. Miller" <davem@xxxxxxxxxx> says:

On Fri, 30 Jul 2004 17:12:05 +0900
Kazunori Miyazawa <kazunori@xxxxxxxxxxxx> wrote:

I consider copying flowi(fl_rt) uses too much stack at the moment.
I'll re-send the fixed patch again.

I agree, and let's defer this patch until we
resolve that.

Is the overhead for allocating memory okay?
Or, do we allcoate some per-cpu memory while ipv6.o initalization phase?
(check: lock? preemption?)
Or, will we allocate fl (and fl_rt) per sock{} (ipv6_pinfo{})?

My intention is not high art, just using struct in6_addr
instead of struct flowi to store final destination.

We have similar stack usage in other codes, and I would fix them at the same time.

These might be my changes. I will fix them.

Another question just for future reference: how many bytes (approx.) do we accept on stack?

Note: sizeof(struct flowi) is 72 bytes (on i386)


--Kazunori Miyazawa

<Prev in Thread] Current Thread [Next in Thread>