Re: [PATCH] Improve behaviour of Netlink Sockets

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

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.

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?
 

Agreed it will postpone the problem, and not cure it.
Where i saw the benefit is if this queue is full/overloaded then you
dont bother transfering skbs to the sock receiveQ - instead you overrun
the event listeners (on purpose) before giving them any data. This

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?

quoted

In fact this has an advantage over the intermediate queue.  With the
latter, you need to hold the packet in place whether the applications
need it or not.  While currently, the application can choose whether
it wants to receive a large batch of events and if so how large.

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.

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 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.  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.

Its actually worse than that -->which is a shame since we have more
control over what can be sent to user.
Congestion could be driven by receiver as well. Look at TCP zero windows
for example. Or even ECN.

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.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt