From mboxrd@z Thu Jan 1 00:00:00 1970 From: Diwaker Gupta Subject: understanding network split device drivers Date: Tue, 6 Sep 2005 17:06:45 -0700 Message-ID: <891be94105090617064886ae5a@mail.gmail.com> Reply-To: diwaker.lists@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org I'm trying to understand the architecture for I/O devices (in particular, t= he network drivers) in Xen. I know the broad design and structure of the split devices drivers. The following picture will hopefully make it easier for people to answer my questions: dom-0 dom-1 ------------------------------------ -------------- device driver backend | | frontend =3D=3D> | =3D=3D> | (eg: e1000) (eg: netback)| |(eg: netfront) ------------------------------------ -------------- || =20 \/ =20 (questions!!) I'm not very knowledgeable on the linux networking stack, so bear with me i= f I ask something obvious. o where and how is this pipelining (between the actual device driver and th= e backend) set up in the code?=20 o is it something xen specific, or is it done via standard linux networking= ?=20 o is there some buffer/queue between the backend and the actual device driv= er?=20 o does the backend get any kind of notification from the hardware in case t= he send/recv fails (since IIUC netback queues requests asynchronous processing= ) o where exactly do the bridge utils fit in this picture? TIA Diwaker --=20 Web/Blog/Gallery: http://floatingsun.net