[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B725D@saturn3.aculab.com>
Date: Fri, 31 May 2013 10:06:07 +0100
From: "David Laight" <David.Laight@...LAB.COM>
To: "Erik Hugne" <erik.hugne@...csson.com>,
"David Miller" <davem@...emloft.net>
Cc: <paul.gortmaker@...driver.com>, <netdev@...r.kernel.org>,
<jon.maloy@...csson.com>, <ying.xue@...driver.com>
Subject: RE: [PATCH net-next 02/12] tipc: Add "max_ports" configuration parameter
> > View compile time constants and module parameters as artificial
> > limits, they are terrible and unnecessary.
> >
> > There is no reason you cannot restructure this table so that you
> > can dynamically size it at run time.
>
> The TIPC ref table index is used directly as the port identity in the
> TIPC publications. When a socket is bound, this ID is published to all
> other nodes in the cluster.
> If we where to allow the table to be changed dynamically, we would need
> to change the port identities for already bound sockets/ports, withdraw
> the old identity and publish the new one.
> In the best case, this will lead to a temporary interruption for all
> TIPC services until the new port ID's have been propagated out to the cluster.
Eh?
Doubling the size of the array doesn't require that the old index
be invalidated. At most it requires an rcu before the old index
array is discarded.
If you use the low bits of the port indentity (32bits ?) as the
table index and the higher bits as a seq value to identify stale
references then you need to distribute the old entries into the
correct places in the new table.
This isn't hard and there could be generic 'reference allocator'
that would do this for you.
David
--
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