[cgl_discussion] RE: [cgl_specs] Proposal to change SCL.1.0 in CGL_Req spec

Zhuang, Louis louis.zhuang at intel.com
Wed Jul 9 07:57:52 PDT 2003


Dear Ibrahim,
	It seems we should move the discussion into cgl_discussion...
	Definitely breaking down loses the big picture a bit, but if the requirement has orthogonal parts, WBS makes our life much easier. 
	AEM is designed to support enormous descriptors in an asynchronous manner. It is efficient. But, IMHO, the two things (scalable descriptor and asynchronous mechanism) are orthogonal such as AIO vs. epoll. Even though both are very important, I still guess some customers cry for one rather than the other.
	My colleagues and I will analysis the gap between each POC and SCL.1.0, not among POCs... Before that, I'd like to revise requirement itself without any concrete implementation in mind. My question is, why CGL customers have the requirement, and how they plan to use the feature?
	 
  - Louis 

> -----Original Message-----
> From: Ibrahim Haddad (QB/LMC) [mailto:ibrahim.haddad at ericsson.com]
> Sent: Wednesday, July 09, 2003 9:28 PM
> To: Zhuang, Louis
> Cc: Fan, Ardelle; CGL Specs-sg; Linda Bebernes
> Subject: RE: [cgl_specs] Proposal to change SCL.1.0 in CGL_Req spec
> 
> Hi Louis,
> 
> Your idea might be one way of going forward with this but
> I am afraid we loose the big picture. The case is similar
> to the story of TIPC and HA-Linux. The Cluster communication
> req was broken up into multiple requirements so HA-Linux
> would fit one of those sub-reqs while it doesn't meet any
> of the other x sub-reqs, as the gap-analisys study by your
> colleague Yi has shown.
> 
> So breaking the req, from my perspective, is not the ultimate
> solution. It add more fragmentation.
> 
> Before we break the req, it would be great is someone would
> do the gap-analisys of AEM compared to epoll and select, similar
> to the one that was done by Yi Zhu for HA-Linux. It will
> provide a useful information that will be of a lot of
> usefuleness when stating the 2 sub-reqs, because I don't
> personally think that the other refered projects for the req
> have all the potentials AEM has.
> 
> Thanks Louis,
> 
> 	Ibrahim
> 
> 
> > -----Original Message-----
> > From: Zhuang, Louis [mailto:louis.zhuang at intel.com]
> > Sent: Tuesday, July 08, 2003 9:38 PM
> > To: Ibrahim Haddad (QB/LMC); Fan, Ardelle; CGL Specs-sg;
> > Linda Bebernes
> > Subject: RE: [cgl_specs] Proposal to change SCL.1.0 in CGL_Req spec
> >
> >
> > Dear Ibrahim,
> > 	Thanks for your reply. How about splitting the bulk
> > SCL.1.0 into fine-grain requirements if both are
> > requirements? Currently, put-all-goods-in-one-basket makes
> > SCL.1.0 confusing and implementation-dependent. Could we
> > possibly split SCL.1.0 into two parts? For example,
> >
> > SCL.1.0
> > Name: Scalable descriptors support
> > POC: AEM, epoll, AIO etc.
> >
> > SCL.2.0
> > Name: asynchronous mechanism for event processing
> > POC: AEM, AIO etc.
> >
> >   - Louis
> >
> > > -----Original Message-----
> > > From: Ibrahim Haddad (QB/LMC) [mailto:ibrahim.haddad at ericsson.com]
> > > Sent: 2003年7月9日 9:16
> > > To: Zhuang, Louis; Fan, Ardelle; CGL Specs-sg; Linda Bebernes
> > > Subject: RE: [cgl_specs] Proposal to change SCL.1.0 in CGL_Req spec
> > >
> > > Thanks Louis.
> > >
> > > It's actually both + other reqs.
> > >
> > > Check
> > http://aem.sourceforge.net/reports/AEM_cgl_reqts_draft0.6.pdf for
> > > more info + if you have access to the Linux Journal July
> > issue, Frederic
> > > had a nice article on AEM.
> > >
> > > Best,
> > > Ibrahim
> > >
> > > -----Original Message-----
> > > From: Zhuang, Louis [mailto:louis.zhuang at intel.com]
> > > Sent: Tuesday, July 08, 2003 8:56 PM
> > > To: Ibrahim Haddad (QB/LMC); Fan, Ardelle; CGL Specs-sg;
> > Linda Bebernes
> > > Subject: RE: [cgl_specs] Proposal to change SCL.1.0 in CGL_Req spec
> > >
> > >
> > > Dear Ibrahim,
> > > 	Thanks for your URL. Ardelle and I want to know what is the real
> > > requirement -- an asynchronous event mechanism or just
> > scalability in
> > > processing enormous fds.
> > >
> > >   - Louis
> > > > -----Original Message-----
> > > > From: Ibrahim Haddad (QB/LMC) [mailto:ibrahim.haddad at ericsson.com]
> > > > Sent: 2003年7月8日 21:53
> > > > To: Fan, Ardelle; Zhuang, Louis; CGL Specs-sg; Linda Bebernes
> > > > Subject: RE: [cgl_specs] Proposal to change SCL.1.0 in
> > CGL_Req spec
> > > >
> > > > Please check this
> > http://aem.sourceforge.net/reports/aem-faq-draf0.3.pdf
> > > > for better description of how AEM compare to epoll and select.
> > > >
> > > > Ibrahim
> > > >
> > > > > -----Original Message-----
> > > > > From: Fan, Ardelle [mailto:ardelle.fan at intel.com]
> > > > > Sent: Tuesday, July 08, 2003 6:01 AM
> > > > > To: Zhuang, Louis; CGL Specs-sg; Linda Bebernes
> > > > > Subject: RE: [cgl_specs] Proposal to change SCL.1.0 in
> > CGL_Req spec
> > > > >
> > > > >
> > > > > Yes, the current SCL.1.0 is like a description of AEM :P, at
> > > > > least the name gives a direct hint of AEM.
> > > > > Could we clarify the requirement? An asynchronous event
> > > > > programing model/API layer, or the capability to handle large
> > > > > number of simultaneous events. If the user space asynchronous
> > > > > programing model is more important, epoll still has gap, such
> > > > > as a user space library. If the target is events handling,
> > > > > could we change the name and description a bit?
> > > > >
> > > > > 		Ardelle Fan
> > > > > 		Software Engineer,  Intel Corporation
> > > > > 		ardelle.fan at intel.com
> > > > >
> > > > > 		These are my opinions and absolutely not
> > > > > official opinions of Intel Corp.
> > > > >
> > > > > -----Original Message-----
> > > > > From: Zhuang, Louis
> > > > > Sent: 2003?7?8? 17:41
> > > > > To: CGL Specs-sg; Linda Bebernes
> > > > > Subject: [cgl_specs] Proposal to change SCL.1.0 in CGL_Req spec
> > > > >
> > > > >
> > > > > Dear Linda and all,
> > > > > 	AFAIK epoll is not *asynchronous* mechanism. It is a
> > > > > *synchronous* polling mechanism which enhance scalability of
> > > > > traditional select()/poll(). So it seems strange to me that
> > > > > the spec lists epoll as one of POCs.
> > > > > 	IMHO, the real idea behind SCL.1.0 is, linux kernel
> > > > > should be scalable enough to process enormous channels like
> > > > > 100k fds. It might not be important whether the mechanism is
> > > > > asynchronous or not, the choice should be left to
> > implementation.
> > > > > 	According to words above, I'd like to propose to change
> > > > > section SCL.1.0 as following:
> > > > >
> > > > > ID: SCL.1.0
> > > > > Name: Efficient enormous low-level events
> > > > > Description: CGL shall provide an efficient capability for
> > > > > handling a large number of essentially
> > > > > simultaneous events arriving on multiple channels, such as
> > > > > multiple sockets or
> > > > > other similar paths.
> > > > > CGL needs to have an efficient mechanism that provides the
> > > > > Linux kernel with advanced carriergrade
> > > > > capabilities. The motivation of this mechanism is to enforce
> > > > > the system scalability and soft
> > > > > real-time responsiveness by reducing contentions appearing at
> > > > > the kernel level, especially under
> > > > > high load.
> > > > >
> > > > >
> > > > > Yours truly,
> > > > > Louis Zhuang
> > > > > Sr. Software Engineer
> > > > > Intel China Software Lab.
> > > > > -------------------------------
> > > > > iNet:  8752-1327
> > > > > Phone: +(86)-21-52574545 ext.1327
> > > > > Email: louis.zhuang at intel.com
> > > > >        louis.zhuang at acm.org
> > > > > -------------------------------
> > > > > My words are my own, not others
> > > > >
> > > > > _______________________________________________
> > > > > cgl_specs mailing list
> > > > > cgl_specs at lists.osdl.org
> > > > > http://lists.osdl.org/mailman/listinfo/cgl_specs
> > > > >
> > > > > _______________________________________________
> > > > > cgl_specs mailing list
> > > > > cgl_specs at lists.osdl.org
> > > > > http://lists.osdl.org/mailman/listinfo/cgl_specs
> > > > >
> >




More information about the cgl_discussion mailing list