Date:	Wed, 18 Jun 2008 22:46:15 +0200
From:	Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
To:	Gerrit Renker <gerrit@....abdn.ac.uk>, acme@...hat.com
Cc:	dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] [DCCP][QPOLICY]: Make information about qpolicies available to userspace

Dnia Wednesday 18 of June 2008, Gerrit Renker napisał:
> | > In the kernel I think it is best to make it type-safe, i.e. no new
> | > parameters to already-defined policies. But I can't see how this would
> | > restrict the use.
> | > (...)
> |
> | So we would need new policy for each new parameter, right? I somehow
> | don't like it but it should work. You are right that this way runtime
> | parameter discovery is not necessary. BTW, we will have a bit of a
> | problem with naming qpolicies ;-)
>
> Yes, not claiming that my suggestions were very good.
>
> By the way, did you notice that the matrix was incomplete - timeout
> standalone was missing, the corrected version would look something like
>
Well, I assumed that you did that on purpose because that would imply that we 
need more or less N policies for N parameters added one at a time. When we 
want separate policy for just timeout we end up with 2^N policies. And that 
would be just mad because the same effect can easily be achieved with setting 
priority to the same value on all packets.

>     +-------------+--------+-------------------+------------------+
>
>     | Policy Name | Policy |         Presence of Parameters       |
>     |
>     |             | ID#    | DCCP_SCM_PRIORITY | DCCP_SCM_TIMEOUT |
>
>     +-------------+--------+-------------------+------------------+
>
>     | "simple     |   0    |        no         |        no        |
>     | "prio"      |   1    |       YES         |        no        |
>     | "timeout"   |   2?   |        no         |       YES        |
>     | "timed-prio"|   3?   |       YES         |       YES        |
>
>     +-------------+--------+-------------------+------------------+
>
> There is a special trick for the aggregate "timed-prio" policy: it is
> the logical-OR of the "prio" and "timeout" policy IDs. Perhaps composite
> policy IDs could be defined in this way.
>
Then we would have straight mapping between possible parameters and policy 
numbers. That is, effectively we would not set the policy number but request 
the capability of processing certain parameters, right? So that the 
application could specify 0, DCCP_SCM_PRIORITY, DCCP_SCM_TIMEOUT or 
DCCP_SCM_PRIORITY|DCCP_SCM_TIMEOUT as the policy ID?

Could be nice, but what happens if we have two policies with the same set of 
supported parameters? How do we differentiate them? In the above: how do we 
diffrentiate between simple policy (which doesn't have any parameters ever) 
and prio policy with no parameters (just because we don't need to provide any 
for one particular case)?

> | I will for sure be working on some apps to demonstrate how the new
> | interface can be used. But first I need to create a simple server/client
> | transmitting G.726 encoded voice over UDP/RTP (any hints on that?)...
>
> Tommi Saviranta has been working on a DCCP port for SpeexComm:
> 	http://tuomas.kulve.fi/projects/speexcomm/
> The port is available via SVN:
> 	svn co http://tuomas.kulve.fi/svn/speexcomm
>
> Leandro Sales de Melo has developed a DCCP plugin for gstreamer and used
> it with VoIP/speex. It comes with example applications for these:
> https://garage.maemo.org/frs/?group_id=297
> https://garage.maemo.org/projects/ephone
> http://www.mail-archive.com/dccp@vger.kernel.org/msg03101.html
> 
I'll have a look at these. It seems that GStreamer is the way to go. However, 
there is a minor glitch. GStreamer doesn't support a clean way of passing 
priority data between plugins, so the code will probably be a bit ugly.
-- 
Regards,
Tomasz Grobelny
--
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