Dnia Tuesday 08 of July 2008, Gerrit Renker napisał: > Thank you for those scenarios -- the problem is now better to understand. > > | I would like to know how applications are supposed to use DCCP in 4 > | scenarios: > > (1) ... (3) can be handled without too many ambiguities; (4) seems to be > the key point. > Yes, but difference between 1 and 2 also needs some consideration. > | 1. The application wants to use the old behaviour (that is simple policy > | with no parameters). > > By setting the ID for the `simple' policy (which does not use parameters) > to 0. > Which is the default, by the way. > | 2. The application wants to use prio policy but needs no parameters. > > That should not be a problem if we only check the supplied parameters. > > The prio policy (any policy for that matter) needs a way of interpreting > the absence of parameters meaningfully. > Currently prio policy should do fine. The result would be the same as if all packets were supplied with the same parameter. In effect 'random' packets are dropped. > | 3. The application wants to attach priority information to each packet. > > This would be the default/expected case. > Yes. > | 4. The application wants to attach priority and timeout information to > | each packet. If kernel cannot process timeout then fall back to priority > | information only. > > I can think of at least two ways of tackling this -- maybe there are more: > > (a) Separate policies for "prio" and "prio with timeout" > --------------------------------------------------- > Would be resolved when trying to set "prio with timeout" policy - the > kernel would either accept (and understand) it or return an error. > So we would have "simple", "prio" and "prio with timeout" policies. The questions are: 1. Should we have "timeout" policy as well? 2. Should we have "prio without priority"* policy as well? * On this example we clearly see that prio is not the best name possible. Maybe something like "realtime policy" would be better? Because the key difference to "simple" policy is the fact that send never waits (ie. the queue seems to be never full). Maybe there exists an even better name than "realtime". What do you think of changing the name? > (b) Use of optional parameters > -------------------------- > If I understand you correctly, this is actually the way you would > design the use of parameters, and my understanding of it is to > that there are a few basic (well-defined) policies which could be > combined with a number of optional additional parameters -- is that > your idea? Yes. The point is: as long as you don't change the basic behaviour there is no need to change policy name/number. Timeout parameter would be entirely optional with default value of infinity. If you were to add a required parameter new policy would probably have to be created. > If this is the case then we need to step back and sort > out the base policies plus set of optional parameters, and find a > way of dealing with each combination. At first sight, this seems > more difficult and complicated than (a). > For me it's not. Note that for each main policy you only have to think about two things: 1. How should it behave if all parameters are supplied. 2. If not all parameters are supplied what should be their default values. For priority it could be 0, for timeout it could be infinity. If you cannot think of a sensible default value for a parameter it is a sign that new policy should be created. In effect you don't have to think about each combination of parameters separately. > Not directly related to above questions, but rather as inspiration I > attach the sketch which I did for the definition of qpolicies. The idea > is to use a separate enum for each combination of parameters. The first > entry is initialised using the parameter bitmask, subsequent entries > have subsequent numbers. > 1. I would summarise difference in our ideas as follows: My approach: we have an algorithm (policy) and let's think what can affect the behaviour of this algorithm => algorithm is first, set of parameters is second. Your approach: we have a set of parameters and let's think what algorithm (policy) can be used to manage them => set of parameters is first, algorithm is second. 2. By choosing policy DCCPQ_POLICY_TIMED_REVERSE_PRIO you basically give the kernel two pieces of information: a) what set of parameters will be used (QPOLICY_INITIALISER(QP_PARAM_PRIO| QP_PARAM_TIMEO)), b) how packets will be managed in a queue (DCCPQ_POLICY_TIMED_REVERSE_PRIO-QPOLICY_INITIALISER(QP_PARAM_PRIO| QP_PARAM_TIMEO)). Do we agree in these points? -- Regards, Tomasz Grobelny -- To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
