Re: [RFC] batched tc to improve change throughput

[Thomas Graf <tgraf@suug.ch>]

* Dan Siemon <1108246033.7554.18.camel@ganymede> 2005-02-12 17:07
> On Sat, 2005-12-02 at 08:45 -0500, jamal wrote:
> > On first impression, this looks very nice - I think you got the object
> > hierachy figured etc; i will look closely later.
> > What would be really interesting is to see (gulp) a SOAP/xml interface
> > on top of this. Is this something you can do with those "bindings"?
> 
> Yes, a SOAP/XML-RPC interface should be quite possible.  This is one of
> the main reasons I went to the trouble of creating the Mono bindings.  I
> need to create some sort of XML interface to LQL in the next few weeks.

Before you go ahead, please consider its possible usages. If possible
it should conform to an existing format allowing for distributed
configuration of network nodes. If no such thing exist and you design
your own format please consider the following requirements, because it
would be sad if you waste effort that needs to be redone later on.

 - all components of the networking configuration must be configurable.
   This includes links, neighbours, routes, routing rules, traffic
   control but also configuration parameters currently only accessible
   via ethtool.

 - The whole interface must take care of the byte order issues. This is
   the most tricky part.

 - It must be possible to extend it without breaking backward
   compatibility.

> As for combining my work with Thomas, I'm certainly willing to discuss
> it.

So let's discuss it, from what I can see your library only consists of
basic netlink connection abilities and message parsers/builders on a
per netlink user basis. You do not provide any ways to customize it,
if the user of your library wants to send its own messages he's pretty
much on its own because the whole process of constructing the message,
sending it and waiting for the ack is hidden behind one single function.

The per object API is quite similiar, you also let the user set the
attributes to a object and then commit that object to the kernel.

Honestly speaking, your API doesn't fit my needs and the changes to
make it suiteable would be rather big so I'm not sure whether a merge
of my code into yours would make much sense and the only that could be
merged from your side to mine would be the additional support for two
or three qdiscs such as htb.