Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next.

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

On Tue, 26 Apr 2005 13:25:50 -0500
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> On 4/26/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > On Tue, 26 Apr 2005 22:10:26 +0400
> > Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > 
> > > > > > There may not be the same work with different data.
> > > > > >
> > > > >
> > > > > Ugh, that really blows. Now every user of a particular message type
> > > > > has to coordinate efforts with other users of the same message type...
> > > > >
> > > > > Imability to "fire and forget" undermines usefulness of whole
> > > > > connector. How will you for example implement hotplug notification
> > > > > over connector? Have kobject_hotplug wait and block other instances?
> > > > > But wait on what?
> > > >
> > > > This is a simple load balancing schema.
> > > > Netlink messages may be dropped in socket queue when
> > > > they are bing delivered to userspace - this is the same -
> > > > if work queue can not be scheduled, message will be dropped,
> > > > but in this case userspace also can not be scheduled
> > > > and message will be dropped.
> > >
> > > Btw, I belive we see that it is reverse direction...
> > > So we have reverse load balancing schema here -
> > > exactly like userspace socket queueing.
> > > We basically can not sleep here - it will be DOS.
> > 
> > And yet another btw - netlink is unreliable protocol,
> > that is why there are seq and ack fields in connector's header -
> > connector's users must implement some check on top of
> > raw connector messages - it could be returned message with
> > timeout resending and so on.
> > I wrote it several times and it is in connector's documentation.
> > 
> 
> I can accept that netlink is unreliable protocol and can drop messages
> - but that should only happen when there is memory pressure. In your
> case you simply can not send messages with frequency higher than your
> timeslice unless you implement synchronous protocol.
> 
> Load balancing allows bursts as long as average rate is under control
> - connector does not.

It happens not only when there is memory pressure,
but also when remote side does not read it's messages.
If system can not schedule work queue, then
it is the same situation. 
And, btw, if system under so strong pressure than 
work queue can not be scheduled, then no skb will be delivered
to/from userspace too.

> -- 
> Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/