Date: Thu, 29 Nov 2001 17:42:38 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: A180009977889@aol.com Cc: hackers@freebsd.org, questions@freebsd.org Subject: re: netgraph Message-ID: <Pine.BSF.4.21.0111291719030.22444-100000@InterJet.elischer.org> In-Reply-To: <23.1547b480.293832e2@aol.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 29 Nov 2001 A180009977889@aol.com wrote: > > The concept that "netgraph hooks" are a "leg up" on say, ETs drivers that > > have integrated bandwidth management and prioritization, WAN bridging > > support, load balancing and a probably 25% performance advantage is a bit > > entertaining. Unless you need to do some convoluted encapsulation netgraph > > is, aside from being appallingly non-standard to anything else in the > market, > > not much of an "advantage", and its a poster child for the trade off of > > "flexibility" versus performance. > > J. Elschier wrote... > > >Netgraph is a prototyping tool, which has enough performance to be useful > >in non-performance-critical applications. (such as all sync interfaces). > >It is not designed for gigabit interfaces etc. > > Im sure the guy with 900 DLCIs on his T3 would not agree that performance is > :not an issue" on sync interfaces.. Performance is always an issue, except > maybe with tcpdump. This short-sightedness is just what Im referring to. If he's doing 900 DLCI's on a T3 he should probably have enough budget to buy a router. However I don't think netgraph would have any problem with that, but it would get a bit cumbersome to adminster with 900 interfaces. That of course is a detail of the frame relay implimentation which I wrote to solve my own desire to have maybe 10 DLCIs. From a performance point of view it would handle 900 with no real degredation that I can think of. It wouldn't take much to add a netgraph node that doesn't need 900 interfacesm but instead presents a single interface and pretends that thew fannout occurs at the "next hop". What netgrapgh does allow me and others to do is to knock up modules to experiment with all these new protocols that are being churned out these days.. (e.g. the 802.1x netgraph module one fellow just wrote). I haven't seen any major drawbacks to netgraph yet, though it would definitly have more overhead than a single monolithic module written to specifically do some operation, it doesn't seem to be as much as I had feared, with no particular noticable overhead under most cases. BTW I don't see what short sightedness you are referring to... > > Making netgraph a plug-in option is fine and desireable. Touting it as "the > way" to do things is damaging to the OS in general,particuarly when you are > not willing to accept alternatives provided by commercial vendors. It is only "the way to go" in cases where it fits the bill.. I haven't seen any alternatives offered yet by any providers yet. (Actually that is not true, a provider has been doing work with the sppp stack). Netgraph is not a part of the basic system. If you leave it off, you still have all the abilities you had without it. It is a module that can be loaded if you want it, and I think that's just how it should be.. (well, it's used to provide pppoe service in the basic system, so it is needed sometimes). > > The best solution is to provide "options" to users. You adulterate the OS by > trying to make it do everything, when its very easy to provide clean hooks so > that different solutions can be seamlessly used depending on what is best for > a particular application. if_ethersubr.c is beginning to look like an > abortion, when one or two simple pre and post processing hooks would allow > for both open-source and commercial solutions, to be used at the users > discretion. Interesting.. Netgraph's influence in if_ethersubr.c is pretty minimal. with I think 1 conditional on the common path.. Wel worth it from my perspective. > > Its a matter of thinking about it and coming up with something that makes > sense, rather that the "I have something that works so lets stuff it into the > OS". So, don't use it... Others want to use it because it fits their requirements and allows them to add modules to do what they want without having to rewrite everything.... I think that helps REDUCE hacks in the rest of the networking code.. > > just my opinion. and you're certainly entitled to it.. You have a particular view of the world and a particular set of requirements of your environemnt. You can jusdge things as you wish according to those requirements. They just happen to be very different to what I see as my requirements, or others see as theirs. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0111291719030.22444-100000>