On 3/3/2015 4:50 PM, David Lamparter wrote: >>>> On Tue, Mar 3, 2015 at 7:19 AM, Greg Troxel <[email protected]> wrote: >>>>> My basic opinion is that shm interfaces end up being painful for >>>>> various reasons, including portability but also leaving shm segments >>>>> around. Since this is control plane, and sockets are fast anyway, I >>>>> don't see any reason to get wrapped up in shm. >>> Le 03/03/2015 16:31, Dinesh Dutt a écrit : >>>> +1, plus the issue that the various daemons may no longer be isolated >>>> from each other due to this shm, >>>> >> On 3/3/2015 12:37 PM, Olivier Dugeon wrote: >>> What do you mean by 'may no longer be isolated from each other' ? They >>> are already link to the zebra daemon. >>> In order to implement BGP-LS, we need some communication between OSFP, >>> IS-IS and BGP. Of course, this will >>> break this isolation principle, but wathever the solution will be. > I agree with Dinesh & Greg. The problem is, with SHM, it is far easier > for invalid data to cause a crash in all the daemons from a bug in just > one of the daemons. The problem isn't locking or anything, it's invalid > (pointer) data inside the SHM data. It's possible to take precautions, > but ultimately you need to validate all incoming data and thus lose much > of the zerocopy advantage.
I too am not a big fan of SHM, unless you have something really simple like a double buffered scheme with single writer. For cases where IPC is too expensive (e.g., between a TED and path computation) I think a scheme that provides a common way to bind additional functionality into a (e.g., TED) daemon makes more sense. >> On Tue, Mar 03, 2015 at 02:23:59PM -0500, Lou Berger wrote: >> Have you considered introducing a generic TED (topology database) >> deamon in parallel to zebra? I think this would more closely match what >> other implementations have done and there are many advantages over >> direct protocol exchanges. >> >> And yes, I know this question/topic is orthogonal to the current >> question/thread on shm vs ipc/rpc. > This sounds interesting. The direction of this, as I understand it, is > to split off new functionality into a separate daemon to reduce > congestion in zebra. exactly. It makes a lot of sense to have a common topology repository/DB just like it does for normal routes, but there's little if any intersection/overlap with current zebra so why put it into the same daemon... Lou > Jumping from this to details regarding socket-based protocols, there are > also some design questions. I'd like to use some pseudostandard > extensible encoding, allowing us to add fields in a structured manner > and profit from code generators for various languages. Apache Avro is > unfortunately under the Apache License, leaving mostly protobuf. What > are people's opinions on this? > > (I'd very much like to use something common here, for ZAPI, OSPFAPI, and > any new APIs including linkstate stuff and structured access to > configuration.) > > > -David > _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
