Message-Id: <200805221948.18305.tomasz@grobelny.oswiecenia.net>
Date:	Thu, 22 May 2008 19:48:18 +0200
From:	Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
To:	Gerrit Renker <gerrit@....abdn.ac.uk>
Cc:	acme@...hat.com, dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] [DCCP][QPOLICY]: Make information about qpolicies available to userspace

Dnia Thursday 22 of May 2008, Gerrit Renker napisał:
> | But when it gets into mainline people should be able to write
> | applications that will be forward and backward compatible (as far as
> | possible) with various kernel versions.
>
> The main answer to that is below, but compare for instance with TCP -
> few socket options need runtime discovery. The type of their parameters
> and their option values are all described in a manpage. On the other
> hand, I like your approach of trying to come up with a novel solution.
>
TCP was designed before the era of having everything pluggable. DCCP on the 
other hand is prepared for adding new CCIDs. Logically then, it should be 
extensible in other areas too.

> | > As a possible suggestion, I came up with a minimalistic variant of
> | > querying the interface - only 7 lines, including documentation.
> | >
> | > This is attached and it works by exploiting that
> | >  * policy IDs are just numbers;
> | >  * so that we could use the highest supported ID instead of an array;
> |
> | I don't like the "highest supported ID" approach. But if you don't like
> | arrays a simple "bool getsockopt" would do, we could just ask the kernel
> | if it supports given qpolicy. Like (in pseudocode):
> | bool
> | supports_prio=getsockopt(sk,DCCP_SOCKOPT_QPOLICY_AVAILABLE,QPOLICY_PRIO);
> | Would that be ok?
>
> What I sent is just a sketch, nothing set in stone. I am happy to take
> my patch out of the repository if there are better solutions.
>
The question is: would you consider such a solution better? 

> | >  * parameters are tied to the individual policy, so that a second
> | >    query (about which parameters are supported) is not necessary.
> |
> | Can you guarantee that nobody ever will add a parameter? In fact even
> | today I can think of two parameters that could be added: the previously
> | discussed timeout and my new concept - the identity or category parameter
> | (which is a subject for a separate thread).
>
> During the design phase it is almost certain to change several times.
>
> When the design phase is over, it will have some parts that will not
> likely change.
>
> Hence I am trying to figure out - how much change is due to re-designing
> things and how much change is de facto required for a useful dynamic
> interface?
>
IMO we could divide the interface into two parts:
 - operations - they are likely to stabilize before pushing the code to 
mainline,
 - parameters (all kinds of numbers like DCCP_SCM_xxx, qpolicy ids, etc.) - 
there should always be a room for new ones (and maybe even deleting old 
ones). And one should be able to verify which numbers are valid - that's why 
we need operations for this purpose that are available from the very 
beginning.

> | BTW, the somewhat big code was meant to act as a framework for other
> | features. Like getting information about percent of dropped packets in
> | prio qpolicy queue.
> | --
>
> Ah - didn't understand what the qpolicy-specific getsockopt hooks were for.
>
> I think there is a way of doing this, but it requires a bit more work.
> This would be to use netlink sockets to communicate/request/poll
> information.
>
> The two alternatives I am aware of are
>
>  * kernel/userspace connector
>    [ Documentation/connector/connector.txt ]
>  * generic netlink interface
>    http://www.linux-foundation.org/en/Net:Generic_Netlink_HOWTO
>
As far as I understand netlink is a kind of intermodule communication 
mechanism (where module may be either in-kernel or userspace application).

> If done well, the interface could be very useful for several other
> things in DCCP:
>  * querying qpolicy interface (with regard to this email thread)
>  * querying the CCIDs (available, set preference list)
>  * getting much-needed runtime statistics into user-space
>    - this is a feature missing in UDP (and partly also TCP)
>    - so far only via CCID-3 getsockopt (tx_info/rx_info)
>    - there is research which says it would be nice to have the
>      current RTT, loss statistics etc in user-space
>  * thus calling for a generic solution.
>
> What do you think about this alternative?
>
I have nothing against creating generic interface for obtaining information 
about various aspects of dccp. But I can't see how netlink can help us here. 
>From the documents I've read I understand that generic netlink requires you 
to create a special kind of socket type and then you can send or receive 
information through it. But it seems to be something separate from dccp 
sockets.

As for information we can get from kernel wrt dccp we have at least:
1. fixed information that depends only on kernel version. For example list of 
ccids, list of available qpolicies, list of parameters for given qpolicy, 
etc. These are system wide and don't need reference to socket. These could 
even be exposed by read-only entries in /sys or /proc.
2. typical socket options. Among others: currently used rx/tx ccid, currently 
used qpolicy, queue and buffer sizes, etc. For these we need reference to 
socket and get/setsockopts are the natural choice. And I guess no changes 
should happen here.
3. statistics. These are not options in the sense that you cannot set them. 
You also cannot expect that two consecutive reads will return the same value. 
They depend on certain asynchronous events in various parts of dccp code. The 
first question is: should we pass those raw events to applications (such 
as "prio qpolicy: packet dropped") or aggregate data ("in the last 100 
packets 17 were dropped before sending")? For this kind of information we 
need reference to socket (struct sock *). And I can't see how we could obtain 
it from functions not mentioned in struct proto.

I suggest that we discuss points 1 and 3 separately because it may turn that 
different mechanisms will be applicable. getsockopt is possible in both which 
doesn't mean that it is the best solution.
-- 
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