> Quoting Gleb Natapov <[EMAIL PROTECTED]>: > Subject: Re: Re: [PATCH RFC] sharing userspace IB objects > > On Tue, Jun 26, 2007 at 03:58:02PM +0300, Michael S. Tsirkin wrote: > > > > No, sharing a send queue must be done in software. I don't really see > > > > the reason > > > > for sarcasm: do you see value in sharing resources between multiple > > > > threads? > > > > Why not multiple processes? Some people just don't want to program > > > > in multithreaded environment. > > > > > > Yes I see the value in sharing resources between threads and processes > > > if done right. This proposition is far from being right. > > > > Ahem, *what* are you talking about? Sharing resources between threads was > > supported in > > libibverbs 1.0, *right from the start*. This is still the case with 1.1, > > and this API > > matches verbs quite closely which means that it can work pretty much on any > > hardware. > > Why do you think that I have a problem with multithreaded application is > beyond my understanding. I have a problem with you thinking that peaking a > completion by random process in FCFS order is a good idea.
Should that have been "picking"? I keep telling you. With multithreaded applications *that's what currently happens*. If multiple threads poll a CQ, which one gets which completion is currently unspecified. Are you worried about this? If not, why are you worried when multiple processes do this? Look here, hardware features do *not* just materialize when you build an API for them. What good would a pretty API that no hardware supports be? It's the other way around: I'm trying to extend our API to improve scalability with existing hardware. -- MST _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
