Re: [PATCH 1/2] improve netem reorder flexibility

[Stephen Hemminger <shemminger@vyatta.com>]

On Sun, 17 Jan 2010 18:56:36 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> From: Christian Samsel <christian.samsel@rwth-aachen.de>
> Date: Sun, 17 Jan 2010 13:11:18 +0100
> 
> > Am Samstag, 16. Januar 2010 10:46:54 schrieb David Miller:
> >> This is a complete mess, and we need to sort it out before we think
> >> about changing the size of qopt at this point.
> >> 
> > Just to state this clearly, by cleaning up the mess you mean switching netem 
> > completely over to netlink attributes? 
> 
> I think the only way we can proceed is to keep the current qopt
> structure static, and only add things using new attributes.
> 
> I would also suggest that we make sch_netem.c strictly require a
> specific size for the structure.  And before anyone says that will
> break something, it's much better than what we have now which is
> random, silent, dropping of attributes.


Just to make it clearer. The normal netlink method of nesting attributes
(done by nla_parse_nested) is:

 +----------------------+------------
 |  len1 | type1| data1 | len2 | ...
 +----------------------+------------
 
But netem uses a sequential format:

 +------+---------------------+------------
 | qopt | len1 | type1| data1 | len2 | ...
 +------+---------------------+------------

So to enhance netlink, the best way is to add new attributes.
Changing the size of qopt will break binary compatiablity because
the code that parses sequential options will get the wrong offset.
Changing the size of attributes will also break compatiablity
as well.

Also, at some point all the functions in netem could be broken
into separate if too complex. For example, the code that was
submitted to replay a recorded trace probably would be better off
as a separate qdisc.