"David S. Miller" <[email protected]> writes:
>
> In fact the exact opposite, such a suggested flow cache is about
> as parallel as you can make it.
It sounds more like it would include the FIB too.
> I don't understand why you think using the routing tables to their
> full potential would imply serialization. If you still believe this
> you have to describe why in more detail.
I guess he's thinking of the FIB, not the routing cache.
The current FIBs have a bit heavier locking at least. Fine grain locking
btrees is also not easy/nice.
-Andi
From: Andi Kleen <[email protected]>
Date: 26 Sep 2002 02:31:13 +0200
"David S. Miller" <[email protected]> writes:
>
> In fact the exact opposite, such a suggested flow cache is about
> as parallel as you can make it.
It sounds more like it would include the FIB too.
That's the second level cache, not the top level lookup which
is what hits %99 of the time.
The current FIBs have a bit heavier locking at least. Fine grain locking
btrees is also not easy/nice.
Also not necessary, only the top level cache really needs to be
top performance.
On Wed, Sep 25, 2002 at 05:29:31PM -0700, David S. Miller wrote:
> The current FIBs have a bit heavier locking at least. Fine grain locking
> btrees is also not easy/nice.
>
> Also not necessary, only the top level cache really needs to be
> top performance.
Sure, but if they were unified (that is what I understood what the original
poster wanted to do) then they would be suddenly much more performance
critical and need fine grained locking.
-Andi
P.S.: One big performance problem currently is ip_conntrack. It has a bad
hash function and tends to have a too big working set (beyond cache size)
Some tuning in this regard would help a lot of workloads.
From: Andi Kleen <[email protected]>
Date: Thu, 26 Sep 2002 02:46:45 +0200
> Also not necessary, only the top level cache really needs to be
> top performance.
Sure, but if they were unified (that is what I understood what the original
poster wanted to do) then they would be suddenly much more performance
critical and need fine grained locking.
This can be made, if necessary. If the toplevel flow cache lookup
table is sized appropriately, I doubt anything will be needed.
P.S.: One big performance problem currently is ip_conntrack. It has a bad
hash function and tends to have a too big working set (beyond cache size)
Some tuning in this regard would help a lot of workloads.
This is well understood problem and a fix is in the works.
See the netfilter lists.