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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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.

-- 
Dmitry
-
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/