On Tue, 2004-09-28 at 20:13, Herbert Xu wrote:
> 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.
But why? ;->
> > 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.
> > 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.
> > 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.
> > 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
|