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?
> > 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~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
|