Re: [PATCH] Improve behaviour of Netlink Sockets

On Tue, 2004-09-28 at 20:13, Herbert Xu wrote:

On Tue, Sep 28, 2004 at 08:32:17AM -0400, jamal wrote:

quoted

Actually i just examined the events generated by the script, they are
IFLA and ROUTE events and not IFA.
So take a look at:rtmsg_ifinfo()

You're right.  rtmsg_info() is using GOODISZE unnecessarily.  I'll
write up a patch.

But why? ;->

quoted

Ah, but theres clearly benefit into saving packets from crossing to user
space in particular in the case of overload. You do save on system
resources for sure in that case.

Can you please elaborate on those benefites/resources?

Well, if you are gonna overrun the socket anyways, is there a point
in delivering all that incomplete info?
If you go ahead and deliver it anyways, you will be crossing
kernel->userspace. Its a worthy cause to do so.
 

If you do this when only one listener's queue is full, then doesn't this
mean that you penalise everyone just because one task's receive queue is
small?

Yes, thats part of the issues.

quoted

Right, but only find out after reading a subset of messages which cross
into user space. Which is wasted cycles really.

Can you please elaborate on "crossing into user space"? I don't think
I understand where these cycles are being wasted.

delivering messages which get obsoleted by an overun from kernel to user
space for uses up unnecessary cycles.

quoted

Now if you could say from user space "please continue where you left
over" the messages before overrun wont be a waste. I do think thats not
wise for events(you should be able a summary of the issue some other way
as in overruns at the moment) but is definetely need for large get
results.

What do you mean by large get results? I thought we've agreed that
scenarios 1) and 2) (get and dump) cannot generate overruns unless
you're doing something silly like sharing your unicast socket with
multicast.  Please point me to a netlink get function that returns
an unbounded or unreasonably large skb.

A dump may be harder given it keeps state. A get item which generates
a huge dataset (dont ask me to give you an example) is going to cause
overruns. Think a multi message formated data.

quoted

A large queue may actually be a problem if it also gets overflown since
it takes relatively longer to find out. You still have to read the damn
state to find out details.

Not quite.  Overrun errors are reported immediately.  

Yes, except they get reported sooner (by virtue of queue getting filled
sooner) if you have a 4K sock buffer vs 1M if you are registered for the
same events. I Know its a digression - just making a point.

What we don't
have is an easy way to flush out the unread messages from before the
overrun.  Well actually you could just close the socket and reopen it.

I think you you should be able to purge queue from the kernel side. I
have a feeling we are talking two different things.

Yes but the end result is that the sender stops sending.  I'm not aware
of any existing TCP mechanisms that result in packets being queued in a
router on the way.

I think you are taking it too literal Herbet ;->
The end goal is what counts i.e the cause of congestion is alleviated.
Intermidiate buffering is a very well known/used trick to alleviate
congestion - especially in a local scenario. Of course such queues have 
finite buffers - you just engineer it so the queue doesnt overflow and
head of line blocking is tolerable. Either of those concerns not
addressed, shit will hit the fan.

cheers,
jamal