> [EMAIL PROTECTED] wrote: > > > >>> > >>> > >>> I guess I still don't see why that would be worse > than spinning - in > >>> either case the ip_input thread is not capable of > doing anything. > >>> You could make the same argument when using a > software crypto > >>> provider. I think if we're worried about > holding up ip_input(), > >>> which seems like a valid concern, then even the > software crypto > >>> providers should be handled asynchronously. > >> > >> > >> I'm not talking about consuming cycles. I'm not > talking about wall > >> clock time considerations. I'm talking about > potential deadlocks due > >> to cv_wait. > >> > >> You must -not- under any conditions cv_wait while > in ip_input's > >> path. Because you don't know anything about what > locks or PIL the > >> calling context is coming from. > > > > > > But no locks should be held.... If the contention > is we have to guard > > against a buggy NIC driver then yes. However, we > will sacrifice > > performance to defend against bad behavior. > > Its just _just_ locks. (Although that concern arises > as well.) Its the > fact that the read you're running on may be in > interrupt context.
If ip_input() is in soft ring thread (which is always the case in Niagara 2), is it ok to be cv_wait()'ed ? Chi-Chang > > Please, please, don't try to come up with some > hackery to make this > work. Its best if we adhere to the rule that > ip_input is called from > streams functions, and must adhere to the same rules > that all other > streams functions follow that.... that is that thou > shalt not sleep. > > Doing anything else is likely to cause spectacular > failure at some point > in the future. > > -- Garrett > -gary > > >> > >> -- Garrett > >> > >>> > >>> -gary > >>> > >>>> > >>>> -- Garrett > >>>> > >>>>> > >>>>> > >>>>> -gary > >>>>> > >>>>>> > >>>>>> -- Garrett > >>>>>> > >>>>>>> > >>>>>>> -gary > >>>>>>> > >>>>>>>> > >>>>>>>> -- Garrett > >>>>>>>> > >>>>>>>>> Right? > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > _______________________________________________ > networking-discuss mailing list > [email protected] > This message posted from opensolaris.org _______________________________________________ networking-discuss mailing list [email protected]
