Dnia Friday 31 of October 2008, napisałeś:

quoted

quoted

One difficulty that I see is what to do when the send socket is
non-blocking.

But socket doesn't get into non-blocking mode until specifically
requested by fcntl(soc, F_SETFL, O_NONBLOCK) call, does it?

Yes - the problem is that the code does not stop the user from
setting non-blocking mode on the socket.

Yes, currently this concept is more a usage convention than a new interface in 
a strict sense. And so it is quite easy to misuse it.

quoted

quoted

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.

I think that much of the previously written qpolicy code could be
removed from the kernel so the interface would be really simple. No
policy switching, no fancy parameters, etc. The only difference from
standard interface would be that a packet could have a 'drop me' flag
(priority 65 in my code). Ok, I agree some may consider it tricky but I
wouldn't call it complicated. The complicated part is meant to be on the
userspace side. And that in my opinion has many advantages: easier
debugging, easier to add new (possibly complex) queuing policies.

I fully agree with the idea, it is the realisation that causes me
some headaches. It would be great if the code need not call send() twice
to send a single packet, and if an skb need not be allocated in order to
create a "waiting effect" in userspace.

The other alternative that I see is to come up with completely new
system calls - as done in SCTP for instance. But this would only make snse
if with the present means things get too ugly; i.e. if the
new semantics can not be expressed with the given system calls.

So there is agreement on the idea, I hope is that realisation
can be refined - without overloading existing calls too much.

What about using select() call to get the effect of waiting? I think that 
select() is precisely designed for such a thing. It is generally used on 
reading from sockets so it could be used on writing to sockets as well. I 
haven't looked at the code yet to know how complicated it might be to 
implement but it seems to be a nice idea to consider.

quoted

quoted

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.

On one test it seemed not to work at all in my setup: ccid3 seems not to
limit traffic at all. But that was just one test so it may well be my
fault.

If you notice anything odd, please do report it on the mailing list.

I will as soon as I have some useful information (that is when I test it on 
fresh git tree).
-- 
Regards,
Tomasz Grobelny