[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081029052118.GA6412@gerrit.erg.abdn.ac.uk>
Date: Wed, 29 Oct 2008 06:21:18 +0100
From: Gerrit Renker <gerrit@....abdn.ac.uk>
To: Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>, dccp@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] [QPOLICY]: Ignore packets with specific priority
| This trivial patch allows qpolicies to be moved to userspace as demonstrated
| by attached C# code (requires mono). This way userspace-kernelspace interface
| is dead simple allowing for quite a lot flexibility in designing the way
| packet buffer is organized.
| The basic idea is that we set send buffer size so that only one packet fits in
| it. Sending second packet while first is inside buffer (has not been sent
| yet) causes send() to block until ccid allows the first packet to be 'send'.
One difficulty that I see is what to do when the send socket is non-blocking.
| For each real packet we call send() twice: one 'fake' (will be discarded just
| before sending) and one 'real' (contains user data). This makes all the
| waiting to be done on the 'fake' packet making sending the real one really
| fast. This allows for late data choice without difficult to implement ring
| buffers shared by user and kernel space or complicated qpolicies code on
| kernel side.
Maybe purists will not like this since the complexity is now shifted to the
user-kernel interface. But it may well be a start to develop some kind of
new interface which achieves the same in a cleaner way.
In any case, if people would like to test this feature, I'd be happy to fork
a new qpolicy subtree from the test tree.
| Results on CCID2 are very promising (near ideal), but CCID3 is somewhat
| disappointing to the extent I'm starting to think that I'm doing something
| seriously wrong while testing it.
|
Can you please narrow down what is happening with CCID-3. CCID-3 is very
complicated and sensitive, so it is possible that the problem is within
CCID-3 and not the qpolicy code - need more detailed information.
| Therefore I have two questions:
| 1. What do you think about the idea in general?
| 2. Could anybody test the attached code on both CCID2 and CCID3 and send
| results/observations to the list?
|
At the moment this is just enough code to allow a what seems to me working
proof-of-concept implementation.
I don't have mono installed and need to prioritise with time - the highest
priority at the moment is to keep the test tree up to date and bug-free.
If a stable interface evolves out of this development work, it would be
great to integrate it with the existing (C flat) code
http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/#DCCP_Library
| --- a/net/dccp/qpolicy.c
| +++ b/net/dccp/qpolicy.c
| @@ -120,11 +122,11 @@ struct sk_buff *dccp_qpolicy_pop(struct sock *sk)
| {
| struct sk_buff *skb = dccp_qpolicy_top(sk);
|
| - /* Clear any skb fields that we used internally */
| - skb->priority = 0;
| -
| - if (skb)
| + if (skb) {
| + /* Clear any skb fields that we used internally */
| + skb->priority = 0;
| skb_unlink(skb, &sk->sk_write_queue);
| + }
| return skb;
| }
Thank you for the above hunk -- since it fixes in fact a potential source of
trouble, I have merged it into the patch entitled "dccp: Policy-based packet
dequeueing infrastructure" and updated the test tree to use this patch.
http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=commitdiff;h=ffc6589ad8fb51edb37f31cbad9b913e9b47f630
--
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