Re: [RFC] batched tc to improve change throughput

[Dan Siemon <dan@coverfire.com>]

Sorry, for the tardy response.

On Tue, 2005-15-02 at 21:47 +0100, Thomas Graf wrote:
> I see, well I can extend my objects, I'm even willing to change the
> architecture if needed. The only requirements from my side is to
> keep the generic caching header to allow putting these objects into
> generic caches and keep it simple to readd commit/rollback extesions
> later on.
> 
> What is exactly required to make it GObject aware? I've never worked
> with GOBject so far. Basically a qdisc looks like this at the moment:
> 
> struct rtnl_qdisc
> {
> 	NLHDR_COMMON;		/* common fields required by cache */
> 	NL_TCA_GENERIC(q);	/* generic tc fields (parent, handle, ifindex ...) */
> 	void *opts;		/* qdisc specific options (e.g.  rtnl_sch_fifo) */
> };
> 
> The NLHDR_COMMON must stay first, the ordering of the others doesn't
> matter.

That could be a problem.  The GObject struct must be at the start so
that all sub-classes can be operated on with the g_object_ functions.
The only way to make these objects work with your caching scheme would
be to make a sub-class of GObject with the caching information.  This
would have the benefit of adding ref counting etc.

The following URL will give you a bit of background on GObject.
http://www.le-hacker.org/papers/gobject/

-- 
OpenPGP key: http://www.coverfire.com/files/pubkey.txt
Key fingerprint: FB0A 2D8A A1E9 11B6 6CA3  0C53 742A 9EA8 891C BD98