netdev - Re: [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked version of Tomasz's patch set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 2 May 2008 22:39:58 +0200
From:	Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
To:	Gerrit Renker <gerrit@....abdn.ac.uk>, dccp@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked version of Tomasz's patch set

Dnia Wednesday 30 of April 2008, Gerrit Renker napisał:
> | c) allow qpolicy to use each cmsg header as different parameter. So that
> (...)
> I think (c) is best, here is what I'd support.
> (...)
Seems we are getting closer in our views, see the just sent patch.

> Ok, but this is a separate question and it is about a yet non-existing
> policy.
>
Hopefully someone, someday will implement it. So it is good to have a basic 
idea how it might work.

> So far there is a "priority" policy, for which I think we agree that 32
> bits are enough.
>
For storing just priority - yes. I'd even say that it is too much...

> And both associated parameters can be parsed differently, in particular
> there is no requirement to restrict DCCP_SCM_TIMEOUT to use 32 bits - it
> could even pass a struct timeval or struct timespec.
>
Yes, that's nice.

> Then there is a yet non-existing "timeout" policy, which has no associated
> field yet. If we can assume that e.g. the skb->tstamp field can be used
> to store timeouts, then there are separate fields associated with separate
> policies.
>
> Thirdly, there is the aggregate policy "priority+timeout", which can
> then use both skb->priority and skb->tstamp.
>
> I.e. to answer the question, I think it is best to implement "timeout"
> first, solve the problems it brings up; when that is done,
> "priority+timeout" will be easy to do - it could be constructed just out of
> the existing functions defined for "priority" and "timeout".
>
> In that manner, other policies can be modularly constructed - for instance
> by combining "timeout" with a different form of the "priority" policy.
>
I'm not entirely sure if such modular constructions would be possible. I 
prefer to think of "timeout policy" and "prio policy" as a special cases 
of "timeout+prio policy" with respectively DCCP_SCM_PRIORITY and 
DCCP_SCM_TIMEOUT not supplied (and thus set to their default values: 0 and 
INFINITY).
-- 
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