On Fri, 6 Jun 2003, Michael Shiu wrote:
> I am using DEVICE_POLLING by Lugzi Rizzo and connecting 2 em devices using > NG_ETHER with NG_BRIDGE. Actually, I am planning to make a netgraph node to > do some filtering but as a performance prototype, I am getting those results > mentioned. i.e. > > em0 - NG_ETHER - NG_BRIDGE - NG_ETHER - em1 > > The polling code currently does not work in SMP environments but with some > patchwork, I probably can make it work. But I am not clear if the netgraph > framework has other limitations. > > rgds, > _Michael > > > ----- Original Message ----- > From: "Vincent Jardin" <[EMAIL PROTECTED]> > To: "Julian Elischer" <[EMAIL PROTECTED]>; "Michael Shiu" > <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, June 06, 2003 4:13 AM > Subject: Re: Does Netgraph in FBSD 5.x SMP requires GIANT lock? it should not require Giant. However there are some locking 'holes' that come when locked resources are accessed by external code that is executed from other contexts.. e.g. many drivers do not know about the locks in their netgraph half, and just 'do' what they want. Also there are instances of callout (timeout) code doing things to a node without getting teh node's lock. > > > Maybe one giant2thread node could be introduced into the graphs. It could > put > the messages and the mbufs into a queue from a giant context, then they > could > be processed from a thread. > > Is it a possible architecture or do I forget something ? > > Regards, > Vincent > > Le Jeudi 5 Juin 2003 13:38, Julian Elischer a écrit : > > On Thu, 5 Jun 2003, Michael Shiu wrote: > > > Dear all, > > > > > > Just like to know if the netgraph code running 5.x SMP kernel requires > > > the GIANT lock? > > > > Netgraph has lovking built into it but I have not > > had teh time yet to "thrown the switch" and run it without > > giant. (actually it would only have giant if the edge node that > > introduces the packet has giant, or if it's running > > as a net thread.) > > > > What is your graph like? > > > > > I have the netgraph doing bridging right now but the performance is > > > limited by the CPU (right now, it is something around 100k pkt/s in > > > 4-STABLE). Does adding another CPU together with upgrading to 5.x be of > > > any help? I guess the bottleneck right now is only one thread is > > > executing in interrupt context with GIANT being held. Am I right? > > > > > > _Michael > > > > > > _______________________________________________ > > > [EMAIL PROTECTED] mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > > _______________________________________________ > > [EMAIL PROTECTED] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > _______________________________________________ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
