From russell.pavlicek.xen@gmail.com Tue Oct 01 04:17:41 2013 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VQqSz-0004yg-1D (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 01 Oct 2013 04:17:41 +0100 X-Cam-SpamScore: s X-Cam-SpamDetails: score 1.9 from SpamAssassin-3.3.2-1527286 * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (russell.pavlicek.xen[at]gmail.com) * 2.5 SUSPICIOUS_RECIPS Similar addresses in recipient list * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.217.182 listed in list.dnswl.dnsbl.ja.net] * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-lb0-f182.google.com ([209.85.217.182]:55582) by ppsw-32.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp id 1VQqSy-0003EJ-1d (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 01 Oct 2013 04:17:41 +0100 Received: by mail-lb0-f182.google.com with SMTP id c11so5440806lbj.27 for ; Mon, 30 Sep 2013 20:17:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.149.197 with SMTP id uc5mr24610393lbb.19.1380597459825; Mon, 30 Sep 2013 20:17:39 -0700 (PDT) Sender: russell.pavlicek.xen@gmail.com Received: by 10.112.77.103 with HTTP; Mon, 30 Sep 2013 20:17:39 -0700 (PDT) Date: Mon, 30 Sep 2013 23:17:39 -0400 X-Google-Sender-Auth: aAoa__hc1hxzIp1AZIRoZ5BlVso Message-ID: Subject: Thanks to those who contributed to Xen Project Document Day From: Russ Pavlicek To: xen-users@lists.xen.org, xen-devel@lists.xen.org, xs-devel@lists.xenserver.org, cl-mirage@lists.cam.ac.uk, xen-api@lists.xen.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 03:17:41 -0000 Status: RO Content-Length: 522 Lines: 15 Thank you to those who contributed to yesterday's Xen Project Documentation Day. The next Doc day is scheduled for October 28. We hope you can block off some time on that day to pitch in and improve the project documentation. The next Doc Day will follow the Xen Project Developer Summit, so keep your eyes and ears open during the event for possible enhancements which should be made to keep up with the new work that's being done. Hope to see you in #xendocs on October 28! Russell Pavlicek Xen Project Evangelist From scott.dj@gmail.com Tue Oct 01 13:32:02 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VQz7S-0004ci-Fh (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 01 Oct 2013 13:32:02 +0100 X-Cam-SpamDetails: score 0.6 from SpamAssassin-3.3.2-1527487 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.160.42 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (scott.dj[at]gmail.com) * 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is * CUSTOM_MED * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid * 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing * list X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-pb0-f42.google.com ([209.85.160.42]:64337) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with esmtp id 1VQz7R-0005HO-hT (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 01 Oct 2013 13:32:02 +0100 Received: by mail-pb0-f42.google.com with SMTP id un15so7091682pbc.29 for ; Tue, 01 Oct 2013 05:32:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.189.98 with SMTP id gh2mr1771391pbc.181.1380630720386; Tue, 01 Oct 2013 05:32:00 -0700 (PDT) Received: by 10.70.56.36 with HTTP; Tue, 1 Oct 2013 05:32:00 -0700 (PDT) Date: Tue, 1 Oct 2013 13:32:00 +0100 Message-ID: Subject: Mirage weekly call From: David Scott To: Mirage List Content-Type: multipart/alternative; boundary=e89a8ff1c4eea7a05d04e7ad23f2 X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 12:32:02 -0000 Status: RO Content-Length: 1695 Lines: 46 --e89a8ff1c4eea7a05d04e7ad23f2 Content-Type: text/plain; charset=ISO-8859-1 Fellow Mirage hackers, as we are approaching our 1.0 deadline, please join me on the Mirage weekly call today (tuesday) at 4pm BST! 1. Please join my meeting. https://www1.gotomeeting.com/join/591890401 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. United Kingdom (toll-free): 0 808 168 0209 United Kingdom: +44 (0) 207 151 1817 United States (toll-free): 1 877 309 2070 United States: +1 (626) 521-0017 Access Code: 591-890-401 Audio PIN: Shown after joining the meeting Meeting ID: 591-890-401 -- Dave Scott --e89a8ff1c4eea7a05d04e7ad23f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Fellow Mirage hackers, as we are approaching our 1.0 = deadline, please join me on the Mirage weekly call today (tuesday) at 4pm B= ST!

1. =A0Please join my meeting.

2. =A0Use your microphone and speakers (VoIP) - a heads= et is recommended. =A0Or, call in using your telephone.

United Kingdom (toll-free): 0 808 168 0209 United Kingdom: +44 (0) 20= 7 151 1817

United States (toll-free): 1 877 309 2070 United States= : +1 (626) 521-0017

Access Code: 591-890-401
=
Audio PIN: Shown after joining the meeting

Meeting ID: 591-890-401

--
Dave Scott
--e89a8ff1c4eea7a05d04e7ad23f2-- From amc79@cam.ac.uk Tue Oct 01 15:54:40 2013 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VR1LU-0004YE-9X (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 01 Oct 2013 15:54:40 +0100 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from dhcp-172-17-158-67.eduroam.lapwing.private.cam.ac.uk ([172.17.158.67]:52051) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:amc79) (TLSv1:AES128-SHA:128) id 1VR1LU-0002Iq-0m (Exim 4.80_167-5a66dd3) (return-path ); Tue, 01 Oct 2013 15:54:40 +0100 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-A466AD32-E31E-4DCC-AB84-23A211A32BBA Content-Transfer-Encoding: 7bit Message-Id: <44FEC5AA-1F24-4BF8-8590-9E286687A6BB@cam.ac.uk> X-Mailer: iPhone Mail (11A465) From: Amir Chaudhry Subject: Re: Mirage weekly call Date: Tue, 1 Oct 2013 15:54:40 +0100 To: David Scott Cc: Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 14:54:40 -0000 Status: RO Content-Length: 2409 Lines: 52 --Apple-Mail-A466AD32-E31E-4DCC-AB84-23A211A32BBA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Will be there but joining late.=20 Best wishes, Amir -- sent via mobile > On 1 Oct 2013, at 13:32, David Scott wrote: >=20 > Fellow Mirage hackers, as we are approaching our 1.0 deadline, please join= me on the Mirage weekly call today (tuesday) at 4pm BST! >=20 > 1. Please join my meeting. > https://www1.gotomeeting.com/join/591890401 >=20 > 2. Use your microphone and speakers (VoIP) - a headset is recommended. O= r, call in using your telephone. >=20 > United Kingdom (toll-free): 0 808 168 0209 United Kingdom: +44 (0) 207 151= 1817 >=20 > United States (toll-free): 1 877 309 2070 United States: +1 (626) 521-0017= >=20 > Access Code: 591-890-401 > Audio PIN: Shown after joining the meeting >=20 > Meeting ID: 591-890-401 >=20 > --=20 > Dave Scott --Apple-Mail-A466AD32-E31E-4DCC-AB84-23A211A32BBA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Will be there but joining late. 

Best wishes,
Amir

--
sent via mobile

On 1 Oct 2013, at 13:32, David Scott <scott.dj@gmail.com> wrote:

Fellow Mirage hackers, as we are approaching our 1.0 deadline, please join me on the Mirage weekly call today (tuesday) at 4pm BST!

1.  Please join my meeting.

2.  Use your microphone and speakers (VoIP) - a headset is recommended.  Or, call in using your telephone.

United Kingdom (toll-free): 0 808 168 0209 United Kingdom: +44 (0) 207 151 1817

United States (toll-free): 1 877 309 2070 United States: +1 (626) 521-0017

Access Code: 591-890-401
Audio PIN: Shown after joining the meeting

Meeting ID: 591-890-401

--
Dave Scott
--Apple-Mail-A466AD32-E31E-4DCC-AB84-23A211A32BBA-- From anil@recoil.org Tue Oct 01 23:19:07 2013 Received: from ppsw-mx-f.csi.cam.ac.uk ([131.111.8.149] helo=ppsw-42.csi.cam.ac.uk) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VR8Hb-00005I-1g (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 01 Oct 2013 23:19:07 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1527487 X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:31952 helo=dark.recoil.org) by ppsw-42.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with smtp id 1VR8Ha-0003UE-7p (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 01 Oct 2013 23:19:06 +0100 Received: (qmail 2711 invoked by uid 634); 1 Oct 2013 22:19:06 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from cpc7-cmbg14-2-0-cust238.5-4.cable.virginmedia.com (HELO [192.168.1.62]) (86.30.244.239) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Tue, 01 Oct 2013 23:19:04 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) Subject: Re: Travis and OCaml, and even ARM From: Anil Madhavapeddy In-Reply-To: <43EF2528-2F11-46F6-8E08-2180C6742508@recoil.org> Date: Tue, 1 Oct 2013 23:19:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <567B1520-20C5-4C0D-B650-FF06EECDC790@recoil.org> References: <43EF2528-2F11-46F6-8E08-2180C6742508@recoil.org> To: "cl-mirage@lists.cam.ac.uk List" X-Mailer: Apple Mail (2.1811) X-Virus-Checked: Checked by ClamAV on dark.recoil.org X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 22:19:07 -0000 Status: RO Content-Length: 1800 Lines: 43 We mentioned on the call today that Travis might not be able to build = the Xen backend since it's an i386 VM, but it does work fine (since we = don't actually use any system libraries in the build) https://travis-ci.org/mirage/mirage-www/jobs/11897190 So we can use Travis for a publishing platform too... -anil On 30 Sep 2013, at 17:04, Anil Madhavapeddy wrote: > Good news everyone! I just had an exciting build failure that I wanted = to share with you. >=20 > Dave and I have been switching a number of our OCaml GitHub = repositories to use Travis continuous integration testing. This is good = enough for any tests that can run in an Ubuntu/i386 VM without hosting = any infrastructure ourselves. Details here: > http://anil.recoil.org/2013/09/30/travis-and-ocaml.html >=20 > If you look at the bottom there, I used Ian Campbell's foreign-chroot = instructions to get OCaml/ARM working too. I've been activating this on = various Mirage repositories to test our builds on ARM without having to = have a box available, and so this is making it much easier to reproduce = bugs such as this shared-memory-ring failure: > https://github.com/djs55/shared-memory-ring/issues/6 > ...just via this Travis log: > https://travis-ci.org/mirage/mirage-platform/jobs/11964317 >=20 > Now we just have to fix it, but that's pretty easy right? :-) >=20 > Are there any brave souls out there that might try to figure out how = to get a Xen environment working from within Travis? It would only need = to boot Mirage kernels, so it's ok to be a bit slow... >=20 > (I expect to finish the conversion of all the Mirage release = repositories to Travis this week, and it would be great to see XAPI = repos like xenopsd also activated, which I believe Dave is working on). >=20 > -anil From avsm@dark.recoil.org Fri Oct 04 10:57:13 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VS28H-0001y3-4Y (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 10:57:13 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1528751 X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:28064 helo=dark.recoil.org) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp id 1VS28F-0003Fh-ij (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 10:57:13 +0100 Received: (qmail 12084 invoked by uid 10000); 4 Oct 2013 09:57:11 -0000 Date: Fri, 4 Oct 2013 10:57:11 +0100 From: Anil Madhavapeddy To: Dimosthenis Pediaditakis Subject: Re: Improving the network-stack performance over Xen Message-ID: <20131004095711.GI14429@dark.recoil.org> References: <5233969C.1080802@cl.cam.ac.uk> <5240EC98.3060509@cl.cam.ac.uk> <5241AFF2.5070001@cl.cam.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5241AFF2.5070001@cl.cam.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Mirage List , David Scott X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 09:57:13 -0000 Status: RO Content-Length: 15910 Lines: 371 Closing the loop on this; is Dave's Activations patch considered safe-to-merge now? -anil On Tue, Sep 24, 2013 at 04:29:54PM +0100, Dimosthenis Pediaditakis wrote: > Hi again, > as promised, here are some data from a DomU-2-DomU iperf flow, > pushing 0.8Gbits in 0.38sec (~2.1Gbps): > http://www.cl.cam.ac.uk/~dp463/files/mirageNetData.tar.gz > > Note that I've used a txqueuelen of 500 for each VIF in dom0. > Also, with TCP debug disabled, speeds reach >= 2.5Gbps. > > Everythin seems smoother. Didn't observe any odd TX delay spikes > caused by netif blocking. > > Regards, > D. > > > > On 24/09/13 02:36, Dimosthenis Pediaditakis wrote: > >Hi David, > >sorry for the absence. I attended a Workshop on SDN last week, and > >today was quite a busy day. > >I had a look in the interrupt branch of your mirage-platform repo, > >cloned it and ran a few experiments. > >The speeds I got were consistently between 2.45-2.6Gbps on my > >machine (i7-3770, dual ch. DDR3 1600), which is a very good > >number. > >Unfortunatelly, I didn't have the time to further stress test it > >and generate any TCP stack plots. This is the top item in my TODO > >list. > > > >I also went briefly through the additions/modifications in > >hypervisor.c, main.c, activations.ml, netif.ml, main.ml > >It seems that SCHEDOP_block + no-op handling + evtchn_poll + > >VIRQ_TIMER-bind along with the rewriting of Activations (fix for > >the silently dropped events) have done the trick. > > > >A couple of questions: > > - In file hypervisor.c, what is the purpose of " > >force_evtchn_callback" ? I've seen it only being invoked via > >"__sti()" and "__restore_flags()" > > > > - In the updated design, when an event is received, then: > > SCHEDOP_block returns, > > event_poll is then invoked, and > > finally Main.aux() is called. > > Activations.run() is invoked in Main.aux() if no threads are > >scheduled, and subsequently the domain is blocked again (until a > >timer interrupt, or reception of another event). My question is > >why don't we re-check right after "Activations.run()" the state of > >t ? For example if packets are waiting to be sent, and netif gets > >unblocked, why we block the domain directly again? > > > >Also, thanks thanks for the credits in you updates :-) > > > >D. > > > > > > > >On 19/09/13 22:41, David Scott wrote: > >>Hi Dimos, > >> > >>I've created a new patch set based on a mix of your ideas and mine: > >> > >>https://github.com/mirage/mirage-platform/pull/58 > >> > >>I've proposed switching to SCHEDOP_block with interrupts > >>enabled. Unlike in regular Mini-OS I don't think we need to do > >>anything in the hypervisor_callback, because we already have > >>code to poll the evtchn pending bits in evtchn_poll-- so we're a > >>bit of a hybrid: interrupts on for wakeups but the whole OS is > >>still based around a select/poll-style loop. I've left all event > >>channels unmasked and used the event_upcall_mask to turn on/off > >>event delivery globally. I've revamped the OCaml Activations > >>interface to remove one source of missing events. > >> > >>So far the code is working ok in my testing. I ran mirage-iperf > >>and am getting 1642002 KBit/sec on my test hardware -- I don't > >>know if this is considered good or bad! I ran your instrumented > >>version (thanks for the exhaustive instructions btw) and it drew > >>some pretty graphs, but I'm not enough of a TCP expert to > >>interpret them properly. > >> > >>Could you give this a go in your test environment and let me > >>know what you think? > >> > >>I'm extremely suspicious of the console code -- it shouldn't be > >>necessary to include a delay in the print loop; that's > >>definitely worth investigating. > >> > >>Cheers, > >>Dave > >> > >> > >>On Thu, Sep 19, 2013 at 11:02 AM, David Scott > >>> wrote: > >> > >> Hi Dimos, > >> > >> Thanks for looking into this! Thinking about it, I think we have > >> several problems. > >> > >> 1. I think the Activations.wait API is difficult to use / unsafe: > >> > >> (* Block waiting for an event to occur on a particular port *) > >> let wait evtchn = > >> if Eventchn.is_valid evtchn then begin > >> let port = Eventchn.to_int evtchn in > >> let th, u = Lwt.task () in > >> let node = Lwt_sequence.add_l u event_cb.(port) in > >> Lwt.on_cancel th (fun _ -> Lwt_sequence.remove node); > >> th > >> end else Lwt.fail Generation.Invalid > >> > >> When you call Activations.wait you are added to a 'sequence' > >> (like a list) of people to wake up when the next event occurs. A > >> typical driver would call Activations.wait in a loop, block for > >> an event, wake up, signal some other thread to do work and then > >> block again. However if the thread running the loop blocks > >> anywhere else, then the thread will not be added to the sequence > >> straight away and any notifications that arrive during the gap > >> will be dropped. I noticed this when debugging my block backend > >> implementation. I think netif has this problem: > >> > >> let listen nf fn = > >> (* Listen for the activation to poll the interface *) > >> let rec poll_t t = > >> lwt () = refill_requests t in > >> ^^^ blocks here, can miss events > >> > >> rx_poll t fn; > >> tx_poll t; > >> (* Evtchn.notify nf.t.evtchn; *) > >> lwt new_t = > >> try_lwt > >> Activations.wait t.evtchn >> return t > >> with > >> | Generation.Invalid -> > >> Console.log_s "Waiting for plug in listen" >> > >> wait_for_plug nf >> > >> Console.log_s "Done..." >> > >> return nf.t > >> in poll_t new_t > >> in > >> poll_t nf.t > >> > >> > >> I think we should change the semantics of Activations.wait to be > >> more level-triggered rather than edge-triggered (i.e. more like > >> the underlying behaviour of xen) like this: > >> > >> type event > >> (** a particular event *) > >> > >> val wait: Evtchn.t -> event option -> event Lwt.t > >> (** [wait evtchn None] returns [Some e] where [e] is the latest > >> event. > >> [wait evtchn (Some e)] returns [Some e'] where [e'] is a > >> later event than [e] *) > >> > >> In the implementation we could have "type event = int" and > >> maintain a counter of "number of times this event has been > >> signalled". When you call Activations.wait, you would pass in the > >> number of the last event you saw, and the thread would block > >> until a new event is available. This way you wouldn't have to be > >> registered in the table when the event arrives. > >> > >> 2. SCHEDOP_poll has a low (arbitrary) nr_ports limit > >> > >> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/common/schedule.c;h=a8398bd9ed4827564bed4346e1fdfbb98ec5907e;hb=c5e9596cd095e3b96a090002d9e6629a980904eb#l712 > >> > >> 704 static long do_poll(struct sched_poll *sched_poll) > >> 705 { > >> 706 struct vcpu *v = current; > >> 707 struct domain *d = v->domain; > >> 708 evtchn_port_t port; > >> 709 long rc; > >> 710 unsigned int i; > >> 711 > >> 712 /* Fairly arbitrary limit. */ > >> 713 if ( sched_poll->nr_ports > 128 ) > >> 714 return -EINVAL; > >> > >> The total number of available event channels for a 64-bit guest > >> is 4096 using the current ABI (a new interface is under > >> development which allows even more). The limit of 128 is probably > >> imposed to limit the amount of time the hypercall takes, to avoid > >> hitting scalability limits like you do in userspace with select(). > >> > >> One of the use-cases I'd like to use Mirage for is to run backend > >> services (like xenstore or blkback) for all the domains on a > >> host. This requires at least one event channel per client domain. > >> We routinely run ~300 VMs/host, so the 128 limit is too small. > >> Plus a quick grep around Linux shows that it doesn't use > >> SCHEDOP_poll very much-- I think we should focus on using the > >> hypercalls that other OSes are using, for maximum chance of success. > >> > >> So I think we should switch from select()-like behaviour using > >> SCHEDOP_poll to interrupt-based delivery using SCHEDOP_block. I > >> note that upstream mini-os does this by default too. I'll take a > >> look at this. > >> > >> Cheers, > >> Dave > >> > >> > >> > >> On Fri, Sep 13, 2013 at 11:50 PM, Dimosthenis Pediaditakis > >> >> > wrote: > >> > >> Hi all, > >> The last few days I've been trying to pin-down the > >> performance issues of the Mirage network stack, when running > >> over Xen. > >> When trying to push net-direct to its limits, random > >> transmissions stall for anywhere between 0.1sec-4sec > >> (especially at the sender). > >> > >> After some experimentation, I believe that those time-outs > >> occur because netif is not (always) notified (via > >> Activations) about freed TX-ring slots. > >> It seems that these events (intermittently) don't reach the > >> guest domain's front-end driver. > >> > >> AFAIK Activations.wait() currently blocks waiting for an > >> event on the port belonging to the event channel for the netif. > >> This event is delivered to Activations.run via Main.run.aux > >> which is invoked via the callback in app_main() of > >> runtime/kernel/main.c > >> The problem I observed was that using "SCHEDOP_poll" without > >> masking the intended events, the hypervisor didn't "wake-up" > >> the blocked domain upon new event availability. > >> The requirement for event-masking when using "SCHEDOP_poll" > >> is also mentioned in the Xen documentation. > >> > >> I've produced a patch that seems to fix the above erratic > >> behavior. > >> Now I am able to consistently achieve higher speeds (up to > >> 2.75Gbps DomU2Domu). Please, have a look at my repo: > >> https://github.com/dimosped/mirage-platform > >> It will be helpful to use big-enough txqueuelen values for > >> your VIFs, as the current TCP implementation doesn't like > >> much losses at high datarates. The default size in my system > >> was only 32. > >> > >> I have also modified the mirage-net-direct by adding per-flow > >> TCP debug logging. This has helped me to better understand > >> and pin-down the problem. > >> You can grab the modified sources here: > >> https://github.com/dimosped/mirage-net > >> Be aware that logging big volumes of data for a TCP flow will > >> require big enough memory. Nevertheless, it only barely > >> affects performance. > >> > >> The iperf benchmark sources can be found here: > >> https://github.com/dimosped/iperf-mirage > >> I've included as much info as possible in the README file. > >> This should be sufficient to get you started and replicate my > >> experiments. > >> > >> In the iperf-mirage repo there is also a Python tool, which > >> you can use to automatically generate plots based on the > >> collected TCP debug info (I include also a sample dataset in > >> data/ ): > >> https://github.com/dimosped/iperf-mirage/tree/master/tools/MirageTcpVis > >> For really large datasets, the script might be slow. I need > >> to switch into using NumPy arrays at some point... > >> > >> Please keep in mind that I am a newbie in Xen/Mirage so your > >> comments/input are more than welcome. > >> > >> Regards, > >> Dimos > >> > >> > >> > >> > >> ------------------------------------------------ > >> MORE TECHNICAL DETAILS > >> ------------------------------------------------ > >> > >> > >> ----------------------------------------------------------------- > >> > >> === How (I think) Mirage and XEN scheduling works === > >> ----------------------------------------------------------------- > >> > >> - When Netif receives a writev request, it checks if the TX > >> ring has enough empty space (for the producer) for the data > >> - If there is not enough space, it block-waits (via > >> Activations.wait) for an event on the port mapped to the > >> netif (and bound to the backend driver) > >> - Otherwise it pushes the request. > >> - Activations are notified (via run) from "aux ()" in > >> Main.run. Once notified, it means that the waiting netif can > >> proceed, check again the ring for free space, write a new > >> request, and send an event to the backend. > >> - Main.run.aux is registered as a callback (under name > >> "OS.Main.run") and is invoked in xen/runtime/kernel/main.c > >> (in app_main() loop). As long as the Mirage guest domain is > >> scheduled, this loop keeps running. > >> - However, in Main.run.aux, the Mirage guest domain is > >> blocked via "block_domain timeout" if the main thread has no > >> task to perform. > >> - In turn, "block_domain" invokes caml_block_domain() found > >> in xen/runtime/kernel/main.c, which issues a > >> "HYPERVISOR_sched_op(SCHEDOP_poll, &sched_poll);" hypercall > >> > >> ------------------------------------- > >> === Polling mode issue === > >> ------------------------------------- > >> In my opinion, and based on debug information, it seems that > >> the problem is that Mirage uses "SCHEDOP_poll" without > >> masking the event channels. > >> The XEN documentation clearly states that with "SCHEDOP_poll" > >> the domain would yield until either > >> a) an event is pending on the polled channels and > >> b) the timeout time (given in nanoseconds, is not duration > >> but absolute system time) is reached > >> It also states that this SCHEDOP_poll can only be be executed > >> when the guest has delivery of events disabled. > >> > >> In Mirage, netif events are not masked and therefore they > >> never "wakeup" the guest domain. > >> The guest only wakes-up whenever a thread is scheduled > >>to wakeup in Time.SleepQueue (e.g. a TCP timer). > >> Once the guest is scheduled again, it completes any > >> outstanding tasks, sends any packets pending, and whenever a) > >> the TX ring gets full, or b)the hypervisor it, c) it will > >> sleep again. > >> To further support the above, whenever I press buttons via > >> XEN-console while the mirage-sender is running, the execution > >> completes faster. > >> > >> ---------------- > >> === Fix === > >> ---------------- > >> There are multiple ways to mask events (e.g. at VCPU level, > >> event level etc). > >> As a quick hack I replaced "Eventchn.unmask h evtchn;" in > >> Netif.plug_inner with Eventchn.mask h evtchn (which I had to > >> create, both in Eventchn and as a stub in > >> xen/runtime/kernel/eventchn_stubs.c). > >> See: > >> https://github.com/dimosped/mirage-platform/commit/6d4d3f0403497f07fde4db6f4cb63665a8bf8e26 > >> > >> > >> > >> > >> > >> > >> > >> > >> -- Dave Scott > >> > >> > >> > >> > >>-- > >>Dave Scott > > > -- Anil Madhavapeddy http://anil.recoil.org From anil@recoil.org Fri Oct 04 11:08:31 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VS2JD-0002Vr-RA (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 11:08:31 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1528751 X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:41987 helo=dark.recoil.org) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp id 1VS2JD-0000ZG-gi (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 11:08:31 +0100 Received: (qmail 18318 invoked by uid 634); 4 Oct 2013 10:08:31 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from host81-149-102-120.in-addr.btopenworld.com (HELO flick.home) (81.149.102.120) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Fri, 04 Oct 2013 11:08:30 +0100 From: Anil Madhavapeddy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Using Merlin from Vim Date: Fri, 4 Oct 2013 11:08:29 +0100 Message-Id: To: "cl-mirage@lists.cam.ac.uk List" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) X-Mailer: Apple Mail (2.1811) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: OCaml Labs X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 10:08:31 -0000 Status: RO Content-Length: 447 Lines: 14 I finally got around to installing the Merlin OCaml editor add-on, and = it gives amazing features such as type display, module completion and = support for hopping around projects. See my little Vim-Merlin from = scratch here: http://anil.recoil.org/2013/10/03/merlin-and-vim.html I suspect we'll need some more .merlin files in the various repos, so = I'll add those as I go along. Has anyone else been using Merlin (e.g. = on Emacs?) -a From Richard.Mortier@nottingham.ac.uk Fri Oct 04 11:11:41 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VS2MH-0002p8-Rf (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 11:11:41 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1528751 * 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from engine03-20433-3.icritical.com ([93.95.15.170]:43721) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp id 1VS2MG-0002Fb-hp (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 11:11:41 +0100 Received: (qmail 6307 invoked from network); 4 Oct 2013 10:11:34 -0000 Received: from localhost (127.0.0.1) by engine03-20433-3.icritical.com with SMTP; 4 Oct 2013 10:11:34 -0000 Received: from engine03-20433-3.icritical.com ([127.0.0.1]) by localhost (engine03-20433-3.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 05982-08 for ; Fri, 4 Oct 2013 11:11:33 +0100 (BST) Received: (qmail 6284 invoked by uid 599); 4 Oct 2013 10:11:33 -0000 Received: from unknown (HELO smtp4.nottingham.ac.uk) (128.243.220.65) by engine03-20433-3.icritical.com (qpsmtpd/0.28) with ESMTP; Fri, 04 Oct 2013 11:11:33 +0100 Received: from uiwexhub01.ad.nottingham.ac.uk ([128.243.15.133]) by smtp4.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1VS2MD-0004uL-Q3; Fri, 04 Oct 2013 11:11:37 +0100 From: Richard Mortier To: Anil Madhavapeddy Date: Fri, 4 Oct 2013 11:11:36 +0100 Subject: Re: Using Merlin from Vim Thread-Topic: Using Merlin from Vim Thread-Index: Ac7A6hxE4prLkCqES/CI3eLd5i7GYw== Message-ID: <4FD883E8-F81B-40B5-8017-6F2CDFA35097@nottingham.ac.uk> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: by iCritical at engine03-20433-3.icritical.com Cc: OCaml Labs , "cl-mirage@lists.cam.ac.uk List" X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 10:11:41 -0000 Status: RO Content-Length: 1523 Lines: 37 On 4 Oct 2013, at 11:08, Anil Madhavapeddy wrote: > http://anil.recoil.org/2013/10/03/merlin-and-vim.html >=20 > I suspect we'll need some more .merlin files in the various repos, so I'l= l add those as I go along. Has anyone else been using Merlin (e.g. on Emac= s?) i've been trying (not that i've managed to actually look at code much in th= e last couple of weeks :/ found it a little flaky tbh - the indentation and type inference features (= probably what i care most about) kind-of worked but had some odd corner cas= es; and the merlin-mode seemed to do something that meant i had to try to c= lose a file twice before it would actually close. i think there might've been an update since though which i've not had a cha= nce to try yet. --=20 Cheers, R. This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From anil@recoil.org Fri Oct 04 11:16:20 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VS2Qm-00030x-LG (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 11:16:20 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1528751 X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:1114 helo=dark.recoil.org) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp id 1VS2Ql-00044t-h5 (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 11:16:20 +0100 Received: (qmail 22397 invoked by uid 634); 4 Oct 2013 10:16:19 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from host81-149-102-120.in-addr.btopenworld.com (HELO flick.home) (81.149.102.120) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Fri, 04 Oct 2013 11:16:18 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) Subject: Re: Using Merlin from Vim From: Anil Madhavapeddy In-Reply-To: <4FD883E8-F81B-40B5-8017-6F2CDFA35097@nottingham.ac.uk> Date: Fri, 4 Oct 2013 11:16:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <23017056-1594-4B8A-B448-D1ACFC9AC523@recoil.org> References: <4FD883E8-F81B-40B5-8017-6F2CDFA35097@nottingham.ac.uk> To: Richard Mortier X-Mailer: Apple Mail (2.1811) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: OCaml Labs , "cl-mirage@lists.cam.ac.uk List" X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 10:16:20 -0000 Status: RO Content-Length: 1037 Lines: 30 On 4 Oct 2013, at 11:11, Richard Mortier = wrote: >=20 > On 4 Oct 2013, at 11:08, Anil Madhavapeddy wrote: >=20 >> http://anil.recoil.org/2013/10/03/merlin-and-vim.html >>=20 >> I suspect we'll need some more .merlin files in the various repos, so = I'll add those as I go along. Has anyone else been using Merlin (e.g. = on Emacs?) >=20 > i've been trying (not that i've managed to actually look at code much = in the last couple of weeks :/ >=20 > found it a little flaky tbh - the indentation and type inference = features (probably what i care most about) kind-of worked but had some = odd corner cases; and the merlin-mode seemed to do something that meant = i had to try to close a file twice before it would actually close. it's worth reporting these corner cases, as it features fairly = sophisticated partial typing to work with broken files. =20 the recent update has indeed made it vastly more stable, so worth = revisiting. I'm very impressed with it on Vim (and soon, Acme!) -anil From Richard.Mortier@nottingham.ac.uk Fri Oct 04 11:23:29 2013 Received: from ppsw-mx-f.csi.cam.ac.uk ([131.111.8.149] helo=ppsw-42.csi.cam.ac.uk) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VS2Xg-0003MR-VW (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 11:23:28 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1528751 * 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from engine04-20433-4.icritical.com ([195.62.217.152]:54495) by ppsw-42.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with smtp id 1VS2Xf-0000ma-9f (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 11:23:28 +0100 Received: (qmail 23197 invoked from network); 4 Oct 2013 10:23:23 -0000 Received: from localhost (127.0.0.1) by engine04-20433-4.icritical.com with SMTP; 4 Oct 2013 10:23:23 -0000 Received: from engine04-20433-4.icritical.com ([127.0.0.1]) by localhost (engine04-20433-4.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 22747-08 for ; Fri, 4 Oct 2013 11:23:22 +0100 (BST) Received: (qmail 19662 invoked by uid 599); 4 Oct 2013 10:18:47 -0000 Received: from unknown (HELO smtp3.nottingham.ac.uk) (128.243.44.55) by engine04-20433-4.icritical.com (qpsmtpd/0.28) with ESMTP; Fri, 04 Oct 2013 11:18:47 +0100 Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp3.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1VS2TC-0004uS-Pd; Fri, 04 Oct 2013 11:18:50 +0100 From: Richard Mortier To: Anil Madhavapeddy Date: Fri, 4 Oct 2013 11:18:49 +0100 Subject: Re: Using Merlin from Vim Thread-Topic: Using Merlin from Vim Thread-Index: Ac7A6x4OCFsRVCXDR5+1ICwxcBgTGg== Message-ID: References: <4FD883E8-F81B-40B5-8017-6F2CDFA35097@nottingham.ac.uk> <23017056-1594-4B8A-B448-D1ACFC9AC523@recoil.org> In-Reply-To: <23017056-1594-4B8A-B448-D1ACFC9AC523@recoil.org> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: by iCritical at engine04-20433-4.icritical.com Cc: OCaml Labs , "cl-mirage@lists.cam.ac.uk List" X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 10:23:29 -0000 Status: RO Content-Length: 1328 Lines: 33 On 4 Oct 2013, at 11:16, Anil Madhavapeddy wrote: > it's worth reporting these corner cases, as it features fairly sophistica= ted partial typing to work with broken files. =20 yup, that was one of the massively useful sounding features that made me tr= y it :) (plus proper support for lwt syntax...) > the recent update has indeed made it vastly more stable, so worth revisit= ing. I'm very impressed with it on Vim (and soon, Acme!) ok, will definitely do that then. it certainly seems likely to be the right= thing to do "going forwards"... :) --=20 Cheers, R. This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From Richard.Mortier@nottingham.ac.uk Fri Oct 04 11:29:06 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VS2d8-0003eb-8n (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 11:29:06 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1528751 * 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from engine04-20433-4.icritical.com ([195.62.217.152]:57124) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp id 1VS2d7-0001WM-iv (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 11:29:06 +0100 Received: (qmail 26761 invoked from network); 4 Oct 2013 10:28:54 -0000 Received: from localhost (127.0.0.1) by engine04-20433-4.icritical.com with SMTP; 4 Oct 2013 10:28:54 -0000 Received: from engine04-20433-4.icritical.com ([127.0.0.1]) by localhost (engine04-20433-4.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 26599-07 for ; Fri, 4 Oct 2013 11:28:53 +0100 (BST) Received: (qmail 23051 invoked by uid 599); 4 Oct 2013 10:23:15 -0000 Received: from unknown (HELO smtp3.nottingham.ac.uk) (128.243.44.55) by engine04-20433-4.icritical.com (qpsmtpd/0.28) with ESMTP; Fri, 04 Oct 2013 11:23:15 +0100 Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp3.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1VS2TC-0004uS-Pd; Fri, 04 Oct 2013 11:18:50 +0100 From: Richard Mortier To: Anil Madhavapeddy Date: Fri, 4 Oct 2013 11:18:49 +0100 Subject: Re: Using Merlin from Vim Thread-Topic: Using Merlin from Vim Thread-Index: Ac7A6x4OCFsRVCXDR5+1ICwxcBgTGg== Message-ID: References: <4FD883E8-F81B-40B5-8017-6F2CDFA35097@nottingham.ac.uk> <23017056-1594-4B8A-B448-D1ACFC9AC523@recoil.org> In-Reply-To: <23017056-1594-4B8A-B448-D1ACFC9AC523@recoil.org> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: by iCritical at engine04-20433-4.icritical.com Cc: OCaml Labs , "cl-mirage@lists.cam.ac.uk List" X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 10:29:06 -0000 Status: RO Content-Length: 1328 Lines: 33 On 4 Oct 2013, at 11:16, Anil Madhavapeddy wrote: > it's worth reporting these corner cases, as it features fairly sophistica= ted partial typing to work with broken files. =20 yup, that was one of the massively useful sounding features that made me tr= y it :) (plus proper support for lwt syntax...) > the recent update has indeed made it vastly more stable, so worth revisit= ing. I'm very impressed with it on Vim (and soon, Acme!) ok, will definitely do that then. it certainly seems likely to be the right= thing to do "going forwards"... :) --=20 Cheers, R. This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From dp463@hermes.cam.ac.uk Fri Oct 04 12:08:01 2013 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VS3En-0006EB-B9 (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 12:08:01 +0100 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cosmic.cl.cam.ac.uk ([128.232.10.197]:40874 helo=localhost) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:dp463) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1VS3En-0001qp-DU (Exim 4.80_167-5a66dd3) (return-path ); Fri, 04 Oct 2013 12:08:01 +0100 Message-ID: <524EA18D.2090609@cl.cam.ac.uk> Date: Fri, 04 Oct 2013 12:07:57 +0100 From: Dimosthenis Pediaditakis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Anil Madhavapeddy Subject: Re: Improving the network-stack performance over Xen References: <5233969C.1080802@cl.cam.ac.uk> <5240EC98.3060509@cl.cam.ac.uk> <5241AFF2.5070001@cl.cam.ac.uk> <20131004095711.GI14429@dark.recoil.org> In-Reply-To: <20131004095711.GI14429@dark.recoil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: "D. Pediaditakis" Cc: Mirage List , David Scott X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 11:08:01 -0000 Status: RO Content-Length: 16287 Lines: 373 As far as Network stack performance, domain scheduling and console operation goes, I haven't observed any issues so far. D. On 04/10/13 10:57, Anil Madhavapeddy wrote: > Closing the loop on this; is Dave's Activations patch considered > safe-to-merge now? > > -anil > > On Tue, Sep 24, 2013 at 04:29:54PM +0100, Dimosthenis Pediaditakis wrote: >> Hi again, >> as promised, here are some data from a DomU-2-DomU iperf flow, >> pushing 0.8Gbits in 0.38sec (~2.1Gbps): >> http://www.cl.cam.ac.uk/~dp463/files/mirageNetData.tar.gz >> >> Note that I've used a txqueuelen of 500 for each VIF in dom0. >> Also, with TCP debug disabled, speeds reach >= 2.5Gbps. >> >> Everythin seems smoother. Didn't observe any odd TX delay spikes >> caused by netif blocking. >> >> Regards, >> D. >> >> >> >> On 24/09/13 02:36, Dimosthenis Pediaditakis wrote: >>> Hi David, >>> sorry for the absence. I attended a Workshop on SDN last week, and >>> today was quite a busy day. >>> I had a look in the interrupt branch of your mirage-platform repo, >>> cloned it and ran a few experiments. >>> The speeds I got were consistently between 2.45-2.6Gbps on my >>> machine (i7-3770, dual ch. DDR3 1600), which is a very good >>> number. >>> Unfortunatelly, I didn't have the time to further stress test it >>> and generate any TCP stack plots. This is the top item in my TODO >>> list. >>> >>> I also went briefly through the additions/modifications in >>> hypervisor.c, main.c, activations.ml, netif.ml, main.ml >>> It seems that SCHEDOP_block + no-op handling + evtchn_poll + >>> VIRQ_TIMER-bind along with the rewriting of Activations (fix for >>> the silently dropped events) have done the trick. >>> >>> A couple of questions: >>> - In file hypervisor.c, what is the purpose of " >>> force_evtchn_callback" ? I've seen it only being invoked via >>> "__sti()" and "__restore_flags()" >>> >>> - In the updated design, when an event is received, then: >>> SCHEDOP_block returns, >>> event_poll is then invoked, and >>> finally Main.aux() is called. >>> Activations.run() is invoked in Main.aux() if no threads are >>> scheduled, and subsequently the domain is blocked again (until a >>> timer interrupt, or reception of another event). My question is >>> why don't we re-check right after "Activations.run()" the state of >>> t ? For example if packets are waiting to be sent, and netif gets >>> unblocked, why we block the domain directly again? >>> >>> Also, thanks thanks for the credits in you updates :-) >>> >>> D. >>> >>> >>> >>> On 19/09/13 22:41, David Scott wrote: >>>> Hi Dimos, >>>> >>>> I've created a new patch set based on a mix of your ideas and mine: >>>> >>>> https://github.com/mirage/mirage-platform/pull/58 >>>> >>>> I've proposed switching to SCHEDOP_block with interrupts >>>> enabled. Unlike in regular Mini-OS I don't think we need to do >>>> anything in the hypervisor_callback, because we already have >>>> code to poll the evtchn pending bits in evtchn_poll-- so we're a >>>> bit of a hybrid: interrupts on for wakeups but the whole OS is >>>> still based around a select/poll-style loop. I've left all event >>>> channels unmasked and used the event_upcall_mask to turn on/off >>>> event delivery globally. I've revamped the OCaml Activations >>>> interface to remove one source of missing events. >>>> >>>> So far the code is working ok in my testing. I ran mirage-iperf >>>> and am getting 1642002 KBit/sec on my test hardware -- I don't >>>> know if this is considered good or bad! I ran your instrumented >>>> version (thanks for the exhaustive instructions btw) and it drew >>>> some pretty graphs, but I'm not enough of a TCP expert to >>>> interpret them properly. >>>> >>>> Could you give this a go in your test environment and let me >>>> know what you think? >>>> >>>> I'm extremely suspicious of the console code -- it shouldn't be >>>> necessary to include a delay in the print loop; that's >>>> definitely worth investigating. >>>> >>>> Cheers, >>>> Dave >>>> >>>> >>>> On Thu, Sep 19, 2013 at 11:02 AM, David Scott >>>> > wrote: >>>> >>>> Hi Dimos, >>>> >>>> Thanks for looking into this! Thinking about it, I think we have >>>> several problems. >>>> >>>> 1. I think the Activations.wait API is difficult to use / unsafe: >>>> >>>> (* Block waiting for an event to occur on a particular port *) >>>> let wait evtchn = >>>> if Eventchn.is_valid evtchn then begin >>>> let port = Eventchn.to_int evtchn in >>>> let th, u = Lwt.task () in >>>> let node = Lwt_sequence.add_l u event_cb.(port) in >>>> Lwt.on_cancel th (fun _ -> Lwt_sequence.remove node); >>>> th >>>> end else Lwt.fail Generation.Invalid >>>> >>>> When you call Activations.wait you are added to a 'sequence' >>>> (like a list) of people to wake up when the next event occurs. A >>>> typical driver would call Activations.wait in a loop, block for >>>> an event, wake up, signal some other thread to do work and then >>>> block again. However if the thread running the loop blocks >>>> anywhere else, then the thread will not be added to the sequence >>>> straight away and any notifications that arrive during the gap >>>> will be dropped. I noticed this when debugging my block backend >>>> implementation. I think netif has this problem: >>>> >>>> let listen nf fn = >>>> (* Listen for the activation to poll the interface *) >>>> let rec poll_t t = >>>> lwt () = refill_requests t in >>>> ^^^ blocks here, can miss events >>>> >>>> rx_poll t fn; >>>> tx_poll t; >>>> (* Evtchn.notify nf.t.evtchn; *) >>>> lwt new_t = >>>> try_lwt >>>> Activations.wait t.evtchn >> return t >>>> with >>>> | Generation.Invalid -> >>>> Console.log_s "Waiting for plug in listen" >> >>>> wait_for_plug nf >> >>>> Console.log_s "Done..." >> >>>> return nf.t >>>> in poll_t new_t >>>> in >>>> poll_t nf.t >>>> >>>> >>>> I think we should change the semantics of Activations.wait to be >>>> more level-triggered rather than edge-triggered (i.e. more like >>>> the underlying behaviour of xen) like this: >>>> >>>> type event >>>> (** a particular event *) >>>> >>>> val wait: Evtchn.t -> event option -> event Lwt.t >>>> (** [wait evtchn None] returns [Some e] where [e] is the latest >>>> event. >>>> [wait evtchn (Some e)] returns [Some e'] where [e'] is a >>>> later event than [e] *) >>>> >>>> In the implementation we could have "type event = int" and >>>> maintain a counter of "number of times this event has been >>>> signalled". When you call Activations.wait, you would pass in the >>>> number of the last event you saw, and the thread would block >>>> until a new event is available. This way you wouldn't have to be >>>> registered in the table when the event arrives. >>>> >>>> 2. SCHEDOP_poll has a low (arbitrary) nr_ports limit >>>> >>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/common/schedule.c;h=a8398bd9ed4827564bed4346e1fdfbb98ec5907e;hb=c5e9596cd095e3b96a090002d9e6629a980904eb#l712 >>>> >>>> 704 static long do_poll(struct sched_poll *sched_poll) >>>> 705 { >>>> 706 struct vcpu *v = current; >>>> 707 struct domain *d = v->domain; >>>> 708 evtchn_port_t port; >>>> 709 long rc; >>>> 710 unsigned int i; >>>> 711 >>>> 712 /* Fairly arbitrary limit. */ >>>> 713 if ( sched_poll->nr_ports > 128 ) >>>> 714 return -EINVAL; >>>> >>>> The total number of available event channels for a 64-bit guest >>>> is 4096 using the current ABI (a new interface is under >>>> development which allows even more). The limit of 128 is probably >>>> imposed to limit the amount of time the hypercall takes, to avoid >>>> hitting scalability limits like you do in userspace with select(). >>>> >>>> One of the use-cases I'd like to use Mirage for is to run backend >>>> services (like xenstore or blkback) for all the domains on a >>>> host. This requires at least one event channel per client domain. >>>> We routinely run ~300 VMs/host, so the 128 limit is too small. >>>> Plus a quick grep around Linux shows that it doesn't use >>>> SCHEDOP_poll very much-- I think we should focus on using the >>>> hypercalls that other OSes are using, for maximum chance of success. >>>> >>>> So I think we should switch from select()-like behaviour using >>>> SCHEDOP_poll to interrupt-based delivery using SCHEDOP_block. I >>>> note that upstream mini-os does this by default too. I'll take a >>>> look at this. >>>> >>>> Cheers, >>>> Dave >>>> >>>> >>>> >>>> On Fri, Sep 13, 2013 at 11:50 PM, Dimosthenis Pediaditakis >>>> >>> > wrote: >>>> >>>> Hi all, >>>> The last few days I've been trying to pin-down the >>>> performance issues of the Mirage network stack, when running >>>> over Xen. >>>> When trying to push net-direct to its limits, random >>>> transmissions stall for anywhere between 0.1sec-4sec >>>> (especially at the sender). >>>> >>>> After some experimentation, I believe that those time-outs >>>> occur because netif is not (always) notified (via >>>> Activations) about freed TX-ring slots. >>>> It seems that these events (intermittently) don't reach the >>>> guest domain's front-end driver. >>>> >>>> AFAIK Activations.wait() currently blocks waiting for an >>>> event on the port belonging to the event channel for the netif. >>>> This event is delivered to Activations.run via Main.run.aux >>>> which is invoked via the callback in app_main() of >>>> runtime/kernel/main.c >>>> The problem I observed was that using "SCHEDOP_poll" without >>>> masking the intended events, the hypervisor didn't "wake-up" >>>> the blocked domain upon new event availability. >>>> The requirement for event-masking when using "SCHEDOP_poll" >>>> is also mentioned in the Xen documentation. >>>> >>>> I've produced a patch that seems to fix the above erratic >>>> behavior. >>>> Now I am able to consistently achieve higher speeds (up to >>>> 2.75Gbps DomU2Domu). Please, have a look at my repo: >>>> https://github.com/dimosped/mirage-platform >>>> It will be helpful to use big-enough txqueuelen values for >>>> your VIFs, as the current TCP implementation doesn't like >>>> much losses at high datarates. The default size in my system >>>> was only 32. >>>> >>>> I have also modified the mirage-net-direct by adding per-flow >>>> TCP debug logging. This has helped me to better understand >>>> and pin-down the problem. >>>> You can grab the modified sources here: >>>> https://github.com/dimosped/mirage-net >>>> Be aware that logging big volumes of data for a TCP flow will >>>> require big enough memory. Nevertheless, it only barely >>>> affects performance. >>>> >>>> The iperf benchmark sources can be found here: >>>> https://github.com/dimosped/iperf-mirage >>>> I've included as much info as possible in the README file. >>>> This should be sufficient to get you started and replicate my >>>> experiments. >>>> >>>> In the iperf-mirage repo there is also a Python tool, which >>>> you can use to automatically generate plots based on the >>>> collected TCP debug info (I include also a sample dataset in >>>> data/ ): >>>> https://github.com/dimosped/iperf-mirage/tree/master/tools/MirageTcpVis >>>> For really large datasets, the script might be slow. I need >>>> to switch into using NumPy arrays at some point... >>>> >>>> Please keep in mind that I am a newbie in Xen/Mirage so your >>>> comments/input are more than welcome. >>>> >>>> Regards, >>>> Dimos >>>> >>>> >>>> >>>> >>>> ------------------------------------------------ >>>> MORE TECHNICAL DETAILS >>>> ------------------------------------------------ >>>> >>>> >>>> ----------------------------------------------------------------- >>>> >>>> === How (I think) Mirage and XEN scheduling works === >>>> ----------------------------------------------------------------- >>>> >>>> - When Netif receives a writev request, it checks if the TX >>>> ring has enough empty space (for the producer) for the data >>>> - If there is not enough space, it block-waits (via >>>> Activations.wait) for an event on the port mapped to the >>>> netif (and bound to the backend driver) >>>> - Otherwise it pushes the request. >>>> - Activations are notified (via run) from "aux ()" in >>>> Main.run. Once notified, it means that the waiting netif can >>>> proceed, check again the ring for free space, write a new >>>> request, and send an event to the backend. >>>> - Main.run.aux is registered as a callback (under name >>>> "OS.Main.run") and is invoked in xen/runtime/kernel/main.c >>>> (in app_main() loop). As long as the Mirage guest domain is >>>> scheduled, this loop keeps running. >>>> - However, in Main.run.aux, the Mirage guest domain is >>>> blocked via "block_domain timeout" if the main thread has no >>>> task to perform. >>>> - In turn, "block_domain" invokes caml_block_domain() found >>>> in xen/runtime/kernel/main.c, which issues a >>>> "HYPERVISOR_sched_op(SCHEDOP_poll, &sched_poll);" hypercall >>>> >>>> ------------------------------------- >>>> === Polling mode issue === >>>> ------------------------------------- >>>> In my opinion, and based on debug information, it seems that >>>> the problem is that Mirage uses "SCHEDOP_poll" without >>>> masking the event channels. >>>> The XEN documentation clearly states that with "SCHEDOP_poll" >>>> the domain would yield until either >>>> a) an event is pending on the polled channels and >>>> b) the timeout time (given in nanoseconds, is not duration >>>> but absolute system time) is reached >>>> It also states that this SCHEDOP_poll can only be be executed >>>> when the guest has delivery of events disabled. >>>> >>>> In Mirage, netif events are not masked and therefore they >>>> never "wakeup" the guest domain. >>>> The guest only wakes-up whenever a thread is scheduled >>>> to wakeup in Time.SleepQueue (e.g. a TCP timer). >>>> Once the guest is scheduled again, it completes any >>>> outstanding tasks, sends any packets pending, and whenever a) >>>> the TX ring gets full, or b)the hypervisor it, c) it will >>>> sleep again. >>>> To further support the above, whenever I press buttons via >>>> XEN-console while the mirage-sender is running, the execution >>>> completes faster. >>>> >>>> ---------------- >>>> === Fix === >>>> ---------------- >>>> There are multiple ways to mask events (e.g. at VCPU level, >>>> event level etc). >>>> As a quick hack I replaced "Eventchn.unmask h evtchn;" in >>>> Netif.plug_inner with Eventchn.mask h evtchn (which I had to >>>> create, both in Eventchn and as a stub in >>>> xen/runtime/kernel/eventchn_stubs.c). >>>> See: >>>> https://github.com/dimosped/mirage-platform/commit/6d4d3f0403497f07fde4db6f4cb63665a8bf8e26 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- Dave Scott >>>> >>>> >>>> >>>> >>>> -- >>>> Dave Scott From daniel.buenzli@erratique.ch Fri Oct 04 12:32:29 2013 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VS3cT-0007fd-HZ (Exim 4.70) (return-path ); Fri, 04 Oct 2013 12:32:29 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1528751 X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail6.webfaction.com ([74.55.86.74]:43636 helo=smtp.webfaction.com) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.148]:25) with esmtp id 1VS3cT-0004w7-DC (Exim 4.80_167-5a66dd3) (return-path ); Fri, 04 Oct 2013 12:32:29 +0100 Received: from [192.168.10.156] (110-19.193-178.cust.bluewin.ch [178.193.19.110]) by smtp.webfaction.com (Postfix) with ESMTP id 68B4D22296A8; Fri, 4 Oct 2013 11:32:27 +0000 (UTC) Date: Fri, 4 Oct 2013 13:33:56 +0200 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Richard Mortier Message-ID: In-Reply-To: <4FD883E8-F81B-40B5-8017-6F2CDFA35097@nottingham.ac.uk> References: <4FD883E8-F81B-40B5-8017-6F2CDFA35097@nottingham.ac.uk> Subject: Re: [ocl-staff] Using Merlin from Vim X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: OCaml Labs , "=?utf-8?Q?cl-mirage=40lists.cam.ac.uk_List?=" , Anil Madhavapeddy X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 11:32:29 -0000 Status: RO Content-Length: 473 Lines: 19 Le vendredi, 4 octobre 2013 =C3=A0 12:11, Richard Mortier a =C3=A9crit : > found it a little flaky tbh - the indentation and type inference featur= es (probably what i care most about) Do you have any idea if it's possible to use merlin in conjunction with o= cp-indent =3F =20 The latter is the best indentation engine I have ever used for OCaml -- i= mplements the programming guidelines and you rarely need to fallback to m= anual indentation. =20 Best, Daniel From Richard.Mortier@nottingham.ac.uk Fri Oct 04 12:37:13 2013 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VS3h3-0000KO-EY (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 12:37:13 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1528751 * 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from engine02-20433-2.icritical.com ([195.62.217.151]:41703) by ppsw-32.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with smtp id 1VS3h3-0000I8-09 (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 12:37:13 +0100 Received: (qmail 16484 invoked from network); 4 Oct 2013 11:36:55 -0000 Received: from localhost (127.0.0.1) by engine02-20433-2.icritical.com with SMTP; 4 Oct 2013 11:36:55 -0000 Received: from engine02-20433-2.icritical.com ([127.0.0.1]) by localhost (engine02-20433-2.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 15994-10 for ; Fri, 4 Oct 2013 12:36:54 +0100 (BST) Received: (qmail 15376 invoked by uid 599); 4 Oct 2013 11:35:34 -0000 Received: from unknown (HELO smtp3.nottingham.ac.uk) (128.243.44.55) by engine02-20433-2.icritical.com (qpsmtpd/0.28) with ESMTP; Fri, 04 Oct 2013 12:35:34 +0100 Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp3.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1VS3fY-0003nC-KW; Fri, 04 Oct 2013 12:35:40 +0100 From: Richard Mortier To: =?iso-8859-1?Q?Daniel_B=FCnzli?= Date: Fri, 4 Oct 2013 12:35:39 +0100 Subject: Re: [ocl-staff] Using Merlin from Vim Thread-Topic: [ocl-staff] Using Merlin from Vim Thread-Index: Ac7A9dnLI8rigLfWT0qXVr7SGUXZog== Message-ID: <7726EDFD-C7E0-411A-9282-F80964C9215A@nottingham.ac.uk> References: <4FD883E8-F81B-40B5-8017-6F2CDFA35097@nottingham.ac.uk> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: by iCritical at engine02-20433-2.icritical.com Cc: OCaml Labs , Anil, "cl-mirage@lists.cam.ac.uk List" , Madhavapeddy X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 11:37:13 -0000 Status: RO Content-Length: 1417 Lines: 36 On 4 Oct 2013, at 12:33, Daniel B=FCnzli wrote: > Le vendredi, 4 octobre 2013 =E0 12:11, Richard Mortier a =E9crit : >> found it a little flaky tbh - the indentation and type inference feature= s (probably what i care most about) >=20 > Do you have any idea if it's possible to use merlin in conjunction with o= cp-indent ? =20 >=20 > The latter is the best indentation engine I have ever used for OCaml -- i= mplements the programming guidelines and you rarely need to fallback to man= ual indentation. =20 not investigated. but it's emacs, so presumably :) does ocp-indent know about lwt syntax extensions? (and others come to that= ...) --=20 Cheers, R. This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From daniel.buenzli@erratique.ch Fri Oct 04 12:56:45 2013 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VS3zx-0001PI-TD (Exim 4.70) (return-path ); Fri, 04 Oct 2013 12:56:45 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1528751 X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail6.webfaction.com ([74.55.86.74]:50366 helo=smtp.webfaction.com) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.148]:25) with esmtp id 1VS3zx-0008B4-Db (Exim 4.80_167-5a66dd3) (return-path ); Fri, 04 Oct 2013 12:56:45 +0100 Received: from [192.168.10.156] (110-19.193-178.cust.bluewin.ch [178.193.19.110]) by smtp.webfaction.com (Postfix) with ESMTP id F084759A3500; Fri, 4 Oct 2013 11:56:38 +0000 (UTC) Date: Fri, 4 Oct 2013 13:58:07 +0200 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Richard Mortier Message-ID: <04F77FC4E408408A84D1410F4C4167D4@erratique.ch> In-Reply-To: <7726EDFD-C7E0-411A-9282-F80964C9215A@nottingham.ac.uk> References: <4FD883E8-F81B-40B5-8017-6F2CDFA35097@nottingham.ac.uk> <7726EDFD-C7E0-411A-9282-F80964C9215A@nottingham.ac.uk> Subject: Re: [ocl-staff] Using Merlin from Vim X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: OCaml Labs , "=?utf-8?Q?cl-mirage=40lists.cam.ac.uk_List?=" , Madhavapeddy X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 11:56:46 -0000 Status: RO Content-Length: 229 Lines: 10 Le vendredi, 4 octobre 2013 =C3=A0 13:35, Richard Mortier a =C3=A9crit : > does ocp-indent know about lwt syntax extensions=3F (and others come to= that...) It seems https://github.com/OCamlPro/ocp-indent/issues/25 Daniel From scott.dj@gmail.com Fri Oct 04 13:04:42 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VS47d-0001lt-VV (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 13:04:41 +0100 X-Cam-SpamDetails: score 0.6 from SpamAssassin-3.3.2-1528751 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.220.48 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (scott.dj[at]gmail.com) * 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is * CUSTOM_MED * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid * 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing * list X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-pa0-f48.google.com ([209.85.220.48]:40551) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with esmtp id 1VS47b-0006P2-hf (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 04 Oct 2013 13:04:41 +0100 Received: by mail-pa0-f48.google.com with SMTP id bj1so4046206pad.35 for ; Fri, 04 Oct 2013 05:04:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.251.133 with SMTP id zk5mr13945452pbc.69.1380888278213; Fri, 04 Oct 2013 05:04:38 -0700 (PDT) Received: by 10.70.56.36 with HTTP; Fri, 4 Oct 2013 05:04:38 -0700 (PDT) In-Reply-To: <524EA18D.2090609@cl.cam.ac.uk> References: <5233969C.1080802@cl.cam.ac.uk> <5240EC98.3060509@cl.cam.ac.uk> <5241AFF2.5070001@cl.cam.ac.uk> <20131004095711.GI14429@dark.recoil.org> <524EA18D.2090609@cl.cam.ac.uk> Date: Fri, 4 Oct 2013 13:04:38 +0100 Message-ID: Subject: Re: Improving the network-stack performance over Xen From: David Scott To: Dimosthenis Pediaditakis Content-Type: multipart/alternative; boundary=047d7b1630a94c282c04e7e91b29 Cc: Mirage List , Anil Madhavapeddy X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 12:04:42 -0000 Status: RO Content-Length: 38965 Lines: 902 --047d7b1630a94c282c04e7e91b29 Content-Type: text/plain; charset=ISO-8859-1 Great. Jon pointed out that I've almost-certainly broken suspend-- I'll look at that now. On Fri, Oct 4, 2013 at 12:07 PM, Dimosthenis Pediaditakis < dimosthenis.pediaditakis@cl.cam.ac.uk> wrote: > As far as Network stack performance, domain scheduling and console > operation goes, I haven't observed any issues so far. > > D. > > > On 04/10/13 10:57, Anil Madhavapeddy wrote: > >> Closing the loop on this; is Dave's Activations patch considered >> safe-to-merge now? >> >> -anil >> >> On Tue, Sep 24, 2013 at 04:29:54PM +0100, Dimosthenis Pediaditakis wrote: >> >>> Hi again, >>> as promised, here are some data from a DomU-2-DomU iperf flow, >>> pushing 0.8Gbits in 0.38sec (~2.1Gbps): >>> http://www.cl.cam.ac.uk/~**dp463/files/mirageNetData.tar.**gz >>> >>> Note that I've used a txqueuelen of 500 for each VIF in dom0. >>> Also, with TCP debug disabled, speeds reach >= 2.5Gbps. >>> >>> Everythin seems smoother. Didn't observe any odd TX delay spikes >>> caused by netif blocking. >>> >>> Regards, >>> D. >>> >>> >>> >>> On 24/09/13 02:36, Dimosthenis Pediaditakis wrote: >>> >>>> Hi David, >>>> sorry for the absence. I attended a Workshop on SDN last week, and >>>> today was quite a busy day. >>>> I had a look in the interrupt branch of your mirage-platform repo, >>>> cloned it and ran a few experiments. >>>> The speeds I got were consistently between 2.45-2.6Gbps on my >>>> machine (i7-3770, dual ch. DDR3 1600), which is a very good >>>> number. >>>> Unfortunatelly, I didn't have the time to further stress test it >>>> and generate any TCP stack plots. This is the top item in my TODO >>>> list. >>>> >>>> I also went briefly through the additions/modifications in >>>> hypervisor.c, main.c, activations.ml, netif.ml, main.ml >>>> It seems that SCHEDOP_block + no-op handling + evtchn_poll + >>>> VIRQ_TIMER-bind along with the rewriting of Activations (fix for >>>> the silently dropped events) have done the trick. >>>> >>>> A couple of questions: >>>> - In file hypervisor.c, what is the purpose of " >>>> force_evtchn_callback" ? I've seen it only being invoked via >>>> "__sti()" and "__restore_flags()" >>>> >>>> - In the updated design, when an event is received, then: >>>> SCHEDOP_block returns, >>>> event_poll is then invoked, and >>>> finally Main.aux() is called. >>>> Activations.run() is invoked in Main.aux() if no threads are >>>> scheduled, and subsequently the domain is blocked again (until a >>>> timer interrupt, or reception of another event). My question is >>>> why don't we re-check right after "Activations.run()" the state of >>>> t ? For example if packets are waiting to be sent, and netif gets >>>> unblocked, why we block the domain directly again? >>>> >>>> Also, thanks thanks for the credits in you updates :-) >>>> >>>> D. >>>> >>>> >>>> >>>> On 19/09/13 22:41, David Scott wrote: >>>> >>>>> Hi Dimos, >>>>> >>>>> I've created a new patch set based on a mix of your ideas and mine: >>>>> >>>>> https://github.com/mirage/**mirage-platform/pull/58 >>>>> >>>>> I've proposed switching to SCHEDOP_block with interrupts >>>>> enabled. Unlike in regular Mini-OS I don't think we need to do >>>>> anything in the hypervisor_callback, because we already have >>>>> code to poll the evtchn pending bits in evtchn_poll-- so we're a >>>>> bit of a hybrid: interrupts on for wakeups but the whole OS is >>>>> still based around a select/poll-style loop. I've left all event >>>>> channels unmasked and used the event_upcall_mask to turn on/off >>>>> event delivery globally. I've revamped the OCaml Activations >>>>> interface to remove one source of missing events. >>>>> >>>>> So far the code is working ok in my testing. I ran mirage-iperf >>>>> and am getting 1642002 KBit/sec on my test hardware -- I don't >>>>> know if this is considered good or bad! I ran your instrumented >>>>> version (thanks for the exhaustive instructions btw) and it drew >>>>> some pretty graphs, but I'm not enough of a TCP expert to >>>>> interpret them properly. >>>>> >>>>> Could you give this a go in your test environment and let me >>>>> know what you think? >>>>> >>>>> I'm extremely suspicious of the console code -- it shouldn't be >>>>> necessary to include a delay in the print loop; that's >>>>> definitely worth investigating. >>>>> >>>>> Cheers, >>>>> Dave >>>>> >>>>> >>>>> On Thu, Sep 19, 2013 at 11:02 AM, David Scott >>>>> > wrote: >>>>> >>>>> Hi Dimos, >>>>> >>>>> Thanks for looking into this! Thinking about it, I think we have >>>>> several problems. >>>>> >>>>> 1. I think the Activations.wait API is difficult to use / unsafe: >>>>> >>>>> (* Block waiting for an event to occur on a particular port *) >>>>> let wait evtchn = >>>>> if Eventchn.is_valid evtchn then begin >>>>> let port = Eventchn.to_int evtchn in >>>>> let th, u = Lwt.task () in >>>>> let node = Lwt_sequence.add_l u event_cb.(port) in >>>>> Lwt.on_cancel th (fun _ -> Lwt_sequence.remove node); >>>>> th >>>>> end else Lwt.fail Generation.Invalid >>>>> >>>>> When you call Activations.wait you are added to a 'sequence' >>>>> (like a list) of people to wake up when the next event occurs. A >>>>> typical driver would call Activations.wait in a loop, block for >>>>> an event, wake up, signal some other thread to do work and then >>>>> block again. However if the thread running the loop blocks >>>>> anywhere else, then the thread will not be added to the sequence >>>>> straight away and any notifications that arrive during the gap >>>>> will be dropped. I noticed this when debugging my block backend >>>>> implementation. I think netif has this problem: >>>>> >>>>> let listen nf fn = >>>>> (* Listen for the activation to poll the interface *) >>>>> let rec poll_t t = >>>>> lwt () = refill_requests t in >>>>> ^^^ blocks here, can miss events >>>>> >>>>> rx_poll t fn; >>>>> tx_poll t; >>>>> (* Evtchn.notify nf.t.evtchn; *) >>>>> lwt new_t = >>>>> try_lwt >>>>> Activations.wait t.evtchn >> return t >>>>> with >>>>> | Generation.Invalid -> >>>>> Console.log_s "Waiting for plug in listen" >> >>>>> wait_for_plug nf >> >>>>> Console.log_s "Done..." >> >>>>> return nf.t >>>>> in poll_t new_t >>>>> in >>>>> poll_t nf.t >>>>> >>>>> >>>>> I think we should change the semantics of Activations.wait to be >>>>> more level-triggered rather than edge-triggered (i.e. more like >>>>> the underlying behaviour of xen) like this: >>>>> >>>>> type event >>>>> (** a particular event *) >>>>> >>>>> val wait: Evtchn.t -> event option -> event Lwt.t >>>>> (** [wait evtchn None] returns [Some e] where [e] is the latest >>>>> event. >>>>> [wait evtchn (Some e)] returns [Some e'] where [e'] is a >>>>> later event than [e] *) >>>>> >>>>> In the implementation we could have "type event = int" and >>>>> maintain a counter of "number of times this event has been >>>>> signalled". When you call Activations.wait, you would pass in the >>>>> number of the last event you saw, and the thread would block >>>>> until a new event is available. This way you wouldn't have to be >>>>> registered in the table when the event arrives. >>>>> >>>>> 2. SCHEDOP_poll has a low (arbitrary) nr_ports limit >>>>> >>>>> http://xenbits.xen.org/gitweb/**?p=xen.git;a=blob;f=xen/** >>>>> common/schedule.c;h=**a8398bd9ed4827564bed4346e1fdfb**b98ec5907e;hb=** >>>>> c5e9596cd095e3b96a090002d9e662**9a980904eb#l712 >>>>> >>>>> 704 static long do_poll(struct sched_poll *sched_poll) >>>>> 705 { >>>>> 706 struct vcpu *v = current; >>>>> 707 struct domain *d = v->domain; >>>>> 708 evtchn_port_t port; >>>>> 709 long rc; >>>>> 710 unsigned int i; >>>>> 711 >>>>> 712 /* Fairly arbitrary limit. */ >>>>> 713 if ( sched_poll->nr_ports > 128 ) >>>>> 714 return -EINVAL; >>>>> >>>>> The total number of available event channels for a 64-bit guest >>>>> is 4096 using the current ABI (a new interface is under >>>>> development which allows even more). The limit of 128 is probably >>>>> imposed to limit the amount of time the hypercall takes, to avoid >>>>> hitting scalability limits like you do in userspace with select(). >>>>> >>>>> One of the use-cases I'd like to use Mirage for is to run backend >>>>> services (like xenstore or blkback) for all the domains on a >>>>> host. This requires at least one event channel per client domain. >>>>> We routinely run ~300 VMs/host, so the 128 limit is too small. >>>>> Plus a quick grep around Linux shows that it doesn't use >>>>> SCHEDOP_poll very much-- I think we should focus on using the >>>>> hypercalls that other OSes are using, for maximum chance of >>>>> success. >>>>> >>>>> So I think we should switch from select()-like behaviour using >>>>> SCHEDOP_poll to interrupt-based delivery using SCHEDOP_block. I >>>>> note that upstream mini-os does this by default too. I'll take a >>>>> look at this. >>>>> >>>>> Cheers, >>>>> Dave >>>>> >>>>> >>>>> >>>>> On Fri, Sep 13, 2013 at 11:50 PM, Dimosthenis Pediaditakis >>>>> >>>>> >> >>>>> wrote: >>>>> >>>>> Hi all, >>>>> The last few days I've been trying to pin-down the >>>>> performance issues of the Mirage network stack, when running >>>>> over Xen. >>>>> When trying to push net-direct to its limits, random >>>>> transmissions stall for anywhere between 0.1sec-4sec >>>>> (especially at the sender). >>>>> >>>>> After some experimentation, I believe that those time-outs >>>>> occur because netif is not (always) notified (via >>>>> Activations) about freed TX-ring slots. >>>>> It seems that these events (intermittently) don't reach the >>>>> guest domain's front-end driver. >>>>> >>>>> AFAIK Activations.wait() currently blocks waiting for an >>>>> event on the port belonging to the event channel for the netif. >>>>> This event is delivered to Activations.run via Main.run.aux >>>>> which is invoked via the callback in app_main() of >>>>> runtime/kernel/main.c >>>>> The problem I observed was that using "SCHEDOP_poll" without >>>>> masking the intended events, the hypervisor didn't "wake-up" >>>>> the blocked domain upon new event availability. >>>>> The requirement for event-masking when using "SCHEDOP_poll" >>>>> is also mentioned in the Xen documentation. >>>>> >>>>> I've produced a patch that seems to fix the above erratic >>>>> behavior. >>>>> Now I am able to consistently achieve higher speeds (up to >>>>> 2.75Gbps DomU2Domu). Please, have a look at my repo: >>>>> https://github.com/dimosped/**mirage-platform >>>>> It will be helpful to use big-enough txqueuelen values for >>>>> your VIFs, as the current TCP implementation doesn't like >>>>> much losses at high datarates. The default size in my system >>>>> was only 32. >>>>> >>>>> I have also modified the mirage-net-direct by adding per-flow >>>>> TCP debug logging. This has helped me to better understand >>>>> and pin-down the problem. >>>>> You can grab the modified sources here: >>>>> https://github.com/dimosped/**mirage-net >>>>> Be aware that logging big volumes of data for a TCP flow will >>>>> require big enough memory. Nevertheless, it only barely >>>>> affects performance. >>>>> >>>>> The iperf benchmark sources can be found here: >>>>> https://github.com/dimosped/**iperf-mirage >>>>> I've included as much info as possible in the README file. >>>>> This should be sufficient to get you started and replicate my >>>>> experiments. >>>>> >>>>> In the iperf-mirage repo there is also a Python tool, which >>>>> you can use to automatically generate plots based on the >>>>> collected TCP debug info (I include also a sample dataset in >>>>> data/ ): >>>>> https://github.com/dimosped/**iperf-mirage/tree/master/** >>>>> tools/MirageTcpVis >>>>> For really large datasets, the script might be slow. I need >>>>> to switch into using NumPy arrays at some point... >>>>> >>>>> Please keep in mind that I am a newbie in Xen/Mirage so your >>>>> comments/input are more than welcome. >>>>> >>>>> Regards, >>>>> Dimos >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------**------------------ >>>>> MORE TECHNICAL DETAILS >>>>> ------------------------------**------------------ >>>>> >>>>> >>>>> ------------------------------**------------------------------ >>>>> **----- >>>>> >>>>> === How (I think) Mirage and XEN scheduling works === >>>>> ------------------------------**------------------------------ >>>>> **----- >>>>> >>>>> - When Netif receives a writev request, it checks if the TX >>>>> ring has enough empty space (for the producer) for the data >>>>> - If there is not enough space, it block-waits (via >>>>> Activations.wait) for an event on the port mapped to the >>>>> netif (and bound to the backend driver) >>>>> - Otherwise it pushes the request. >>>>> - Activations are notified (via run) from "aux ()" in >>>>> Main.run. Once notified, it means that the waiting netif can >>>>> proceed, check again the ring for free space, write a new >>>>> request, and send an event to the backend. >>>>> - Main.run.aux is registered as a callback (under name >>>>> "OS.Main.run") and is invoked in xen/runtime/kernel/main.c >>>>> (in app_main() loop). As long as the Mirage guest domain is >>>>> scheduled, this loop keeps running. >>>>> - However, in Main.run.aux, the Mirage guest domain is >>>>> blocked via "block_domain timeout" if the main thread has no >>>>> task to perform. >>>>> - In turn, "block_domain" invokes caml_block_domain() found >>>>> in xen/runtime/kernel/main.c, which issues a >>>>> "HYPERVISOR_sched_op(SCHEDOP_**poll, &sched_poll);" hypercall >>>>> >>>>> ------------------------------**------- >>>>> === Polling mode issue === >>>>> ------------------------------**------- >>>>> In my opinion, and based on debug information, it seems that >>>>> the problem is that Mirage uses "SCHEDOP_poll" without >>>>> masking the event channels. >>>>> The XEN documentation clearly states that with "SCHEDOP_poll" >>>>> the domain would yield until either >>>>> a) an event is pending on the polled channels and >>>>> b) the timeout time (given in nanoseconds, is not duration >>>>> but absolute system time) is reached >>>>> It also states that this SCHEDOP_poll can only be be executed >>>>> when the guest has delivery of events disabled. >>>>> >>>>> In Mirage, netif events are not masked and therefore they >>>>> never "wakeup" the guest domain. >>>>> The guest only wakes-up whenever a thread is scheduled >>>>> to wakeup in Time.SleepQueue (e.g. a TCP timer). >>>>> Once the guest is scheduled again, it completes any >>>>> outstanding tasks, sends any packets pending, and whenever a) >>>>> the TX ring gets full, or b)the hypervisor it, c) it will >>>>> sleep again. >>>>> To further support the above, whenever I press buttons via >>>>> XEN-console while the mirage-sender is running, the execution >>>>> completes faster. >>>>> >>>>> ---------------- >>>>> === Fix === >>>>> ---------------- >>>>> There are multiple ways to mask events (e.g. at VCPU level, >>>>> event level etc). >>>>> As a quick hack I replaced "Eventchn.unmask h evtchn;" in >>>>> Netif.plug_inner with Eventchn.mask h evtchn (which I had to >>>>> create, both in Eventchn and as a stub in >>>>> xen/runtime/kernel/eventchn_**stubs.c). >>>>> See: >>>>> https://github.com/dimosped/**mirage-platform/commit/** >>>>> 6d4d3f0403497f07fde4db6f4cb636**65a8bf8e26 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- Dave Scott >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Dave Scott >>>>> >>>> > -- Dave Scott --047d7b1630a94c282c04e7e91b29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Great. Jon pointed out that I've almost-certainly brok= en suspend-- I'll look at that now.

On Fri, Oct 4, 2013 at 12:07 PM, Dimostheni= s Pediaditakis <dimosthenis.pediaditakis@cl.cam.ac.uk<= /a>> wrote:
As far as Network stack performance, domain = scheduling and console operation goes, I haven't observed any issues so= far.

D.


On 04/10/13 10:57, Anil Madhavapeddy wrote:
Closing the loop on this; is Dave's Activations patch considered
safe-to-merge now?

-anil

On Tue, Sep 24, 2013 at 04:29:54PM +0100, Dimosthenis Pediaditakis wrote:
Hi again,
as promised, here are some data from a DomU-2-DomU iperf flow,
pushing 0.8Gbits in 0.38sec (~2.1Gbps):
http://www.cl.cam.ac.uk/~dp463/files/mirageNetData.tar.= gz

Note that I've used a txqueuelen of 500 for each VIF in dom0.
Also, with TCP debug disabled, speeds reach >=3D 2.5Gbps.

Everythin seems smoother. Didn't observe any odd TX delay spikes
caused by netif blocking.

Regards,
D.



On 24/09/13 02:36, Dimosthenis Pediaditakis wrote:
Hi David,
sorry for the absence. I attended a Workshop on SDN last week, and
today was quite a busy day.
I had a look in the interrupt branch of your mirage-platform repo,
cloned it and ran a few experiments.
The speeds I got were consistently between 2.45-2.6Gbps on my
machine (i7-3770, dual ch. DDR3 1600), which is a very good
number.
Unfortunatelly, I didn't have the time to further stress test it
and generate any TCP stack plots. This is the top item in my TODO
list.

I also went briefly through the additions/modifications in
hypervisor.c, main.c, a= ctivations.ml, netif.ml, main.ml
It seems that SCHEDOP_block + no-op handling + evtchn_poll =A0+
VIRQ_TIMER-bind =A0along with the rewriting of Activations (fix for
the silently dropped events) have done the trick.

A couple of questions:
- In file hypervisor.c, what is the purpose of "
force_evtchn_callback" ? I've seen it only being invoked via
"__sti()" and "__restore_flags()"

- In the updated design, when an event is received, then:
=A0 =A0 SCHEDOP_block returns,
=A0 =A0 event_poll is then invoked, and
=A0 =A0 finally Main.aux() is called.
=A0 Activations.run() is invoked in Main.aux() if no threads are
scheduled, and subsequently the domain is blocked again (until a
timer interrupt, or reception of another event). =A0My question is
why don't we re-check right after "Activations.run()" the sta= te of
t ? =A0For example if packets are waiting to be sent, and netif gets
unblocked, why we block the domain directly again?

Also, thanks thanks for the credits in you updates :-)

D.



On 19/09/13 22:41, David Scott wrote:
Hi Dimos,

I've created a new patch set based on a mix of your ideas and mine:

https://github.com/mirage/mirage-platform/pull/58

I've proposed switching to SCHEDOP_block with interrupts
enabled. Unlike in regular Mini-OS I don't think we need to do
anything in the hypervisor_callback, because we already have
code to poll the evtchn pending bits in evtchn_poll-- so we're a
bit of a hybrid: interrupts on for wakeups but the whole OS is
still based around a select/poll-style loop. I've left all event
channels unmasked and used the event_upcall_mask to turn on/off
event delivery globally. I've revamped the OCaml Activations
interface to remove one source of missing events.

So far the code is working ok in my testing. I ran mirage-iperf
and am getting 1642002 KBit/sec on my test hardware -- I don't
know if this is considered good or bad! I ran your instrumented
version (thanks for the exhaustive instructions btw) and it drew
some pretty graphs, but I'm not enough of a TCP expert to
interpret them properly.

Could you give this a go in your test environment and let me
know what you think?

I'm extremely suspicious of the console code -- it shouldn't be
necessary to include a delay in the print loop; that's
definitely worth investigating.

Cheers,
Dave


On Thu, Sep 19, 2013 at 11:02 AM, David Scott
<scott.dj@gmail.= com <mailto:= scott.dj@gmail.com>> wrote:

=A0 =A0 Hi Dimos,

=A0 =A0 Thanks for looking into this! Thinking about it, I think we have =A0 =A0 several problems.

=A0 =A0 1. I think the Activations.wait API is difficult to use / unsafe:
=A0 =A0 (* Block waiting for an event to occur on a particular port *)
=A0 =A0 let wait evtchn =3D
=A0 =A0 =A0 if Eventchn.is_valid evtchn then begin
=A0 =A0 =A0 =A0 =A0 =A0 =A0 let port =3D Eventchn.to_int evtchn in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 let th, u =3D Lwt.task () in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 let node =3D Lwt_sequence.add_l u event_cb.(por= t) in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Lwt.on_cancel th (fun _ -> Lwt_sequence.remo= ve node);
=A0 =A0 =A0 =A0 =A0 =A0 =A0 th
=A0 =A0 =A0 end else Lwt.fail Generation.Invalid

=A0 =A0 When you call Activations.wait you are added to a 'sequence'= ;
=A0 =A0 (like a list) of people to wake up when the next event occurs. A =A0 =A0 typical driver would call Activations.wait in a loop, block for
=A0 =A0 an event, wake up, signal some other thread to do work and then
=A0 =A0 block again. However if the thread running the loop blocks
=A0 =A0 anywhere else, then the thread will not be added to the sequence =A0 =A0 straight away and any notifications that arrive during the gap
=A0 =A0 will be dropped. I noticed this when debugging my block backend
=A0 =A0 implementation. I think netif has this problem:

=A0 =A0 let listen nf fn =3D
=A0 =A0 =A0 (* Listen for the activation to poll the interface *)
=A0 =A0 =A0 let rec poll_t t =3D
=A0 =A0 =A0 =A0 lwt () =3D refill_requests t in
=A0 =A0 =A0 =A0 ^^^ blocks here, can miss events

=A0 =A0 =A0 =A0 rx_poll t fn;
=A0 =A0 =A0 =A0 tx_poll t;
=A0 =A0 =A0 =A0 (* Evtchn.notify nf.t.evtchn; *)
=A0 =A0 =A0 =A0 lwt new_t =3D
=A0 =A0 =A0 =A0 =A0 try_lwt
=A0 =A0 =A0 =A0 =A0 =A0 Activations.wait t.evtchn >> return t
=A0 =A0 =A0 =A0 =A0 with
=A0 =A0 =A0 =A0 =A0 | Generation.Invalid ->
=A0 =A0 =A0 =A0 =A0 =A0 Console.log_s "Waiting for plug in listen"= ; >>
=A0 =A0 =A0 =A0 =A0 =A0 wait_for_plug nf >>
=A0 =A0 =A0 =A0 =A0 =A0 Console.log_s "Done..." >>
=A0 =A0 =A0 =A0 =A0 =A0 return nf.t
=A0 =A0 =A0 =A0 in poll_t new_t
=A0 =A0 =A0 in
=A0 =A0 =A0 poll_t nf.t


=A0 =A0 I think we should change the semantics of Activations.wait to be =A0 =A0 more level-triggered rather than edge-triggered (i.e. more like
=A0 =A0 the underlying behaviour of xen) like this:

=A0 =A0 =A0type event
=A0 =A0 =A0(** a particular event *)

=A0 =A0 =A0val wait: Evtchn.t -> event option -> event Lwt.t
=A0 =A0 =A0(** [wait evtchn None] returns [Some e] where [e] is the latest<= br> =A0 =A0 event.
=A0 =A0 =A0 =A0 =A0[wait evtchn (Some e)] returns [Some e'] where [e= 9;] is a
=A0 =A0 later event than [e] *)

=A0 =A0 In the implementation we could have "type event =3D int" = and
=A0 =A0 maintain a counter of "number of times this event has been
=A0 =A0 signalled". When you call Activations.wait, you would pass in = the
=A0 =A0 number of the last event you saw, and the thread would block
=A0 =A0 until a new event is available. This way you wouldn't have to b= e
=A0 =A0 registered in the table when the event arrives.

=A0 =A0 2. SCHEDOP_poll has a low (arbitrary) nr_ports limit

=A0 =A0 http://xenbit= s.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Dxen/common/schedul= e.c;h=3Da8398bd9ed4827564bed4346e1fdfbb98ec5907e;hb=3D= c5e9596cd095e3b96a090002d9e6629a980904eb#l712

=A0 =A0 =A0704 static long do_poll(struct sched_poll *sched_poll)
=A0 =A0 =A0705 {
=A0 =A0 =A0706 =A0 =A0 struct vcpu =A0 *v =3D current;
=A0 =A0 =A0707 =A0 =A0 struct domain *d =3D v->domain;
=A0 =A0 =A0708 =A0 =A0 evtchn_port_t =A0port;
=A0 =A0 =A0709 =A0 =A0 long =A0 =A0 =A0 =A0 =A0 rc;
=A0 =A0 =A0710 =A0 =A0 unsigned int =A0 i;
=A0 =A0 =A0711
=A0 =A0 =A0712 =A0 =A0 /* Fairly arbitrary limit. */
=A0 =A0 =A0713 =A0 =A0 if ( sched_poll->nr_ports > 128 )
=A0 =A0 =A0714 =A0 =A0 =A0 =A0 return -EINVAL;

=A0 =A0 The total number of available event channels for a 64-bit guest
=A0 =A0 is 4096 using the current ABI (a new interface is under
=A0 =A0 development which allows even more). The limit of 128 is probably =A0 =A0 imposed to limit the amount of time the hypercall takes, to avoid =A0 =A0 hitting scalability limits like you do in userspace with select().<= br>
=A0 =A0 One of the use-cases I'd like to use Mirage for is to run backe= nd
=A0 =A0 services (like xenstore or blkback) for all the domains on a
=A0 =A0 host. This requires at least one event channel per client domain. =A0 =A0 We routinely run ~300 VMs/host, so the 128 limit is too small.
=A0 =A0 Plus a quick grep around Linux shows that it doesn't use
=A0 =A0 SCHEDOP_poll very much-- I think we should focus on using the
=A0 =A0 hypercalls that other OSes are using, for maximum chance of success= .

=A0 =A0 So I think we should switch from select()-like behaviour using
=A0 =A0 SCHEDOP_poll to interrupt-based delivery using SCHEDOP_block. I
=A0 =A0 note that upstream mini-os does this by default too. I'll take = a
=A0 =A0 look at this.

=A0 =A0 Cheers,
=A0 =A0 Dave



=A0 =A0 On Fri, Sep 13, 2013 at 11:50 PM, Dimosthenis Pediaditakis
=A0 =A0 <dimosthenis.pediaditakis@cl.cam.ac.uk
=A0 =A0 <mailto:dimosthenis.pediaditakis@cl.cam.ac.uk>>= wrote:

=A0 =A0 =A0 =A0 Hi all,
=A0 =A0 =A0 =A0 The last few days I've been trying to pin-down the
=A0 =A0 =A0 =A0 performance issues of the Mirage network stack, when runnin= g
=A0 =A0 =A0 =A0 over Xen.
=A0 =A0 =A0 =A0 When trying to push net-direct to its limits, random
=A0 =A0 =A0 =A0 transmissions stall for anywhere between 0.1sec-4sec
=A0 =A0 =A0 =A0 (especially at the sender).

=A0 =A0 =A0 =A0 After some experimentation, I believe that those time-outs<= br> =A0 =A0 =A0 =A0 occur because netif is not (always) notified (via
=A0 =A0 =A0 =A0 Activations) about freed TX-ring slots.
=A0 =A0 =A0 =A0 It seems that these events (intermittently) don't reach= the
=A0 =A0 =A0 =A0 guest domain's front-end driver.

=A0 =A0 =A0 =A0 AFAIK Activations.wait() currently blocks waiting for an =A0 =A0 =A0 =A0 event on the port belonging to the event channel for the ne= tif.
=A0 =A0 =A0 =A0 This event is delivered to Activations.run via Main.run.aux=
=A0 =A0 =A0 =A0 which is invoked via the callback in app_main() of
=A0 =A0 =A0 =A0 runtime/kernel/main.c
=A0 =A0 =A0 =A0 The problem I observed was that using "SCHEDOP_poll&qu= ot; without
=A0 =A0 =A0 =A0 masking the intended events, the hypervisor didn't &quo= t;wake-up"
=A0 =A0 =A0 =A0 the blocked domain upon new event availability.
=A0 =A0 =A0 =A0 The requirement for event-masking when using "SCHEDOP_= poll"
=A0 =A0 =A0 =A0 is also mentioned in the Xen documentation.

=A0 =A0 =A0 =A0 I've produced a patch that seems to fix the above errat= ic
=A0 =A0 =A0 =A0 behavior.
=A0 =A0 =A0 =A0 Now I am able to consistently achieve higher speeds (up to<= br> =A0 =A0 =A0 =A0 2.75Gbps DomU2Domu). Please, have a look at my repo:
=A0 =A0 =A0 =A0 https://github.com/dimosped/mirage-platform
=A0 =A0 =A0 =A0 It will be helpful to use big-enough txqueuelen values for<= br> =A0 =A0 =A0 =A0 your VIFs, as the current TCP implementation doesn't li= ke
=A0 =A0 =A0 =A0 much losses at high datarates. The default size in my syste= m
=A0 =A0 =A0 =A0 was only 32.

=A0 =A0 =A0 =A0 I have also modified the mirage-net-direct by adding per-fl= ow
=A0 =A0 =A0 =A0 TCP debug logging. This has helped me to better understand<= br> =A0 =A0 =A0 =A0 and pin-down the problem.
=A0 =A0 =A0 =A0 You can grab the modified sources here:
=A0 =A0 =A0 =A0 https://github.com/dimosped/mirage-net
=A0 =A0 =A0 =A0 Be aware that logging big volumes of data for a TCP flow wi= ll
=A0 =A0 =A0 =A0 require big enough memory. Nevertheless, it only barely
=A0 =A0 =A0 =A0 affects performance.

=A0 =A0 =A0 =A0 The iperf benchmark sources can be found here:
=A0 =A0 =A0 =A0 https://github.com/dimosped/iperf-mirage
=A0 =A0 =A0 =A0 I've included as much info as possible in the README fi= le.
=A0 =A0 =A0 =A0 This should be sufficient to get you started and replicate = my
=A0 =A0 =A0 =A0 experiments.

=A0 =A0 =A0 =A0 In the iperf-mirage repo there is also a Python tool, which=
=A0 =A0 =A0 =A0 you can use to automatically generate plots based on the =A0 =A0 =A0 =A0 collected TCP debug info (I include also a sample dataset i= n
=A0 =A0 =A0 =A0 data/ ):
=A0 =A0 =A0 =A0 https://github.com/dimosped/<= /u>iperf-mirage/tree/master/tools/MirageTcpVis
=A0 =A0 =A0 =A0 For really large datasets, the script might be slow. I need=
=A0 =A0 =A0 =A0 to switch into using NumPy arrays at some point...

=A0 =A0 =A0 =A0 Please keep in mind that I am a newbie in Xen/Mirage so you= r
=A0 =A0 =A0 =A0 comments/input are more than welcome.

=A0 =A0 =A0 =A0 Regards,
=A0 =A0 =A0 =A0 Dimos




=A0 =A0 =A0 =A0 ------------------------------------------------
=A0 =A0 =A0 =A0 =A0 =A0MORE TECHNICAL DETAILS
=A0 =A0 =A0 =A0 ------------------------------------------------


=A0 =A0 =A0 =A0 ----------------------------------------------------= -------------

=A0 =A0 =A0 =A0 =3D=3D=3D How (I think) Mirage and XEN scheduling works =3D= =3D=3D
=A0 =A0 =A0 =A0 ----------------------------------------------------= -------------

=A0 =A0 =A0 =A0 =A0- When Netif receives a writev request, it checks if the= TX
=A0 =A0 =A0 =A0 ring has enough empty space (for the producer) for the data=
=A0 =A0 =A0 =A0 =A0 =A0 - If there is not enough space, it block-waits (via=
=A0 =A0 =A0 =A0 Activations.wait) for an event on the port mapped to the =A0 =A0 =A0 =A0 netif (and bound to the backend driver)
=A0 =A0 =A0 =A0 =A0 =A0 - Otherwise it pushes the request.
=A0 =A0 =A0 =A0 - =A0Activations are notified (via run) from "aux ()&q= uot; in
=A0 =A0 =A0 =A0 Main.run. Once notified, it means that the waiting netif ca= n
=A0 =A0 =A0 =A0 proceed, check again the ring for free space, write a new =A0 =A0 =A0 =A0 request, and send an event to the backend.
=A0 =A0 =A0 =A0 - Main.run.aux is registered as a callback (under name
=A0 =A0 =A0 =A0 "OS.Main.run") and is invoked in xen/runtime/kern= el/main.c
=A0 =A0 =A0 =A0 (in app_main() loop). As long as the Mirage guest domain is=
=A0 =A0 =A0 =A0 scheduled, this loop keeps running.
=A0 =A0 =A0 =A0 - However, in Main.run.aux, the Mirage guest domain is
=A0 =A0 =A0 =A0 blocked via "block_domain timeout" if the main th= read has no
=A0 =A0 =A0 =A0 task to perform.
=A0 =A0 =A0 =A0 - In turn, "block_domain" invokes caml_block_doma= in() =A0found
=A0 =A0 =A0 =A0 in xen/runtime/kernel/main.c, which issues a
=A0 =A0 =A0 =A0 "HYPERVISOR_sched_op(SCHEDOP_poll, &sched_p= oll);" hypercall

=A0 =A0 =A0 =A0 -------------------------------------
=A0 =A0 =A0 =A0 =3D=3D=3D Polling mode issue =3D=3D=3D
=A0 =A0 =A0 =A0 -------------------------------------
=A0 =A0 =A0 =A0 In my opinion, and based on debug information, it seems tha= t
=A0 =A0 =A0 =A0 the problem is that Mirage uses "SCHEDOP_poll" wi= thout
=A0 =A0 =A0 =A0 masking the event channels.
=A0 =A0 =A0 =A0 The XEN documentation clearly states that with "SCHEDO= P_poll"
=A0 =A0 =A0 =A0 the domain would yield until either
=A0 =A0 =A0 =A0 =A0 a) an event is pending on the polled channels and
=A0 =A0 =A0 =A0 =A0 b) the timeout time (given in nanoseconds, is not durat= ion
=A0 =A0 =A0 =A0 but absolute system time) is reached
=A0 =A0 =A0 =A0 It also states that this SCHEDOP_poll can only be be execut= ed
=A0 =A0 =A0 =A0 when the guest has delivery of events disabled.

=A0 =A0 =A0 =A0 In Mirage, netif events are not masked and therefore they =A0 =A0 =A0 =A0 never "wakeup" the guest domain.
=A0 =A0 =A0 =A0 The guest only wakes-up whenever a thread is scheduled
to =A0 =A0 =A0 =A0 wakeup in Time.SleepQueue (e.g. a TCP timer).
=A0 =A0 =A0 =A0 Once the guest is scheduled again, it completes any
=A0 =A0 =A0 =A0 outstanding tasks, sends any packets pending, and whenever = a)
=A0 =A0 =A0 =A0 the TX ring gets full, or =A0b)the hypervisor =A0it, c) =A0= it will
=A0 =A0 =A0 =A0 sleep again.
=A0 =A0 =A0 =A0 To further support the above, whenever I press buttons via<= br> =A0 =A0 =A0 =A0 XEN-console while the mirage-sender is running, the executi= on
=A0 =A0 =A0 =A0 completes faster.

=A0 =A0 =A0 =A0 ----------------
=A0 =A0 =A0 =A0 =3D=3D=3D Fix =3D=3D=3D
=A0 =A0 =A0 =A0 ----------------
=A0 =A0 =A0 =A0 There are multiple ways to mask events (e.g. at VCPU level,=
=A0 =A0 =A0 =A0 event level etc).
=A0 =A0 =A0 =A0 As a quick hack I replaced "Eventchn.unmask h evtchn;&= quot; in
=A0 =A0 =A0 =A0 Netif.plug_inner with Eventchn.mask h evtchn (which I had t= o
=A0 =A0 =A0 =A0 create, both in Eventchn and =A0as a stub in
=A0 =A0 =A0 =A0 xen/runtime/kernel/eventchn_stubs.c).
=A0 =A0 =A0 =A0 See:
=A0 =A0 =A0 =A0 https://gith= ub.com/dimosped/mirage-platform/commit/6d4d3f0403497f07fde4db= 6f4cb63665a8bf8e26








=A0 =A0 -- =A0 =A0 Dave Scott




--
Dave Scott




--
= Dave Scott
--047d7b1630a94c282c04e7e91b29-- From thomas.gazagnaire@gmail.com Fri Oct 04 13:29:49 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VS4Vx-0002vX-EM (Exim 4.70) (return-path ); Fri, 04 Oct 2013 13:29:49 +0100 X-Cam-SpamDetails: score -0.6 from SpamAssassin-3.3.2-1528751 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [74.125.82.182 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (thomas.gazagnaire[at]gmail.com) * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-we0-f182.google.com ([74.125.82.182]:36865) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with esmtp id 1VS4Vw-0008A4-iz (Exim 4.80_167-5a66dd3) (return-path ); Fri, 04 Oct 2013 13:29:49 +0100 Received: by mail-we0-f182.google.com with SMTP id t61so3623017wes.41 for ; Fri, 04 Oct 2013 05:29:48 -0700 (PDT) X-Received: by 10.180.211.111 with SMTP id nb15mr7078924wic.55.1380889788733; Fri, 04 Oct 2013 05:29:48 -0700 (PDT) Received: from [10.70.97.39] ([213.30.181.210]) by mx.google.com with ESMTPSA id mw9sm15370732wib.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Oct 2013 05:29:47 -0700 (PDT) Sender: Thomas Gazagnaire Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [ocl-staff] Using Merlin from Vim From: Thomas Gazagnaire In-Reply-To: <7726EDFD-C7E0-411A-9282-F80964C9215A@nottingham.ac.uk> Date: Fri, 4 Oct 2013 14:29:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <087DB6B5-69F7-4BE5-AAEA-C2FD53190F29@gazagnaire.org> References: <4FD883E8-F81B-40B5-8017-6F2CDFA35097@nottingham.ac.uk> <7726EDFD-C7E0-411A-9282-F80964C9215A@nottingham.ac.uk> To: Richard Mortier X-Mailer: Apple Mail (2.1510) Cc: =?windows-1252?Q?Daniel_B=FCnzli?= , OCaml Labs , "cl-mirage@lists.cam.ac.uk List" , Anil Madhavapeddy X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 12:29:49 -0000 Content-Length: 1083 Lines: 42 > does ocp-indent know about lwt syntax extensions? (and others come to = that=85) You can add to your ~/.emacs: (custom-set-variables '(ocp-indent-syntax (quote ("lwt")))) or "syntax =3D lwt" in your .ocp-indent -- Thomas >=20 > --=20 > Cheers, >=20 > R. >=20 >=20 >=20 >=20 > This message and any attachment are intended solely for the addressee = and may contain confidential information. If you have received this = message in error, please send it back to me, and immediately delete it. = Please do not use, copy or disclose the information contained in this = message or in any attachment. Any views or opinions expressed by the = author of this email do not necessarily reflect the views of the = University of Nottingham. >=20 > This message has been checked for viruses but the contents of an = attachment > may still contain software viruses which could damage your computer = system, you are advised to perform your own checks. Email communications = with the University of Nottingham may be monitored as permitted by UK = legislation. >=20 >=20 >=20 >=20 >=20 From anil@recoil.org Sun Oct 06 19:28:27 2013 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VSt47-0007QH-50 (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Sun, 06 Oct 2013 19:28:27 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1529413 X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:4908 helo=dark.recoil.org) by ppsw-32.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with smtp id 1VSt46-0003b7-10 (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Sun, 06 Oct 2013 19:28:27 +0100 Received: (qmail 27571 invoked by uid 634); 6 Oct 2013 18:28:25 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from cpc7-cmbg14-2-0-cust238.5-4.cable.virginmedia.com (HELO [192.168.1.62]) (86.30.244.239) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Sun, 06 Oct 2013 19:28:25 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) Subject: Re: Travis and OCaml, and even ARM From: Anil Madhavapeddy In-Reply-To: <567B1520-20C5-4C0D-B650-FF06EECDC790@recoil.org> Date: Sun, 6 Oct 2013 19:28:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4EA7CF4A-0B87-4E89-B4E0-A4D0402E196B@recoil.org> References: <43EF2528-2F11-46F6-8E08-2180C6742508@recoil.org> <567B1520-20C5-4C0D-B650-FF06EECDC790@recoil.org> To: "cl-mirage@lists.cam.ac.uk List" X-Mailer: Apple Mail (2.1811) X-Virus-Checked: Checked by ClamAV on dark.recoil.org X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 18:28:27 -0000 Content-Length: 2366 Lines: 59 And another followup -- Travis is now building the Mirage homepage upon = every push, and committing the resulting unikernel to a GitHub state = repository that is polled by the live machines. So they just 'git pull' = regularly now and refresh the kernel when they spot a new one. http://anil.recoil.org/2013/10/06/travis-secure-ssh-integration.html The state repository is here: https://github.com/mirage/mirage-www-deployment -anil On 1 Oct 2013, at 23:19, Anil Madhavapeddy wrote: > We mentioned on the call today that Travis might not be able to build = the Xen backend since it's an i386 VM, but it does work fine (since we = don't actually use any system libraries in the build) >=20 > https://travis-ci.org/mirage/mirage-www/jobs/11897190 >=20 > So we can use Travis for a publishing platform too... >=20 > -anil >=20 > On 30 Sep 2013, at 17:04, Anil Madhavapeddy wrote: >=20 >> Good news everyone! I just had an exciting build failure that I = wanted to share with you. >>=20 >> Dave and I have been switching a number of our OCaml GitHub = repositories to use Travis continuous integration testing. This is good = enough for any tests that can run in an Ubuntu/i386 VM without hosting = any infrastructure ourselves. Details here: >> http://anil.recoil.org/2013/09/30/travis-and-ocaml.html >>=20 >> If you look at the bottom there, I used Ian Campbell's foreign-chroot = instructions to get OCaml/ARM working too. I've been activating this on = various Mirage repositories to test our builds on ARM without having to = have a box available, and so this is making it much easier to reproduce = bugs such as this shared-memory-ring failure: >> https://github.com/djs55/shared-memory-ring/issues/6 >> ...just via this Travis log: >> https://travis-ci.org/mirage/mirage-platform/jobs/11964317 >>=20 >> Now we just have to fix it, but that's pretty easy right? :-) >>=20 >> Are there any brave souls out there that might try to figure out how = to get a Xen environment working from within Travis? It would only need = to boot Mirage kernels, so it's ok to be a bit slow... >>=20 >> (I expect to finish the conversion of all the Mirage release = repositories to Travis this week, and it would be great to see XAPI = repos like xenopsd also activated, which I believe Dave is working on). >>=20 >> -anil >=20 >=20 From anil@recoil.org Mon Oct 07 12:50:07 2013 Received: from ppsw-mx-f.csi.cam.ac.uk ([131.111.8.149] helo=ppsw-42.csi.cam.ac.uk) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VT9KB-00003e-Go (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 07 Oct 2013 12:50:07 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1529602 * 0.0 HTML_MESSAGE BODY: HTML included in message X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:20801 helo=dark.recoil.org) by ppsw-42.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with smtp id 1VT9K9-0004DP-72 (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 07 Oct 2013 12:50:07 +0100 Received: (qmail 10374 invoked by uid 634); 7 Oct 2013 11:50:03 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED,HTML_MESSAGE X-Spam-Check-By: dark.recoil.org Received: from volstagg-0.srg.cl.cam.ac.uk (HELO flick.office) (128.232.32.232) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Mon, 07 Oct 2013 12:50:00 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_4D5C056B-3D64-446C-B843-943115AB1290" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) Subject: Re: Improving the network-stack performance over Xen From: Anil Madhavapeddy In-Reply-To: Date: Mon, 7 Oct 2013 12:49:58 +0100 Message-Id: <12DF22A0-D4A6-412C-9A41-BF4D3775CD89@recoil.org> References: <5233969C.1080802@cl.cam.ac.uk> <5240EC98.3060509@cl.cam.ac.uk> <5241AFF2.5070001@cl.cam.ac.uk> <20131004095711.GI14429@dark.recoil.org> <524EA18D.2090609@cl.cam.ac.uk> To: David Scott X-Mailer: Apple Mail (2.1811) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: Dimosthenis Pediaditakis , Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 11:50:07 -0000 Content-Length: 39858 Lines: 802 --Apple-Mail=_4D5C056B-3D64-446C-B843-943115AB1290 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thanks! All this is merged and in the Mirage-0.9.7 release (now on = OPAM). I've also merged Haris' NS3 work into 0.9.8, so some quickfire = releases coming up shortly... -anil On 4 Oct 2013, at 13:04, David Scott wrote: > Great. Jon pointed out that I've almost-certainly broken suspend-- = I'll look at that now. >=20 >=20 > On Fri, Oct 4, 2013 at 12:07 PM, Dimosthenis Pediaditakis = wrote: > As far as Network stack performance, domain scheduling and console = operation goes, I haven't observed any issues so far. >=20 > D. >=20 >=20 > On 04/10/13 10:57, Anil Madhavapeddy wrote: > Closing the loop on this; is Dave's Activations patch considered > safe-to-merge now? >=20 > -anil >=20 > On Tue, Sep 24, 2013 at 04:29:54PM +0100, Dimosthenis Pediaditakis = wrote: > Hi again, > as promised, here are some data from a DomU-2-DomU iperf flow, > pushing 0.8Gbits in 0.38sec (~2.1Gbps): > http://www.cl.cam.ac.uk/~dp463/files/mirageNetData.tar.gz >=20 > Note that I've used a txqueuelen of 500 for each VIF in dom0. > Also, with TCP debug disabled, speeds reach >=3D 2.5Gbps. >=20 > Everythin seems smoother. Didn't observe any odd TX delay spikes > caused by netif blocking. >=20 > Regards, > D. >=20 >=20 >=20 > On 24/09/13 02:36, Dimosthenis Pediaditakis wrote: > Hi David, > sorry for the absence. I attended a Workshop on SDN last week, and > today was quite a busy day. > I had a look in the interrupt branch of your mirage-platform repo, > cloned it and ran a few experiments. > The speeds I got were consistently between 2.45-2.6Gbps on my > machine (i7-3770, dual ch. DDR3 1600), which is a very good > number. > Unfortunatelly, I didn't have the time to further stress test it > and generate any TCP stack plots. This is the top item in my TODO > list. >=20 > I also went briefly through the additions/modifications in > hypervisor.c, main.c, activations.ml, netif.ml, main.ml > It seems that SCHEDOP_block + no-op handling + evtchn_poll + > VIRQ_TIMER-bind along with the rewriting of Activations (fix for > the silently dropped events) have done the trick. >=20 > A couple of questions: > - In file hypervisor.c, what is the purpose of " > force_evtchn_callback" ? I've seen it only being invoked via > "__sti()" and "__restore_flags()" >=20 > - In the updated design, when an event is received, then: > SCHEDOP_block returns, > event_poll is then invoked, and > finally Main.aux() is called. > Activations.run() is invoked in Main.aux() if no threads are > scheduled, and subsequently the domain is blocked again (until a > timer interrupt, or reception of another event). My question is > why don't we re-check right after "Activations.run()" the state of > t ? For example if packets are waiting to be sent, and netif gets > unblocked, why we block the domain directly again? >=20 > Also, thanks thanks for the credits in you updates :-) >=20 > D. >=20 >=20 >=20 > On 19/09/13 22:41, David Scott wrote: > Hi Dimos, >=20 > I've created a new patch set based on a mix of your ideas and mine: >=20 > https://github.com/mirage/mirage-platform/pull/58 >=20 > I've proposed switching to SCHEDOP_block with interrupts > enabled. Unlike in regular Mini-OS I don't think we need to do > anything in the hypervisor_callback, because we already have > code to poll the evtchn pending bits in evtchn_poll-- so we're a > bit of a hybrid: interrupts on for wakeups but the whole OS is > still based around a select/poll-style loop. I've left all event > channels unmasked and used the event_upcall_mask to turn on/off > event delivery globally. I've revamped the OCaml Activations > interface to remove one source of missing events. >=20 > So far the code is working ok in my testing. I ran mirage-iperf > and am getting 1642002 KBit/sec on my test hardware -- I don't > know if this is considered good or bad! I ran your instrumented > version (thanks for the exhaustive instructions btw) and it drew > some pretty graphs, but I'm not enough of a TCP expert to > interpret them properly. >=20 > Could you give this a go in your test environment and let me > know what you think? >=20 > I'm extremely suspicious of the console code -- it shouldn't be > necessary to include a delay in the print loop; that's > definitely worth investigating. >=20 > Cheers, > Dave >=20 >=20 > On Thu, Sep 19, 2013 at 11:02 AM, David Scott > > wrote: >=20 > Hi Dimos, >=20 > Thanks for looking into this! Thinking about it, I think we have > several problems. >=20 > 1. I think the Activations.wait API is difficult to use / unsafe: >=20 > (* Block waiting for an event to occur on a particular port *) > let wait evtchn =3D > if Eventchn.is_valid evtchn then begin > let port =3D Eventchn.to_int evtchn in > let th, u =3D Lwt.task () in > let node =3D Lwt_sequence.add_l u event_cb.(port) in > Lwt.on_cancel th (fun _ -> Lwt_sequence.remove node); > th > end else Lwt.fail Generation.Invalid >=20 > When you call Activations.wait you are added to a 'sequence' > (like a list) of people to wake up when the next event occurs. A > typical driver would call Activations.wait in a loop, block for > an event, wake up, signal some other thread to do work and then > block again. However if the thread running the loop blocks > anywhere else, then the thread will not be added to the sequence > straight away and any notifications that arrive during the gap > will be dropped. I noticed this when debugging my block backend > implementation. I think netif has this problem: >=20 > let listen nf fn =3D > (* Listen for the activation to poll the interface *) > let rec poll_t t =3D > lwt () =3D refill_requests t in > ^^^ blocks here, can miss events >=20 > rx_poll t fn; > tx_poll t; > (* Evtchn.notify nf.t.evtchn; *) > lwt new_t =3D > try_lwt > Activations.wait t.evtchn >> return t > with > | Generation.Invalid -> > Console.log_s "Waiting for plug in listen" >> > wait_for_plug nf >> > Console.log_s "Done..." >> > return nf.t > in poll_t new_t > in > poll_t nf.t >=20 >=20 > I think we should change the semantics of Activations.wait to be > more level-triggered rather than edge-triggered (i.e. more like > the underlying behaviour of xen) like this: >=20 > type event > (** a particular event *) >=20 > val wait: Evtchn.t -> event option -> event Lwt.t > (** [wait evtchn None] returns [Some e] where [e] is the latest > event. > [wait evtchn (Some e)] returns [Some e'] where [e'] is a > later event than [e] *) >=20 > In the implementation we could have "type event =3D int" and > maintain a counter of "number of times this event has been > signalled". When you call Activations.wait, you would pass in the > number of the last event you saw, and the thread would block > until a new event is available. This way you wouldn't have to be > registered in the table when the event arrives. >=20 > 2. SCHEDOP_poll has a low (arbitrary) nr_ports limit >=20 > = http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Dxen/common/schedul= e.c;h=3Da8398bd9ed4827564bed4346e1fdfbb98ec5907e;hb=3Dc5e9596cd095e3b96a09= 0002d9e6629a980904eb#l712 >=20 > 704 static long do_poll(struct sched_poll *sched_poll) > 705 { > 706 struct vcpu *v =3D current; > 707 struct domain *d =3D v->domain; > 708 evtchn_port_t port; > 709 long rc; > 710 unsigned int i; > 711 > 712 /* Fairly arbitrary limit. */ > 713 if ( sched_poll->nr_ports > 128 ) > 714 return -EINVAL; >=20 > The total number of available event channels for a 64-bit guest > is 4096 using the current ABI (a new interface is under > development which allows even more). The limit of 128 is probably > imposed to limit the amount of time the hypercall takes, to avoid > hitting scalability limits like you do in userspace with select(). >=20 > One of the use-cases I'd like to use Mirage for is to run backend > services (like xenstore or blkback) for all the domains on a > host. This requires at least one event channel per client domain. > We routinely run ~300 VMs/host, so the 128 limit is too small. > Plus a quick grep around Linux shows that it doesn't use > SCHEDOP_poll very much-- I think we should focus on using the > hypercalls that other OSes are using, for maximum chance of = success. >=20 > So I think we should switch from select()-like behaviour using > SCHEDOP_poll to interrupt-based delivery using SCHEDOP_block. I > note that upstream mini-os does this by default too. I'll take a > look at this. >=20 > Cheers, > Dave >=20 >=20 >=20 > On Fri, Sep 13, 2013 at 11:50 PM, Dimosthenis Pediaditakis > > wrote: >=20 > Hi all, > The last few days I've been trying to pin-down the > performance issues of the Mirage network stack, when running > over Xen. > When trying to push net-direct to its limits, random > transmissions stall for anywhere between 0.1sec-4sec > (especially at the sender). >=20 > After some experimentation, I believe that those time-outs > occur because netif is not (always) notified (via > Activations) about freed TX-ring slots. > It seems that these events (intermittently) don't reach the > guest domain's front-end driver. >=20 > AFAIK Activations.wait() currently blocks waiting for an > event on the port belonging to the event channel for the = netif. > This event is delivered to Activations.run via Main.run.aux > which is invoked via the callback in app_main() of > runtime/kernel/main.c > The problem I observed was that using "SCHEDOP_poll" without > masking the intended events, the hypervisor didn't "wake-up" > the blocked domain upon new event availability. > The requirement for event-masking when using "SCHEDOP_poll" > is also mentioned in the Xen documentation. >=20 > I've produced a patch that seems to fix the above erratic > behavior. > Now I am able to consistently achieve higher speeds (up to > 2.75Gbps DomU2Domu). Please, have a look at my repo: > https://github.com/dimosped/mirage-platform > It will be helpful to use big-enough txqueuelen values for > your VIFs, as the current TCP implementation doesn't like > much losses at high datarates. The default size in my system > was only 32. >=20 > I have also modified the mirage-net-direct by adding per-flow > TCP debug logging. This has helped me to better understand > and pin-down the problem. > You can grab the modified sources here: > https://github.com/dimosped/mirage-net > Be aware that logging big volumes of data for a TCP flow will > require big enough memory. Nevertheless, it only barely > affects performance. >=20 > The iperf benchmark sources can be found here: > https://github.com/dimosped/iperf-mirage > I've included as much info as possible in the README file. > This should be sufficient to get you started and replicate my > experiments. >=20 > In the iperf-mirage repo there is also a Python tool, which > you can use to automatically generate plots based on the > collected TCP debug info (I include also a sample dataset in > data/ ): > = https://github.com/dimosped/iperf-mirage/tree/master/tools/MirageTcpVis > For really large datasets, the script might be slow. I need > to switch into using NumPy arrays at some point... >=20 > Please keep in mind that I am a newbie in Xen/Mirage so your > comments/input are more than welcome. >=20 > Regards, > Dimos >=20 >=20 >=20 >=20 > ------------------------------------------------ > MORE TECHNICAL DETAILS > ------------------------------------------------ >=20 >=20 > = ----------------------------------------------------------------- >=20 > =3D=3D=3D How (I think) Mirage and XEN scheduling works =3D=3D=3D= > = ----------------------------------------------------------------- >=20 > - When Netif receives a writev request, it checks if the TX > ring has enough empty space (for the producer) for the data > - If there is not enough space, it block-waits (via > Activations.wait) for an event on the port mapped to the > netif (and bound to the backend driver) > - Otherwise it pushes the request. > - Activations are notified (via run) from "aux ()" in > Main.run. Once notified, it means that the waiting netif can > proceed, check again the ring for free space, write a new > request, and send an event to the backend. > - Main.run.aux is registered as a callback (under name > "OS.Main.run") and is invoked in xen/runtime/kernel/main.c > (in app_main() loop). As long as the Mirage guest domain is > scheduled, this loop keeps running. > - However, in Main.run.aux, the Mirage guest domain is > blocked via "block_domain timeout" if the main thread has no > task to perform. > - In turn, "block_domain" invokes caml_block_domain() found > in xen/runtime/kernel/main.c, which issues a > "HYPERVISOR_sched_op(SCHEDOP_poll, &sched_poll);" hypercall >=20 > ------------------------------------- > =3D=3D=3D Polling mode issue =3D=3D=3D > ------------------------------------- > In my opinion, and based on debug information, it seems that > the problem is that Mirage uses "SCHEDOP_poll" without > masking the event channels. > The XEN documentation clearly states that with "SCHEDOP_poll" > the domain would yield until either > a) an event is pending on the polled channels and > b) the timeout time (given in nanoseconds, is not duration > but absolute system time) is reached > It also states that this SCHEDOP_poll can only be be executed > when the guest has delivery of events disabled. >=20 > In Mirage, netif events are not masked and therefore they > never "wakeup" the guest domain. > The guest only wakes-up whenever a thread is scheduled > to wakeup in Time.SleepQueue (e.g. a TCP timer). > Once the guest is scheduled again, it completes any > outstanding tasks, sends any packets pending, and whenever a) > the TX ring gets full, or b)the hypervisor it, c) it will > sleep again. > To further support the above, whenever I press buttons via > XEN-console while the mirage-sender is running, the execution > completes faster. >=20 > ---------------- > =3D=3D=3D Fix =3D=3D=3D > ---------------- > There are multiple ways to mask events (e.g. at VCPU level, > event level etc). > As a quick hack I replaced "Eventchn.unmask h evtchn;" in > Netif.plug_inner with Eventchn.mask h evtchn (which I had to > create, both in Eventchn and as a stub in > xen/runtime/kernel/eventchn_stubs.c). > See: > = https://github.com/dimosped/mirage-platform/commit/6d4d3f0403497f07fde4db6= f4cb63665a8bf8e26 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -- Dave Scott >=20 >=20 >=20 >=20 > --=20 > Dave Scott >=20 >=20 >=20 >=20 > --=20 > Dave Scott --Apple-Mail=_4D5C056B-3D64-446C-B843-943115AB1290 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Thanks!  All this is merged and in the Mirage-0.9.7 release (now on OPAM).  I've also merged Haris' NS3 work into 0.9.8, so some quickfire releases coming up shortly...

-anil

On 4 Oct 2013, at 13:04, David Scott <scott.dj@gmail.com> wrote:

Great. Jon pointed out that I've almost-certainly broken suspend-- I'll look at that now.


On Fri, Oct 4, 2013 at 12:07 PM, Dimosthenis Pediaditakis <dimosthenis.pediaditakis@cl.cam.ac.uk> wrote:
As far as Network stack performance, domain scheduling and console operation goes, I haven't observed any issues so far.

D.


On 04/10/13 10:57, Anil Madhavapeddy wrote:
Closing the loop on this; is Dave's Activations patch considered
safe-to-merge now?

-anil

On Tue, Sep 24, 2013 at 04:29:54PM +0100, Dimosthenis Pediaditakis wrote:
Hi again,
as promised, here are some data from a DomU-2-DomU iperf flow,
pushing 0.8Gbits in 0.38sec (~2.1Gbps):
http://www.cl.cam.ac.uk/~dp463/files/mirageNetData.tar.gz

Note that I've used a txqueuelen of 500 for each VIF in dom0.
Also, with TCP debug disabled, speeds reach >= 2.5Gbps.

Everythin seems smoother. Didn't observe any odd TX delay spikes
caused by netif blocking.

Regards,
D.



On 24/09/13 02:36, Dimosthenis Pediaditakis wrote:
Hi David,
sorry for the absence. I attended a Workshop on SDN last week, and
today was quite a busy day.
I had a look in the interrupt branch of your mirage-platform repo,
cloned it and ran a few experiments.
The speeds I got were consistently between 2.45-2.6Gbps on my
machine (i7-3770, dual ch. DDR3 1600), which is a very good
number.
Unfortunatelly, I didn't have the time to further stress test it
and generate any TCP stack plots. This is the top item in my TODO
list.

I also went briefly through the additions/modifications in
hypervisor.c, main.c, activations.ml, netif.ml, main.ml
It seems that SCHEDOP_block + no-op handling + evtchn_poll  +
VIRQ_TIMER-bind  along with the rewriting of Activations (fix for
the silently dropped events) have done the trick.

A couple of questions:
- In file hypervisor.c, what is the purpose of "
force_evtchn_callback" ? I've seen it only being invoked via
"__sti()" and "__restore_flags()"

- In the updated design, when an event is received, then:
    SCHEDOP_block returns,
    event_poll is then invoked, and
    finally Main.aux() is called.
  Activations.run() is invoked in Main.aux() if no threads are
scheduled, and subsequently the domain is blocked again (until a
timer interrupt, or reception of another event).  My question is
why don't we re-check right after "Activations.run()" the state of
t ?  For example if packets are waiting to be sent, and netif gets
unblocked, why we block the domain directly again?

Also, thanks thanks for the credits in you updates :-)

D.



On 19/09/13 22:41, David Scott wrote:
Hi Dimos,

I've created a new patch set based on a mix of your ideas and mine:

https://github.com/mirage/mirage-platform/pull/58

I've proposed switching to SCHEDOP_block with interrupts
enabled. Unlike in regular Mini-OS I don't think we need to do
anything in the hypervisor_callback, because we already have
code to poll the evtchn pending bits in evtchn_poll-- so we're a
bit of a hybrid: interrupts on for wakeups but the whole OS is
still based around a select/poll-style loop. I've left all event
channels unmasked and used the event_upcall_mask to turn on/off
event delivery globally. I've revamped the OCaml Activations
interface to remove one source of missing events.

So far the code is working ok in my testing. I ran mirage-iperf
and am getting 1642002 KBit/sec on my test hardware -- I don't
know if this is considered good or bad! I ran your instrumented
version (thanks for the exhaustive instructions btw) and it drew
some pretty graphs, but I'm not enough of a TCP expert to
interpret them properly.

Could you give this a go in your test environment and let me
know what you think?

I'm extremely suspicious of the console code -- it shouldn't be
necessary to include a delay in the print loop; that's
definitely worth investigating.

Cheers,
Dave


On Thu, Sep 19, 2013 at 11:02 AM, David Scott
<scott.dj@gmail.com <mailto:scott.dj@gmail.com>> wrote:

    Hi Dimos,

    Thanks for looking into this! Thinking about it, I think we have
    several problems.

    1. I think the Activations.wait API is difficult to use / unsafe:

    (* Block waiting for an event to occur on a particular port *)
    let wait evtchn =
      if Eventchn.is_valid evtchn then begin
              let port = Eventchn.to_int evtchn in
              let th, u = Lwt.task () in
              let node = Lwt_sequence.add_l u event_cb.(port) in
              Lwt.on_cancel th (fun _ -> Lwt_sequence.remove node);
              th
      end else Lwt.fail Generation.Invalid

    When you call Activations.wait you are added to a 'sequence'
    (like a list) of people to wake up when the next event occurs. A
    typical driver would call Activations.wait in a loop, block for
    an event, wake up, signal some other thread to do work and then
    block again. However if the thread running the loop blocks
    anywhere else, then the thread will not be added to the sequence
    straight away and any notifications that arrive during the gap
    will be dropped. I noticed this when debugging my block backend
    implementation. I think netif has this problem:

    let listen nf fn =
      (* Listen for the activation to poll the interface *)
      let rec poll_t t =
        lwt () = refill_requests t in
        ^^^ blocks here, can miss events

        rx_poll t fn;
        tx_poll t;
        (* Evtchn.notify nf.t.evtchn; *)
        lwt new_t =
          try_lwt
            Activations.wait t.evtchn >> return t
          with
          | Generation.Invalid ->
            Console.log_s "Waiting for plug in listen" >>
            wait_for_plug nf >>
            Console.log_s "Done..." >>
            return nf.t
        in poll_t new_t
      in
      poll_t nf.t


    I think we should change the semantics of Activations.wait to be
    more level-triggered rather than edge-triggered (i.e. more like
    the underlying behaviour of xen) like this:

     type event
     (** a particular event *)

     val wait: Evtchn.t -> event option -> event Lwt.t
     (** [wait evtchn None] returns [Some e] where [e] is the latest
    event.
         [wait evtchn (Some e)] returns [Some e'] where [e'] is a
    later event than [e] *)

    In the implementation we could have "type event = int" and
    maintain a counter of "number of times this event has been
    signalled". When you call Activations.wait, you would pass in the
    number of the last event you saw, and the thread would block
    until a new event is available. This way you wouldn't have to be
    registered in the table when the event arrives.

    2. SCHEDOP_poll has a low (arbitrary) nr_ports limit

    http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/common/schedule.c;h=a8398bd9ed4827564bed4346e1fdfbb98ec5907e;hb=c5e9596cd095e3b96a090002d9e6629a980904eb#l712

     704 static long do_poll(struct sched_poll *sched_poll)
     705 {
     706     struct vcpu   *v = current;
     707     struct domain *d = v->domain;
     708     evtchn_port_t  port;
     709     long           rc;
     710     unsigned int   i;
     711
     712     /* Fairly arbitrary limit. */
     713     if ( sched_poll->nr_ports > 128 )
     714         return -EINVAL;

    The total number of available event channels for a 64-bit guest
    is 4096 using the current ABI (a new interface is under
    development which allows even more). The limit of 128 is probably
    imposed to limit the amount of time the hypercall takes, to avoid
    hitting scalability limits like you do in userspace with select().

    One of the use-cases I'd like to use Mirage for is to run backend
    services (like xenstore or blkback) for all the domains on a
    host. This requires at least one event channel per client domain.
    We routinely run ~300 VMs/host, so the 128 limit is too small.
    Plus a quick grep around Linux shows that it doesn't use
    SCHEDOP_poll very much-- I think we should focus on using the
    hypercalls that other OSes are using, for maximum chance of success.

    So I think we should switch from select()-like behaviour using
    SCHEDOP_poll to interrupt-based delivery using SCHEDOP_block. I
    note that upstream mini-os does this by default too. I'll take a
    look at this.

    Cheers,
    Dave



    On Fri, Sep 13, 2013 at 11:50 PM, Dimosthenis Pediaditakis
    <dimosthenis.pediaditakis@cl.cam.ac.uk
    <mailto:dimosthenis.pediaditakis@cl.cam.ac.uk>> wrote:

        Hi all,
        The last few days I've been trying to pin-down the
        performance issues of the Mirage network stack, when running
        over Xen.
        When trying to push net-direct to its limits, random
        transmissions stall for anywhere between 0.1sec-4sec
        (especially at the sender).

        After some experimentation, I believe that those time-outs
        occur because netif is not (always) notified (via
        Activations) about freed TX-ring slots.
        It seems that these events (intermittently) don't reach the
        guest domain's front-end driver.

        AFAIK Activations.wait() currently blocks waiting for an
        event on the port belonging to the event channel for the netif.
        This event is delivered to Activations.run via Main.run.aux
        which is invoked via the callback in app_main() of
        runtime/kernel/main.c
        The problem I observed was that using "SCHEDOP_poll" without
        masking the intended events, the hypervisor didn't "wake-up"
        the blocked domain upon new event availability.
        The requirement for event-masking when using "SCHEDOP_poll"
        is also mentioned in the Xen documentation.

        I've produced a patch that seems to fix the above erratic
        behavior.
        Now I am able to consistently achieve higher speeds (up to
        2.75Gbps DomU2Domu). Please, have a look at my repo:
        https://github.com/dimosped/mirage-platform
        It will be helpful to use big-enough txqueuelen values for
        your VIFs, as the current TCP implementation doesn't like
        much losses at high datarates. The default size in my system
        was only 32.

        I have also modified the mirage-net-direct by adding per-flow
        TCP debug logging. This has helped me to better understand
        and pin-down the problem.
        You can grab the modified sources here:
        https://github.com/dimosped/mirage-net
        Be aware that logging big volumes of data for a TCP flow will
        require big enough memory. Nevertheless, it only barely
        affects performance.

        The iperf benchmark sources can be found here:
        https://github.com/dimosped/iperf-mirage
        I've included as much info as possible in the README file.
        This should be sufficient to get you started and replicate my
        experiments.

        In the iperf-mirage repo there is also a Python tool, which
        you can use to automatically generate plots based on the
        collected TCP debug info (I include also a sample dataset in
        data/ ):
        https://github.com/dimosped/iperf-mirage/tree/master/tools/MirageTcpVis
        For really large datasets, the script might be slow. I need
        to switch into using NumPy arrays at some point...

        Please keep in mind that I am a newbie in Xen/Mirage so your
        comments/input are more than welcome.

        Regards,
        Dimos




        ------------------------------------------------
           MORE TECHNICAL DETAILS
        ------------------------------------------------


        -----------------------------------------------------------------

        === How (I think) Mirage and XEN scheduling works ===
        -----------------------------------------------------------------

         - When Netif receives a writev request, it checks if the TX
        ring has enough empty space (for the producer) for the data
            - If there is not enough space, it block-waits (via
        Activations.wait) for an event on the port mapped to the
        netif (and bound to the backend driver)
            - Otherwise it pushes the request.
        -  Activations are notified (via run) from "aux ()" in
        Main.run. Once notified, it means that the waiting netif can
        proceed, check again the ring for free space, write a new
        request, and send an event to the backend.
        - Main.run.aux is registered as a callback (under name
        "OS.Main.run") and is invoked in xen/runtime/kernel/main.c
        (in app_main() loop). As long as the Mirage guest domain is
        scheduled, this loop keeps running.
        - However, in Main.run.aux, the Mirage guest domain is
        blocked via "block_domain timeout" if the main thread has no
        task to perform.
        - In turn, "block_domain" invokes caml_block_domain()  found
        in xen/runtime/kernel/main.c, which issues a
        "HYPERVISOR_sched_op(SCHEDOP_poll, &sched_poll);" hypercall

        -------------------------------------
        === Polling mode issue ===
        -------------------------------------
        In my opinion, and based on debug information, it seems that
        the problem is that Mirage uses "SCHEDOP_poll" without
        masking the event channels.
        The XEN documentation clearly states that with "SCHEDOP_poll"
        the domain would yield until either
          a) an event is pending on the polled channels and
          b) the timeout time (given in nanoseconds, is not duration
        but absolute system time) is reached
        It also states that this SCHEDOP_poll can only be be executed
        when the guest has delivery of events disabled.

        In Mirage, netif events are not masked and therefore they
        never "wakeup" the guest domain.
        The guest only wakes-up whenever a thread is scheduled
to         wakeup in Time.SleepQueue (e.g. a TCP timer).
        Once the guest is scheduled again, it completes any
        outstanding tasks, sends any packets pending, and whenever a)
        the TX ring gets full, or  b)the hypervisor  it, c)  it will
        sleep again.
        To further support the above, whenever I press buttons via
        XEN-console while the mirage-sender is running, the execution
        completes faster.

        ----------------
        === Fix ===
        ----------------
        There are multiple ways to mask events (e.g. at VCPU level,
        event level etc).
        As a quick hack I replaced "Eventchn.unmask h evtchn;" in
        Netif.plug_inner with Eventchn.mask h evtchn (which I had to
        create, both in Eventchn and  as a stub in
        xen/runtime/kernel/eventchn_stubs.c).
        See:
        https://github.com/dimosped/mirage-platform/commit/6d4d3f0403497f07fde4db6f4cb63665a8bf8e26








    --     Dave Scott




--
Dave Scott




--
Dave Scott

--Apple-Mail=_4D5C056B-3D64-446C-B843-943115AB1290-- From anil@recoil.org Tue Oct 08 10:04:19 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VTTDH-0006pq-E8 (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 08 Oct 2013 10:04:19 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1529793 X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:15071 helo=dark.recoil.org) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp id 1VTTDG-0007ra-iO (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 08 Oct 2013 10:04:19 +0100 Received: (qmail 8721 invoked by uid 634); 8 Oct 2013 09:04:18 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from host81-149-102-120.in-addr.btopenworld.com (HELO flick.home) (81.149.102.120) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Tue, 08 Oct 2013 10:04:18 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) Subject: Re: Using Merlin from Vim From: Anil Madhavapeddy In-Reply-To: <20131007212256.GC28899@haris-mac.cl.cam.ac.uk> Date: Tue, 8 Oct 2013 10:04:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2FEA3FD9-CB1E-4699-807A-133C12418442@recoil.org> References: <20131007212256.GC28899@haris-mac.cl.cam.ac.uk> To: Charalampos Rotsos X-Mailer: Apple Mail (2.1811) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 09:04:19 -0000 Content-Length: 1165 Lines: 38 On 7 Oct 2013, at 22:22, Charalampos Rotsos wrote: > On 10/04/13 at 11:08P, Anil Madhavapeddy wrote: >> I finally got around to installing the Merlin OCaml editor add-on, = and it gives amazing features such as type display, module completion = and support for hopping around projects. See my little Vim-Merlin from = scratch here: >>=20 >> http://anil.recoil.org/2013/10/03/merlin-and-vim.html >>=20 >> I suspect we'll need some more .merlin files in the various repos, so = I'll add those as I go along. Has anyone else been using Merlin (e.g. = on Emacs?) >>=20 >> -a >>=20 >>=20 >=20 > I have been giving it a try for the last month and it works great. My = only > problem, which I haven't searched in depth to see how I can fix, is = that it > doesn't seem to work when you rename modules.=20 >=20 > e.g. If do=20 > module OP =3D Openflow.Ofpacket >=20 > I will never get autocomplete when I type OP. I've noticed this too... I suspect this will be fixed when we build cmt = files (-bin-annot) unconditionally, since that's where the compiler = stashes all the module path information. Without it, the editor is = guessing. -anil From thomas.gazagnaire@gmail.com Tue Oct 08 10:07:39 2013 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VTTGV-00073X-9F (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 08 Oct 2013 10:07:39 +0100 X-Cam-SpamDetails: score -0.6 from SpamAssassin-3.3.2-1529793 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.212.176 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (thomas.gazagnaire[at]gmail.com) * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-wi0-f176.google.com ([209.85.212.176]:42682) by ppsw-32.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp id 1VTTGU-0005PC-2Z (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 08 Oct 2013 10:07:39 +0100 Received: by mail-wi0-f176.google.com with SMTP id hi5so369605wib.15 for ; Tue, 08 Oct 2013 02:07:38 -0700 (PDT) X-Received: by 10.180.94.233 with SMTP id df9mr457519wib.63.1381223258578; Tue, 08 Oct 2013 02:07:38 -0700 (PDT) Received: from [192.168.0.12] (gou06-3-88-170-165-56.fbx.proxad.net. [88.170.165.56]) by mx.google.com with ESMTPSA id ma3sm3118404wic.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Oct 2013 02:07:36 -0700 (PDT) Sender: Thomas Gazagnaire Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Using Merlin from Vim From: Thomas Gazagnaire In-Reply-To: <2FEA3FD9-CB1E-4699-807A-133C12418442@recoil.org> Date: Tue, 8 Oct 2013 11:07:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131007212256.GC28899@haris-mac.cl.cam.ac.uk> <2FEA3FD9-CB1E-4699-807A-133C12418442@recoil.org> To: Anil Madhavapeddy X-Mailer: Apple Mail (2.1510) Cc: Louis Gesbert , Charalampos Rotsos , Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 09:07:39 -0000 Content-Length: 701 Lines: 24 >> I have been giving it a try for the last month and it works great. My = only >> problem, which I haven't searched in depth to see how I can fix, is = that it >> doesn't seem to work when you rename modules.=20 >>=20 >> e.g. If do=20 >> module OP =3D Openflow.Ofpacket >>=20 >> I will never get autocomplete when I type OP. >=20 > I've noticed this too... I suspect this will be fixed when we build = cmt files (-bin-annot) unconditionally, since that's where the compiler = stashes all the module path information. Without it, the editor is = guessing. FWI module aliases works fine with the Git version of 'ocp-index' (but = Merlin is usually much better at semantics completion). -- Thomas From anil@recoil.org Tue Oct 08 10:08:41 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VTTHV-000767-ET (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 08 Oct 2013 10:08:41 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1529793 X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:26394 helo=dark.recoil.org) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp id 1VTTHV-00026S-gB (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 08 Oct 2013 10:08:41 +0100 Received: (qmail 3044 invoked by uid 634); 8 Oct 2013 09:08:40 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from host81-149-102-120.in-addr.btopenworld.com (HELO flick.home) (81.149.102.120) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Tue, 08 Oct 2013 10:08:40 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) Subject: Re: Using Merlin from Vim From: Anil Madhavapeddy In-Reply-To: Date: Tue, 8 Oct 2013 10:08:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131007212256.GC28899@haris-mac.cl.cam.ac.uk> <2FEA3FD9-CB1E-4699-807A-133C12418442@recoil.org> To: Thomas Gazagnaire X-Mailer: Apple Mail (2.1811) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: Louis Gesbert , Charalampos Rotsos , Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 09:08:41 -0000 Content-Length: 852 Lines: 26 On 8 Oct 2013, at 10:07, Thomas Gazagnaire = wrote: >>> I have been giving it a try for the last month and it works great. = My only >>> problem, which I haven't searched in depth to see how I can fix, is = that it >>> doesn't seem to work when you rename modules.=20 >>>=20 >>> e.g. If do=20 >>> module OP =3D Openflow.Ofpacket >>>=20 >>> I will never get autocomplete when I type OP. >>=20 >> I've noticed this too... I suspect this will be fixed when we build = cmt files (-bin-annot) unconditionally, since that's where the compiler = stashes all the module path information. Without it, the editor is = guessing. >=20 > FWI module aliases works fine with the Git version of 'ocp-index' (but = Merlin is usually much better at semantics completion). Got it -- is there anyone working on Merlin+ocp-index at all? -anil= From louis.gesbert@ocamlpro.com Tue Oct 08 11:17:27 2013 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VTUM3-00076o-30 (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 08 Oct 2013 11:17:27 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1529793 * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [212.227.126.186 listed in list.dnswl.dnsbl.ja.net] * 0.0 HTML_MESSAGE BODY: HTML included in message X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from moutng.kundenserver.de ([212.227.126.186]:53071) by ppsw-32.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp id 1VTUM2-0006HU-17 (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 08 Oct 2013 11:17:27 +0100 Received: from agaric.localnet (jua06-3-88-189-115-104.fbx.proxad.net [88.189.115.104]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LkkrY-1W3eW62764-00aj9s; Tue, 08 Oct 2013 12:17:15 +0200 From: Louis Gesbert To: Anil Madhavapeddy Subject: Re: Using Merlin from Vim Date: Tue, 08 Oct 2013 12:17:10 +0200 Message-ID: <39470815.dukatY4dsf@agaric> Organization: OCamlPro User-Agent: KMail/4.10.5 (Linux/3.10-2-amd64; KDE/4.10.5; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart2290195.8qaTIZaBq5" Content-Transfer-Encoding: 7Bit X-Provags-ID: V02:K0:0ZFPmVvOs2r42KJtUOTCkPaHVW7A4217rvLlLGwvxMa /QXt6NflQPGofrFVDeGe9XOAMveDm0HU9B8Ii5HWC44wGoMy1U uhKu2Y9A5JJZt4jSe0w+4RWxw1D0Jzl2YSezanGYcRIg5aoM3q j6yWFEDgSps31StJg7O409DzJKhMQRz4eJ8DiCk3Ca9tU7wKHj L/cjGJiV/JAj+oKLKG76BYM8KDeCGzJt38FnG+MrS5+nETwmQU E4sgQcy2ES4TNNpsJ020gcHdRFVKpLxd/cqXeNnQDr4mqMnc4Z glGmAEwPScOT3mpbQIJ+aA7EkR5xp3D/XBeU8BD/Mrpv5Fdl6+ ukWBx1xLOXSRTec2sMzk= Cc: Charalampos Rotsos , Thomas Gazagnaire , Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 10:17:27 -0000 Content-Length: 7758 Lines: 155 This is a multi-part message in MIME format. --nextPart2290195.8qaTIZaBq5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Le mardi 8 octobre 2013 10:08:39 Anil Madhavapeddy a =E9crit : > On 8 Oct 2013, at 10:07, Thomas Gazagnaire wr= ote: >=20 > >>> I have been giving it a try for the last month and it works great= . My only > >>> problem, which I haven't searched in depth to see how I can fix, = is that it > >>> doesn't seem to work when you rename modules.=20 > >>>=20 > >>> e.g. If do=20 > >>> module OP =3D Openflow.Ofpacket > >>>=20 > >>> I will never get autocomplete when I type OP. > >>=20 > >> I've noticed this too... I suspect this will be fixed when we buil= d cmt files (-bin-annot) unconditionally, since that's where the compil= er stashes all the module path information. Without it, the editor is = guessing. > >=20 > > FWI module aliases works fine with the Git version of 'ocp-index' (= but Merlin is usually much better at semantics completion). >=20 > Got it -- is there anyone working on Merlin+ocp-index at all? >=20 > -anil Not at the moment ; but we should definitely meet and see where we coul= d join our efforts. We already discussed some ideas on IRC a while ago ; since ocp-index is= much lighter-weight, and uses a different approach, that would probabl= y be in the direction of Merlin using some parts of it (eg. as a fallba= ck in some cases) I'm not sure about this specific problem though, since ocp-index uses a= pocket-sized hand-written parser to gather that kind of info, where Me= rlin already has the full grammar. -- Louis --nextPart2290195.8qaTIZaBq5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"

Le = mardi 8 octobre 2013 10:08:39 Anil Madhavapeddy a =E9crit=A0:

>= ; On 8 Oct 2013, at 10:07, Thomas Gazagnaire <thomas@gazagnaire.org&= gt; wrote:

>= ;

>= ; >>> I have been giving it a try for the last month and it wo= rks great. My only

>= ; >>> problem, which I haven't searched in depth to see how I = can fix, is that it

>= ; >>> doesn't seem to work when you rename modules.

>= ; >>>

>= ; >>> e.g. If do

>= ; >>> module OP =3D Openflow.Ofpacket

>= ; >>>

>= ; >>> I will never get autocomplete when I type OP.

>= ; >>

>= ; >> I've noticed this too... I suspect this will be fixed when w= e build cmt files (-bin-annot) unconditionally, since that's where the = compiler stashes all the module path information. Without it, the edit= or is guessing.

>= ; >

>= ; > FWI module aliases works fine with the Git version of 'ocp-index= ' (but Merlin is usually much better at semantics completion).

>= ;

>= ; Got it -- is there anyone working on Merlin+ocp-index at all?

>= ;

>= ; -anil

 

Not= at the moment ; but we should definitely meet and see where we could j= oin our efforts.

We = already discussed some ideas on IRC a while ago ; since ocp-index is mu= ch lighter-weight, and uses a different approach, that would probably b= e in the direction of Merlin using some parts of it (eg. as a fallback = in some cases)

 

I'm= not sure about this specific problem though, since ocp-index uses a po= cket-sized hand-written parser to gather that kind of info, where Merli= n already has the full grammar.

 

--<= /p>

Lou= is

--nextPart2290195.8qaTIZaBq5-- From scott.dj@gmail.com Tue Oct 08 15:04:46 2013 Received: from ppsw-mx-f.csi.cam.ac.uk ([131.111.8.149] helo=ppsw-42.csi.cam.ac.uk) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VTXu2-0006g5-Qe (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 08 Oct 2013 15:04:46 +0100 X-Cam-SpamDetails: score 0.6 from SpamAssassin-3.3.2-1529793 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.220.50 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (scott.dj[at]gmail.com) * 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is * CUSTOM_MED * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid * 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing * list X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-pa0-f50.google.com ([209.85.220.50]:43522) by ppsw-42.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with esmtp id 1VTXu2-0002Bf-6r (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 08 Oct 2013 15:04:46 +0100 Received: by mail-pa0-f50.google.com with SMTP id fb1so8866587pad.23 for ; Tue, 08 Oct 2013 07:04:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.113.130 with SMTP id iy2mr2338682pbb.2.1381241085095; Tue, 08 Oct 2013 07:04:45 -0700 (PDT) Received: by 10.70.56.36 with HTTP; Tue, 8 Oct 2013 07:04:45 -0700 (PDT) Date: Tue, 8 Oct 2013 15:04:45 +0100 Message-ID: Subject: Mirage weekly call From: David Scott To: Mirage List Content-Type: multipart/alternative; boundary=047d7b6d7a6639f4e604e83b408e X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 14:04:46 -0000 Content-Length: 1733 Lines: 48 --047d7b6d7a6639f4e604e83b408e Content-Type: text/plain; charset=ISO-8859-1 Fellow Mirage hackers, as we have only a few days to go before our 1.0 deadline, please join me on the Mirage weekly call today (tuesday) at 4pm BST! 1. Please join my meeting. https://www1.gotomeeting.com/join/591890401 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. United Kingdom (toll-free): 0 808 168 0209 United Kingdom: +44 (0) 207 151 1817 United States (toll-free): 1 877 309 2070 United States: +1 (626) 521-0017 Access Code: 591-890-401 Audio PIN: Shown after joining the meeting Meeting ID: 591-890-401 -- Dave Scott --047d7b6d7a6639f4e604e83b408e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Fellow Mirage hackers, as we have only a few days to = go before our 1.0 deadline, please join me on the Mirage weekly call today = (tuesday) at 4pm BST!

1. =A0Please join my meeting= .

2. =A0Use your m= icrophone and speakers (VoIP) - a headset is recommended. =A0Or, call in us= ing your telephone.

United Kingdom (toll-free): 0 808 168 0209 United Kingd= om: +44 (0) 207 151 1817

United States (toll-free)= : 1 877 309 2070 United States: +1 (626) 521-0017

Access Code: 591-890-401
Audio PIN: Shown after joining the meeti= ng

Meeting ID: 591-890-401

-- =
Dave Scott
--047d7b6d7a6639f4e604e83b408e-- From anil@recoil.org Tue Oct 08 16:23:57 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VTZ8f-0003tE-35 (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 08 Oct 2013 16:23:57 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1529793 X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:37622 helo=dark.recoil.org) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp id 1VTZ8e-0006eT-hI (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 08 Oct 2013 16:23:57 +0100 Received: (qmail 8154 invoked by uid 634); 8 Oct 2013 15:23:56 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from host81-149-212-230.in-addr.btopenworld.com (HELO [10.0.1.72]) (81.149.212.230) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Tue, 08 Oct 2013 16:23:53 +0100 From: Anil Madhavapeddy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: [Caml-list] [ANN] QCheck 0.1 Date: Tue, 8 Oct 2013 16:23:49 +0100 References: <20131007083549.GA22920@emmental.inria.fr> To: Mirage List Message-Id: <93DD4DC3-A447-4ED2-9CDC-3D18A6655CDC@recoil.org> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) X-Mailer: Apple Mail (2.1811) X-Virus-Checked: Checked by ClamAV on dark.recoil.org X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 15:23:57 -0000 Content-Length: 1284 Lines: 44 Jon (and others), here's the QuickCheck library I mentioned on the = Mirage call. Begin forwarded message: > From: Simon Cruanes > Subject: [Caml-list] [ANN] QCheck 0.1 > Date: 7 October 2013 09:35:49 BST > To: OCaml users > Reply-To: Simon Cruanes >=20 > Hello, >=20 > I'm happy to announce the first release of a small QuickCheck > implementation for OCaml, named `QCheck`. It consists in writing > invariants as function t -> bool for some type t, and then checking = that > the invariant holds on randomly generated instances of t. >=20 > QCheck is designed so that writing tests is as easy as possible[1], > especially for Arbitrary instances (the part where you generate random > values of a type) where it provides many combinators. >=20 > The library requires OCaml >=3D 4.00.1, and is available under the BSD > license on opam via: >=20 > $ opam install qcheck >=20 > You can find documentation at: > http://cedeela.fr/~simon/software/qcheck/QCheck.html > source code at: > https://github.com/c-cube/qcheck > and some explanations here: > http://cedeela.fr/quickcheck-for-ocaml.html >=20 > Feedback or comments welcome! > Cheers, >=20 > --=20 > Simon >=20 > [1] your mileage might vary ;) From warnegia@gmail.com Thu Oct 10 22:17:32 2013 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VUNbw-0007SE-Dz (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Thu, 10 Oct 2013 22:17:32 +0100 X-Cam-SpamDetails: score 0.6 from SpamAssassin-3.3.2-1530532 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [74.125.82.42 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (warnegia[at]gmail.com) * 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is * CUSTOM_MED * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid * 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing * list X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-wg0-f42.google.com ([74.125.82.42]:46015) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.148]:25) with esmtp id 1VUNbv-0000tN-EO (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Thu, 10 Oct 2013 22:17:32 +0100 Received: by mail-wg0-f42.google.com with SMTP id m15so204990wgh.3 for ; Thu, 10 Oct 2013 14:17:31 -0700 (PDT) X-Received: by 10.194.222.2 with SMTP id qi2mr14298190wjc.14.1381439851141; Thu, 10 Oct 2013 14:17:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.115.65 with HTTP; Thu, 10 Oct 2013 14:17:11 -0700 (PDT) In-Reply-To: References: <11A052D6-F076-4B60-9EA1-93A4E07C4732@recoil.org> From: William Le Ferrand Date: Thu, 10 Oct 2013 14:17:11 -0700 Message-ID: Subject: Re: RX error (microkernel in EC2) To: Anil Madhavapeddy Content-Type: multipart/alternative; boundary=001a11c278149b205304e869876c Cc: David Scott , cl-mirage X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 21:17:32 -0000 Content-Length: 13537 Lines: 404 --001a11c278149b205304e869876c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Anil, did you had the chance to take a look at the DHCP problem? thanks On Thu, Sep 19, 2013 at 8:28 AM, William Le Ferrand wro= te: > ok great. fyi I'm doing consulting work for someone who is storing & > indexing > 8 Tb/day in AWS and looking to scale to 250 Tb/day. It's full > scala, but I'd love to benchmark a mirage-based solution on my spare time > and to push them in this direction if the figures make sense > > > On Thu, Sep 19, 2013 at 6:59 AM, Anil Madhavapeddy wrote= : > >> DHCP should work too (and has worked in the past, so this is no doubt a >> minor issue, despite being difficult to debug). >> >> -anil >> >> On 19 Sep 2013, at 14:56, William Le Ferrand wrote: >> >> I used the ec2.sh script, but I think that I was on the wrong track >> anyway as local IP should be retrieved from the instance using "*GET >> http://169.254.169.254/latest/meta-data/local-ipv4" *rather than DHCP, >> shouldn't it? That's why I inquired about the status of client functions= in >> cohttp >> >> >> On Thu, Sep 19, 2013 at 3:57 AM, Anil Madhavapeddy wrot= e: >> >>> I'll take a look at this -- which script did you use to wrap up the EC2 >>> kernel for upload William? (just curious if you've been using the AWS O= Caml >>> bindings for this, or doing it manually) >>> >>> -anil >>> >>> On 18 Sep 2013, at 23:57, William Le Ferrand wrote= : >>> >>> Yes, I tried that but the error only occurs in EC2; it's raised >>> somewhere in the DHCP module it seems .. >>> >>> >>> On Wed, Sep 18, 2013 at 2:12 PM, David Scott wrote= : >>> >>>> Hi, >>>> >>>> I usually start by recompiling the app as a Unix process (using >>>> "mirage-unix" rather than "mirage-xen"). Assuming the bug manifests th= ere >>>> (probably: I suspect the String.sub problem is coming from the http-le= vel >>>> rather than the xen driver-level) then you can use regular debugging t= ools, >>>> set OCAMLRUNPARAM=3Db etc. >>>> >>>> Debugging in-situ on EC2 is currently a matter of inserting printf's >>>> and reading the code-- not ideal. >>>> >>>> HTH >>>> Dave >>>> >>>> >>>> On Wed, Sep 18, 2013 at 9:45 PM, William Le Ferrand >>> > wrote: >>>> >>>>> hello everyone >>>>> >>>>> I'm running the simplest cohttp application possible in EC2, the >>>>> instance boots but quickly complains : >>>>> >>>>> >>>>> >>>>> MAC: 0e:32:89:f8:03:7b >>>>> sg:true gso_tcpv4:true rx_copy:true rx_flip:false smart_poll:false >>>>> Manager: plug 0 >>>>> Manager: plug done, to listener >>>>> Manager: Interface 0 to DHCP >>>>> DHCP: waiting for first offer >>>>> Manager: init done >>>>> DHCP: start discovery >>>>> Sending DHCP broadcast len 552 >>>>> DHCP: start discovery >>>>> Sending DHCP broadcast len 552 >>>>> DHCP: input ciaddr 0.0.0.0 yiaddr 172.31.23.46 siaddr 0.0.0.0 giaddr = 0.0.0.0 chaddr 2=EF=BF=BD=EF=BF=BD { sname file >>>>> DHCP: offer received: 172.31.23.46 >>>>> Sending DHCP broadcast len 552 >>>>> RX exn Invalid_argument("String.sub") >>>>> >>>>> >>>>> Am I doing something wrong somewhere and what would be a good strateg= y >>>>> to debug this? >>>>> >>>>> Thanks >>>>> >>>>> william >>>>> >>>>> -- >>>>> William Le Ferrand >>>>> >>>>> Mobile : (+1) (415) 683-1484 >>>>> Web : http://williamleferrand.github.com/ >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Dave Scott >>>> >>> >>> >>> >>> -- >>> William Le Ferrand >>> >>> Mobile : (+1) (415) 683-1484 >>> Web : http://williamleferrand.github.com/ >>> >>> >>> >>> >> >> >> -- >> William Le Ferrand >> >> Mobile : (+1) (415) 683-1484 >> Web : http://williamleferrand.github.com/ >> >> >> >> > > > -- > William Le Ferrand > > Mobile : (+1) (415) 683-1484 > Web : http://williamleferrand.github.com/ > > --=20 William Le Ferrand Mobile : (+1) (415) 683-1484 Web : http://williamleferrand.github.com/ --001a11c278149b205304e869876c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Anil, did you had the chance to take a look at the DHCP= problem? thanks


On Thu, Sep 19, 2013 at 8:28 AM, William Le Ferrand <warnegia@gm= ail.com> wrote:
ok great. fyi I'm doing= consulting work for someone who is storing & indexing > 8 Tb/day in= AWS and looking to scale to 250 Tb/day. It's full scala, but I'd l= ove to benchmark a mirage-based solution on my spare time and to push them = in this direction if the figures make sense


On Thu, Sep 1= 9, 2013 at 6:59 AM, Anil Madhavapeddy <anil@recoil.org> wrote:=
DHCP should work too (and has worked in= the past, so this is no doubt a minor issue, despite being difficult to de= bug).

-anil

On 19 Sep 2013, at 14:56, Willia= m Le Ferrand <wa= rnegia@gmail.com> wrote:

I used the ec2.sh script, but I think that I was on the wr= ong track anyway as local IP should be retrieved from the instance using &q= uot;GET http://169.254.169.254/latest/meta-da= ta/local-ipv4"=C2=A0rather than DHCP, shouldn't it? T= hat's why I inquired about the status of client functions in cohttp


On Thu, Sep 1= 9, 2013 at 3:57 AM, Anil Madhavapeddy <anil@recoil.org> wrote:=
I'll take a look at this -- which s= cript did you use to wrap up the EC2 kernel for upload William? (just curio= us if you've been using the AWS OCaml bindings for this, or doing it ma= nually)

-anil

On 18 Sep 2= 013, at 23:57, William Le Ferrand <warnegia@gmail.com> wrote:

Yes, I tried that but the error = only occurs in EC2; it's raised somewhere in the DHCP module it seems .= .


On Wed= , Sep 18, 2013 at 2:12 PM, David Scott <scott.dj@gmail.com>= wrote:
Hi,

I us= ually start by recompiling the app as a Unix process (using "mirage-un= ix" rather than "mirage-xen"). Assuming the bug manifests th= ere (probably: I suspect the String.sub problem is coming from the http-lev= el rather than the xen driver-level) then you can use regular debugging too= ls, set OCAMLRUNPARAM=3Db etc.

Debugging in-situ on EC2 is currently a matter of inser= ting printf's and reading the code-- not ideal.

HTH
Dave


On Wed, Sep 18, 2013 at 9:45 PM, William Le Ferrand <<= a href=3D"mailto:warnegia@gmail.com" target=3D"_blank">warnegia@gmail.com> wrote:
hello everyone

I'm running the simp= lest cohttp application possible in EC2, the instance boots but quickly com= plains :=C2=A0



MAC: 0e:32:89:f8:03:7b
 sg:true gso_tcpv4:true rx_copy:true rx_flip:false smart_poll:false
Manager: plug 0
Manager: plug done, to listener
Manager: Interface 0 to DHCP
DHCP: waiting for first offer
Manager: init done
DHCP: start discovery
Sending DHCP broadcast len 552
DHCP: start discovery
Sending DHCP broadcast len 552
DHCP: input ciaddr 0.0.0.0 yiaddr 172.31.23.46 siaddr 0.0.0.0 giaddr 0.0.0.=
0 chaddr  2=EF=BF=BD=EF=BF=BD { sname  file=20
DHCP: offer received: 172.31.23.46
Sending DHCP broadcast len 552
RX exn Invalid_argument("String.sub")

Am= I doing something wrong somewhere and what would be a good strategy to deb= ug this?=C2=A0

Thanks

william=C2=A0

--
William Le Ferrand

Mobile :=C2=A0(+1= )=C2=A0(415) 683-1484
<= /a>



--
Dave Scott



--
William Le F= errand




--
William Le Ferrand

Mobile := =C2=A0(+1)=C2=A0(415) 683-1484




--
William Le Ferrand

Mobi= le :=C2=A0(+1)=C2=A0(415) 683-1484



--
= William Le Ferrand

Mobile :=C2=A0(+1)=C2=A0= (415) 683-1484
--001a11c278149b205304e869876c-- From warnegia@gmail.com Fri Oct 11 01:34:55 2013 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VUQgx-0006LW-7y (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 11 Oct 2013 01:34:55 +0100 X-Cam-SpamDetails: score 0.6 from SpamAssassin-3.3.2-1530532 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [74.125.82.179 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (warnegia[at]gmail.com) * 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is * CUSTOM_MED * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid * 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing * list X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-we0-f179.google.com ([74.125.82.179]:43179) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.148]:25) with esmtp id 1VUQgw-0007Gf-EV (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 11 Oct 2013 01:34:55 +0100 Received: by mail-we0-f179.google.com with SMTP id w61so3492200wes.10 for ; Thu, 10 Oct 2013 17:34:54 -0700 (PDT) X-Received: by 10.180.160.203 with SMTP id xm11mr753718wib.17.1381451694108; Thu, 10 Oct 2013 17:34:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.115.65 with HTTP; Thu, 10 Oct 2013 17:34:34 -0700 (PDT) In-Reply-To: References: From: William Le Ferrand Date: Thu, 10 Oct 2013 17:34:34 -0700 Message-ID: Subject: Re: cohttp_lwt_mirage.ml / client To: Anil Madhavapeddy Content-Type: multipart/alternative; boundary=047d7b66f9078078fb04e86c494a Cc: Balraj Singh , cl-mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 00:34:55 -0000 Content-Length: 3550 Lines: 109 --047d7b66f9078078fb04e86c494a Content-Type: text/plain; charset=ISO-8859-1 Hi Balraj, hi Anil, what is the status of cohttp/client on mirage? (I'll be happy to write it if mirage has the required primitives) thanks william On Wed, Sep 18, 2013 at 4:56 PM, Anil Madhavapeddy wrote: > I didn't fill it out as I was waiting for Balraj's TCP connect state > machine to be tested (we were mainly just testing servers before). Balraj: > is that in trunk in mirage-net now? > > -anil > > On 19 Sep 2013, at 00:54, William Le Ferrand wrote: > > > Hello everyone > > > > Is there a version of Cohttp_lwt_mirage.Client that works somewhere? Is > there any special difficulties with it? The one on github has fail "no > implemented" here and there. > > > > Thanks! > > > > William > > > > -- > > William Le Ferrand > > > > Mobile : (+1) (415) 683-1484 > > Web : http://williamleferrand.github.com/ > > > > -- William Le Ferrand Mobile : (+1) (415) 683-1484 Web : http://williamleferrand.github.com/ --047d7b66f9078078fb04e86c494a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Balraj, hi Anil, what is the status of cohttp/clie= nt on mirage? (I'll be happy to write it if mirage has the required pri= mitives)

thanks

william

On = Wed, Sep 18, 2013 at 4:56 PM, Anil Madhavapeddy <anil@recoil.org> wrote:
I didn't fill it out as I was waiting fo= r Balraj's TCP connect state machine to be tested (we were mainly just = testing servers before). =A0Balraj: is that in trunk in mirage-net now?

-anil

On 19 Sep 2013, at 00:54, William Le Ferrand <warnegia@gmail.com> wrote:

> Hello everyone
>
> Is there a version of Cohttp_lwt_mirage.Client that works somewhere? I= s there any special difficulties with it? The one on github has fail "= no implemented" here and there.
>
> Thanks!
>
> William
>
> --
> William Le Ferrand
>
> Mobile : (+1) (415) 683-1484
> Web : http://williamleferrand.github.com/
>




--
= William Le Ferrand

Mobile :=A0(+1)=A0(415) = 683-1484
--047d7b66f9078078fb04e86c494a-- From anil@recoil.org Sun Oct 13 11:10:23 2013 Received: from ppsw-mx-f.csi.cam.ac.uk ([131.111.8.149] helo=ppsw-42.csi.cam.ac.uk) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VVIcx-0003jE-P4 (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Sun, 13 Oct 2013 11:10:23 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1531518 X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:39467 helo=dark.recoil.org) by ppsw-42.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with smtp id 1VVIcw-00011V-9H (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Sun, 13 Oct 2013 11:10:23 +0100 Received: (qmail 26434 invoked by uid 634); 13 Oct 2013 10:10:22 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from host81-149-102-120.in-addr.btopenworld.com (HELO flick.home) (81.149.102.120) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Sun, 13 Oct 2013 11:10:21 +0100 From: Anil Madhavapeddy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: cstruct 0.8.0; anything else before 1.0? Message-Id: Date: Sun, 13 Oct 2013 11:10:19 +0100 To: Mirage List , Arjun Guha Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) X-Mailer: Apple Mail (2.1812) X-Virus-Checked: Checked by ClamAV on dark.recoil.org X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 10:10:23 -0000 Content-Length: 1657 Lines: 36 I've gone through the outstanding cstruct issues and fixed most of them: 0.8.0rc1 (13-Oct-2013): * Improved ocamldoc for BE/LE modules. * Add Travis-CI test scripts and fix `test.sh` script compilation. * Support int32/int64 constant values in cenum like `VAL =3D = 0xffffffffl`, useful for 32-bit hosts. * Check and raise error in case of negative offsets for blits (#4). * Correctly preserve the sequence after a constant constructor is set = during a `cenum` definition. * Do not repeat the `sizeof_` binding for every get/set field = (should be no externally observable change). * Add `Cstruct.hexdump_to_buffer` to make spooling hexdump output = easier. * Generate `hexdump_foo` and `hexdump_foo_to_buffer` prettyprinting = functions for a `cstruct foo`. Arjun, this should fix your 32-bit host problem, but you need to ensure = that you use the correct literals so that the OCaml lexer doesn't = complain (i.e. 0xffffffffl instead of 0xffffffff). I've also added a handy set of hexdump functions to prettyprint = cstructs, and improved the README to describe the functions involved. Mort, I've been through your issues about the iter/fold, but the only = real use-case right now is the pcap parser. Most of the other call = sites just handle individual packets, so I've got no strong opinion on = this. I'll leave those for you to drive with examples uses... Other than that, I'd like to have the extension also emit ctypes values, = so that it can be used in stub-generation and other interactions with C = libraries. That will be post 1.0 though, so I'll tag this current = featureset as 1.0 if noone's got any showstoppers. -anil= From thomas.gazagnaire@gmail.com Sun Oct 13 17:49:03 2013 Received: from ppsw-mx-f.csi.cam.ac.uk ([131.111.8.149] helo=ppsw-42.csi.cam.ac.uk) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VVOql-0000Qi-Fe (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Sun, 13 Oct 2013 17:49:03 +0100 X-Cam-SpamDetails: score -0.6 from SpamAssassin-3.3.2-1531518 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [74.125.82.48 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (thomas.gazagnaire[at]gmail.com) * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-wg0-f48.google.com ([74.125.82.48]:36143) by ppsw-42.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with esmtp id 1VVOqk-00039f-8R (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Sun, 13 Oct 2013 17:49:03 +0100 Received: by mail-wg0-f48.google.com with SMTP id b13so5089557wgh.3 for ; Sun, 13 Oct 2013 09:49:02 -0700 (PDT) X-Received: by 10.180.160.203 with SMTP id xm11mr11197033wib.17.1381682942337; Sun, 13 Oct 2013 09:49:02 -0700 (PDT) Received: from [192.168.0.12] (sud35-6-83-152-60-83.fbx.proxad.net. [83.152.60.83]) by mx.google.com with ESMTPSA id b13sm25835953wic.9.2013.10.13.09.48.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Oct 2013 09:49:00 -0700 (PDT) Sender: Thomas Gazagnaire Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: cstruct 0.8.0; anything else before 1.0? From: Thomas Gazagnaire In-Reply-To: Date: Sun, 13 Oct 2013 18:49:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Anil Madhavapeddy X-Mailer: Apple Mail (2.1510) Cc: Arjun Guha , Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 16:49:03 -0000 Content-Length: 2205 Lines: 48 Would be nice to have a mutable interface at one point (I've started = different design in Cagit[1] and Irminsule[2] already, not totally sure = yet what's the best interface). I tend to prefer [2] where the mutable = buffer type is defined as 'type t =3D { mutable buffer: Cstruct.t }' [1] https://github.com/samoht/cagit/blob/master/src/lib/IO.ml [2] https://github.com/samoht/irminsule/blob/master/src/irminIO.ml On Oct 13, 2013, at 12:10 PM, Anil Madhavapeddy wrote: > I've gone through the outstanding cstruct issues and fixed most of = them: >=20 > 0.8.0rc1 (13-Oct-2013): > * Improved ocamldoc for BE/LE modules. > * Add Travis-CI test scripts and fix `test.sh` script compilation. > * Support int32/int64 constant values in cenum like `VAL =3D = 0xffffffffl`, useful for 32-bit hosts. > * Check and raise error in case of negative offsets for blits (#4). > * Correctly preserve the sequence after a constant constructor is set = during a `cenum` definition. > * Do not repeat the `sizeof_` binding for every get/set field = (should be no externally observable change). > * Add `Cstruct.hexdump_to_buffer` to make spooling hexdump output = easier. > * Generate `hexdump_foo` and `hexdump_foo_to_buffer` prettyprinting = functions for a `cstruct foo`. >=20 > Arjun, this should fix your 32-bit host problem, but you need to = ensure that you use the correct literals so that the OCaml lexer doesn't = complain (i.e. 0xffffffffl instead of 0xffffffff). >=20 > I've also added a handy set of hexdump functions to prettyprint = cstructs, and improved the README to describe the functions involved. >=20 > Mort, I've been through your issues about the iter/fold, but the only = real use-case right now is the pcap parser. Most of the other call = sites just handle individual packets, so I've got no strong opinion on = this. I'll leave those for you to drive with examples uses... >=20 > Other than that, I'd like to have the extension also emit ctypes = values, so that it can be used in stub-generation and other interactions = with C libraries. That will be post 1.0 though, so I'll tag this = current featureset as 1.0 if noone's got any showstoppers. >=20 > -anil From arjun.guha@gmail.com Sun Oct 13 21:40:11 2013 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VVSSR-0005ug-CT (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Sun, 13 Oct 2013 21:40:11 +0100 X-Cam-SpamDetails: score -0.6 from SpamAssassin-3.3.2-1531518 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.223.171 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (arjun.guha[at]gmail.com) * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-ie0-f171.google.com ([209.85.223.171]:56119) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.148]:25) with esmtp id 1VVSSP-000448-F0 (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Sun, 13 Oct 2013 21:40:11 +0100 Received: by mail-ie0-f171.google.com with SMTP id at1so13390527iec.30 for ; Sun, 13 Oct 2013 13:40:08 -0700 (PDT) X-Received: by 10.50.136.137 with SMTP id qa9mr10811350igb.42.1381696808768; Sun, 13 Oct 2013 13:40:08 -0700 (PDT) MIME-Version: 1.0 Sender: arjun.guha@gmail.com Received: by 10.43.2.195 with HTTP; Sun, 13 Oct 2013 13:39:48 -0700 (PDT) In-Reply-To: References: From: Arjun Guha Date: Sun, 13 Oct 2013 16:39:48 -0400 X-Google-Sender-Auth: UoTeG-d9co-NYXbdkDADvlecQGo Message-ID: Subject: Re: cstruct 0.8.0; anything else before 1.0? To: Thomas Gazagnaire Content-Type: multipart/alternative; boundary=089e0141aa04795f2a04e8a55b12 Cc: Nate Foster , Mirage List , Anil Madhavapeddy X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 20:40:11 -0000 Content-Length: 5860 Lines: 134 --089e0141aa04795f2a04e8a55b12 Content-Type: text/plain; charset=UTF-8 This is certainly ready to be a 1.0 release. Thanks so much! Arjun On Sun, Oct 13, 2013 at 12:49 PM, Thomas Gazagnaire wrote: > Would be nice to have a mutable interface at one point (I've started > different design in Cagit[1] and Irminsule[2] already, not totally sure yet > what's the best interface). I tend to prefer [2] where the mutable buffer > type is defined as 'type t = { mutable buffer: Cstruct.t }' > > [1] https://github.com/samoht/cagit/blob/master/src/lib/IO.ml > [2] https://github.com/samoht/irminsule/blob/master/src/irminIO.ml > > On Oct 13, 2013, at 12:10 PM, Anil Madhavapeddy wrote: > > > I've gone through the outstanding cstruct issues and fixed most of them: > > > > 0.8.0rc1 (13-Oct-2013): > > * Improved ocamldoc for BE/LE modules. > > * Add Travis-CI test scripts and fix `test.sh` script compilation. > > * Support int32/int64 constant values in cenum like `VAL = 0xffffffffl`, > useful for 32-bit hosts. > > * Check and raise error in case of negative offsets for blits (#4). > > * Correctly preserve the sequence after a constant constructor is set > during a `cenum` definition. > > * Do not repeat the `sizeof_` binding for every get/set field > (should be no externally observable change). > > * Add `Cstruct.hexdump_to_buffer` to make spooling hexdump output easier. > > * Generate `hexdump_foo` and `hexdump_foo_to_buffer` prettyprinting > functions for a `cstruct foo`. > > > > Arjun, this should fix your 32-bit host problem, but you need to ensure > that you use the correct literals so that the OCaml lexer doesn't complain > (i.e. 0xffffffffl instead of 0xffffffff). > > > > I've also added a handy set of hexdump functions to prettyprint > cstructs, and improved the README to describe the functions involved. > > > > Mort, I've been through your issues about the iter/fold, but the only > real use-case right now is the pcap parser. Most of the other call sites > just handle individual packets, so I've got no strong opinion on this. > I'll leave those for you to drive with examples uses... > > > > Other than that, I'd like to have the extension also emit ctypes values, > so that it can be used in stub-generation and other interactions with C > libraries. That will be post 1.0 though, so I'll tag this current > featureset as 1.0 if noone's got any showstoppers. > > > > -anil > > --089e0141aa04795f2a04e8a55b12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is certainly ready to be a 1.0 release. Thanks so muc= h!

Arjun


<= div class=3D"gmail_quote">On Sun, Oct 13, 2013 at 12:49 PM, Thomas Gazagnai= re <thomas@gazagnaire.org> wrote:
Would be nice to have a mutable interface at= one point (I've started different design in Cagit[1] and Irminsule[2] = already, not totally sure yet what's the best interface). I tend to pre= fer [2] where the mutable buffer type is defined as 'type t =3D { mutab= le buffer: Cstruct.t }'

[1] https://github.com/samoht/cagit/blob/master/src/lib/IO.ml<= /a>
[2] https://github.com/samoht/irminsule/blob/master/src/i= rminIO.ml

On Oct 13, 2013, at 12:10 PM, Anil Madhavapeddy <anil@recoil.org> wrote:

> I've gone through the outstanding cstruct issues and fixed most of= them:
>
> 0.8.0rc1 (13-Oct-2013):
> * Improved ocamldoc for BE/LE modules.
> * Add Travis-CI test scripts and fix `test.sh` script compilation.
> * Support int32/int64 constant values in cenum like `VAL =3D 0xfffffff= fl`, useful for 32-bit hosts.
> * Check and raise error in case of negative offsets for blits (#4). > * Correctly preserve the sequence after a constant constructor is set = during a `cenum` definition.
> * Do not repeat the `sizeof_<field>` binding for every get/set f= ield (should be no externally observable change).
> * Add `Cstruct.hexdump_to_buffer` to make spooling hexdump output easi= er.
> * Generate `hexdump_foo` and `hexdump_foo_to_buffer` prettyprinting fu= nctions for a `cstruct foo`.
>
> Arjun, this should fix your 32-bit host problem, but you need to ensur= e that you use the correct literals so that the OCaml lexer doesn't com= plain (i.e. 0xffffffffl instead of 0xffffffff).
>
> I've also added a handy set of hexdump functions to prettyprint cs= tructs, and improved the README to describe the functions involved.
>
> Mort, I've been through your issues about the iter/fold, but the o= nly real use-case right now is the pcap parser. =C2=A0Most of the other cal= l sites just handle individual packets, so I've got no strong opinion o= n this. =C2=A0I'll leave those for you to drive with examples uses... >
> Other than that, I'd like to have the extension also emit ctypes v= alues, so that it can be used in stub-generation and other interactions wit= h C libraries. =C2=A0That will be post 1.0 though, so I'll tag this cur= rent featureset as 1.0 if noone's got any showstoppers.
>
> -anil


--089e0141aa04795f2a04e8a55b12-- From anil@recoil.org Mon Oct 14 09:29:17 2013 Received: from ppsw-mx-f.csi.cam.ac.uk ([131.111.8.149] helo=ppsw-42.csi.cam.ac.uk) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VVdWf-0001VO-C0 (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 14 Oct 2013 09:29:17 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1531636 X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:22277 helo=dark.recoil.org) by ppsw-42.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with smtp id 1VVdWc-0001TJ-8C (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 14 Oct 2013 09:29:15 +0100 Received: (qmail 11844 invoked by uid 634); 14 Oct 2013 08:29:14 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from volstagg-0.srg.cl.cam.ac.uk (HELO flick.office) (128.232.32.232) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Mon, 14 Oct 2013 09:29:13 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) Subject: Re: cstruct 0.8.0; anything else before 1.0? From: Anil Madhavapeddy In-Reply-To: Date: Mon, 14 Oct 2013 09:29:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3DB14562-DE13-40D7-90EE-4A8FF64CEEF8@recoil.org> References: To: Thomas Gazagnaire X-Mailer: Apple Mail (2.1812) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: Arjun Guha , Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 08:29:17 -0000 Content-Length: 2648 Lines: 61 I do like the look of this streaming API quite a bit, but I'll go ahead = and tag a 1.0.0 shortly with the existing API. We can refine and break = the interface in 2.x, as there quite a few consumers of the existing one = already (for good or for ill!). OPAM can sort out the resulting = compatibility matrix. -a On 13 Oct 2013, at 17:49, Thomas Gazagnaire = wrote: > Would be nice to have a mutable interface at one point (I've started = different design in Cagit[1] and Irminsule[2] already, not totally sure = yet what's the best interface). I tend to prefer [2] where the mutable = buffer type is defined as 'type t =3D { mutable buffer: Cstruct.t }' >=20 > [1] https://github.com/samoht/cagit/blob/master/src/lib/IO.ml > [2] https://github.com/samoht/irminsule/blob/master/src/irminIO.ml >=20 > On Oct 13, 2013, at 12:10 PM, Anil Madhavapeddy = wrote: >=20 >> I've gone through the outstanding cstruct issues and fixed most of = them: >>=20 >> 0.8.0rc1 (13-Oct-2013): >> * Improved ocamldoc for BE/LE modules. >> * Add Travis-CI test scripts and fix `test.sh` script compilation. >> * Support int32/int64 constant values in cenum like `VAL =3D = 0xffffffffl`, useful for 32-bit hosts. >> * Check and raise error in case of negative offsets for blits (#4). >> * Correctly preserve the sequence after a constant constructor is set = during a `cenum` definition. >> * Do not repeat the `sizeof_` binding for every get/set field = (should be no externally observable change). >> * Add `Cstruct.hexdump_to_buffer` to make spooling hexdump output = easier. >> * Generate `hexdump_foo` and `hexdump_foo_to_buffer` prettyprinting = functions for a `cstruct foo`. >>=20 >> Arjun, this should fix your 32-bit host problem, but you need to = ensure that you use the correct literals so that the OCaml lexer doesn't = complain (i.e. 0xffffffffl instead of 0xffffffff). >>=20 >> I've also added a handy set of hexdump functions to prettyprint = cstructs, and improved the README to describe the functions involved. >>=20 >> Mort, I've been through your issues about the iter/fold, but the only = real use-case right now is the pcap parser. Most of the other call = sites just handle individual packets, so I've got no strong opinion on = this. I'll leave those for you to drive with examples uses... >>=20 >> Other than that, I'd like to have the extension also emit ctypes = values, so that it can be used in stub-generation and other interactions = with C libraries. That will be post 1.0 though, so I'll tag this = current featureset as 1.0 if noone's got any showstoppers. >>=20 >> -anil >=20 From thomas.gazagnaire@gmail.com Mon Oct 14 09:30:24 2013 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VVdXk-0001bO-Gr (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 14 Oct 2013 09:30:24 +0100 X-Cam-SpamDetails: score -0.6 from SpamAssassin-3.3.2-1531636 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [74.125.82.47 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (thomas.gazagnaire[at]gmail.com) * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-wg0-f47.google.com ([74.125.82.47]:42325) by ppsw-32.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp id 1VVdXj-0001N7-0Y (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 14 Oct 2013 09:30:24 +0100 Received: by mail-wg0-f47.google.com with SMTP id c11so1930902wgh.26 for ; Mon, 14 Oct 2013 01:30:23 -0700 (PDT) X-Received: by 10.194.10.193 with SMTP id k1mr523270wjb.50.1381739422915; Mon, 14 Oct 2013 01:30:22 -0700 (PDT) Received: from [192.168.0.12] (sud35-6-83-152-60-83.fbx.proxad.net. [83.152.60.83]) by mx.google.com with ESMTPSA id h15sm31865544wic.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Oct 2013 01:30:21 -0700 (PDT) Sender: Thomas Gazagnaire Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: cstruct 0.8.0; anything else before 1.0? From: Thomas Gazagnaire In-Reply-To: <3DB14562-DE13-40D7-90EE-4A8FF64CEEF8@recoil.org> Date: Mon, 14 Oct 2013 10:30:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0026BF48-51E2-4D18-BC20-B0CD3E6A28E9@gazagnaire.org> References: <3DB14562-DE13-40D7-90EE-4A8FF64CEEF8@recoil.org> To: Anil Madhavapeddy X-Mailer: Apple Mail (2.1510) Cc: Arjun Guha , Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 08:30:24 -0000 Content-Length: 2710 Lines: 65 > I do like the look of this streaming API quite a bit, but I'll go = ahead and tag a 1.0.0 shortly with the existing API. We can refine and = break the interface in 2.x, as there quite a few consumers of the = existing one already (for good or for ill!). OPAM can sort out the = resulting compatibility matrix. Agreed. >=20 > -a >=20 > On 13 Oct 2013, at 17:49, Thomas Gazagnaire = wrote: >=20 >> Would be nice to have a mutable interface at one point (I've started = different design in Cagit[1] and Irminsule[2] already, not totally sure = yet what's the best interface). I tend to prefer [2] where the mutable = buffer type is defined as 'type t =3D { mutable buffer: Cstruct.t }' >>=20 >> [1] https://github.com/samoht/cagit/blob/master/src/lib/IO.ml >> [2] https://github.com/samoht/irminsule/blob/master/src/irminIO.ml >>=20 >> On Oct 13, 2013, at 12:10 PM, Anil Madhavapeddy = wrote: >>=20 >>> I've gone through the outstanding cstruct issues and fixed most of = them: >>>=20 >>> 0.8.0rc1 (13-Oct-2013): >>> * Improved ocamldoc for BE/LE modules. >>> * Add Travis-CI test scripts and fix `test.sh` script compilation. >>> * Support int32/int64 constant values in cenum like `VAL =3D = 0xffffffffl`, useful for 32-bit hosts. >>> * Check and raise error in case of negative offsets for blits (#4). >>> * Correctly preserve the sequence after a constant constructor is = set during a `cenum` definition. >>> * Do not repeat the `sizeof_` binding for every get/set field = (should be no externally observable change). >>> * Add `Cstruct.hexdump_to_buffer` to make spooling hexdump output = easier. >>> * Generate `hexdump_foo` and `hexdump_foo_to_buffer` prettyprinting = functions for a `cstruct foo`. >>>=20 >>> Arjun, this should fix your 32-bit host problem, but you need to = ensure that you use the correct literals so that the OCaml lexer doesn't = complain (i.e. 0xffffffffl instead of 0xffffffff). >>>=20 >>> I've also added a handy set of hexdump functions to prettyprint = cstructs, and improved the README to describe the functions involved. >>>=20 >>> Mort, I've been through your issues about the iter/fold, but the = only real use-case right now is the pcap parser. Most of the other call = sites just handle individual packets, so I've got no strong opinion on = this. I'll leave those for you to drive with examples uses... >>>=20 >>> Other than that, I'd like to have the extension also emit ctypes = values, so that it can be used in stub-generation and other interactions = with C libraries. That will be post 1.0 though, so I'll tag this = current featureset as 1.0 if noone's got any showstoppers. >>>=20 >>> -anil >>=20 >=20 From lars.kurth.xen@gmail.com Wed Oct 16 16:24:07 2013 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VWSxD-0002Yq-AS (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 16 Oct 2013 16:24:07 +0100 X-Cam-SpamDetails: score -0.6 from SpamAssassin-3.3.2-1532248 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [74.125.82.176 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (lars.kurth.xen[at]gmail.com) * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-we0-f176.google.com ([74.125.82.176]:59790) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.148]:25) with esmtp id 1VWSxB-00049T-F5 (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 16 Oct 2013 16:24:07 +0100 Received: by mail-we0-f176.google.com with SMTP id w62so887081wes.35 for ; Wed, 16 Oct 2013 08:24:05 -0700 (PDT) X-Received: by 10.180.208.97 with SMTP id md1mr2772138wic.41.1381937045431; Wed, 16 Oct 2013 08:24:05 -0700 (PDT) Received: from [172.16.26.11] ([185.25.64.249]) by mx.google.com with ESMTPSA id b13sm6855327wic.9.2013.10.16.08.24.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Oct 2013 08:24:04 -0700 (PDT) Sender: Lars Kurth Message-ID: <525EAF90.4080400@xen.org> Date: Wed, 16 Oct 2013 16:24:00 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" , "xen-api@lists.xen.org" , "cl-mirage@lists.cam.ac.uk List" , Anil Madhavapeddy , "konrad.wilk" , George Dunlap , Ian Campbell , Ian Jackson , Roger Pau Monne , Dario Faggioli , Anthony PERARD Subject: Re: Xen Project to Sponsor one student for Gnome Womens Outreach winter round (Urgent) References: <525D6CB7.8070301@xen.org> In-Reply-To: <525D6CB7.8070301@xen.org> Content-Type: multipart/alternative; boundary="------------050405070801000004050702" X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list Reply-To: lars.kurth@xen.org List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:24:07 -0000 Content-Length: 32756 Lines: 719 This is a multi-part message in MIME format. --------------050405070801000004050702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi all, I got confirmation that this is still OK. So we will have one student to work on a Xen project that the Advisory Boards will fund. I created http://wiki.xenproject.org/wiki/OutreachProgramForWomen/Round7 http://wiki.xenproject.org/wiki/OutreachProgramForWomen/OPWApply I copied the GSoC list and prospective mentors are: * Konrad * George * Anil * Ian Campvell * Ian Jackson * Roger * Dario * Anthony If your name is listed above: * review the projects in http://wiki.xenproject.org/wiki/OutreachProgramForWomen/Round7 and REMOVE those that are done already * REMOVE your projects fvrom the list if you are NOT willing to mentor Best Regards Lars On 15/10/2013 17:26, Lars Kurth wrote: > Hi all, > > I just got the last vote in for the Advisory Board sponsoring a > student to work on the Xen Project for this winter round. The > deadlines are tight and it is possible that we may not get the > paperwork done in time. I will hopefully know in a day or two and will > then immediately create the landing page, etc. > > Assuming all goes well, we will need a mentor and a few suitable > projects. Do we have any volunteers and suitable projects? > > Regards > Lars > > *From:*Lars Kurth > *Sent:* 15 October 2013 15:33 > *To:* Advisory-board discussions > *Cc:* Konrad Rzeszutek Wilk (konrad.wilk@oracle.com) > *Subject:* RE: [Advisory-board] Xen Project AB VOTE: Sponsoring one > intern for winter 2013/14 (close by October 15th) > > Hi all, > > we have the votes we need: 7 ayes by > > ·Bromium > > ·CA > > ·Calxeda > > ·Citrix > > ·Google > > ·Intel > > ·Oracle > > I will get started on this right away, such that Konrad can get going > when he is back next week. I will add the decision to the AB wiki. > > Regards > > Lars > > --------------050405070801000004050702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi all,

I got confirmation that this is still OK. So we will have one student to work on a Xen project that the Advisory Boards will fund. I created
http://wiki.xenproject.org/wiki/OutreachProgramForWomen/Round7
http://wiki.xenproject.org/wiki/OutreachProgramForWomen/OPWApply

I copied the GSoC list and prospective mentors are:
* Konrad
* George
* Anil
* Ian Campvell
* Ian Jackson
* Roger
* Dario
* Anthony

If your name is listed above:
* review the projects in http://wiki.xenproject.org/wiki/OutreachProgramForWomen/Round7 and REMOVE those that are done already
* REMOVE your projects fvrom the list if you are NOT willing to mentor

Best Regards
Lars

On 15/10/2013 17:26, Lars Kurth wrote:
Hi all,

I just got the last vote in for the Advisory Board sponsoring a student to work on the Xen Project for this winter round. The deadlines are tight and it is possible that we may not get the paperwork done in time. I will hopefully know in a day or two and will then immediately create the landing page, etc.

Assuming all goes well, we will need a mentor and a few suitable projects. Do we have any volunteers and suitable projects?

Regards
Lars
 

From: Lars Kurth
Sent: 15 October 2013 15:33
To: Advisory-board discussions
Cc: Konrad Rzeszutek Wilk (konrad.wilk@oracle.com)
Subject: RE: [Advisory-board] Xen Project AB VOTE: Sponsoring one intern for winter 2013/14 (close by October 15th)

 

Hi all,

 

we have the votes we need: 7 ayes by

·         Bromium

·         CA

·         Calxeda

·         Citrix

·         Google

·         Intel

·         Oracle

 

I will get started on this right away, such that Konrad can get going when he is back next week. I will add the decision to the AB wiki.

 

Regards

Lars



--------------050405070801000004050702-- From Chris.Greenhalgh@nottingham.ac.uk Wed Oct 16 18:55:45 2013 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VWVJx-00017y-OT (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 16 Oct 2013 18:55:45 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1532248 * 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from engine01-20433-7.icritical.com ([151.236.209.33]:39185) by ppsw-32.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with smtp id 1VWVJx-0006kz-16 (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 16 Oct 2013 18:55:45 +0100 Received: (qmail 3886 invoked from network); 16 Oct 2013 17:55:30 -0000 Received: from localhost (127.0.0.1) by engine01-20433-7.icritical.com with SMTP; 16 Oct 2013 17:55:30 -0000 Received: from engine01-20433-7.icritical.com ([127.0.0.1]) by localhost (engine01-20433-7.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 03482-07 for ; Wed, 16 Oct 2013 18:55:28 +0100 (BST) Received: (qmail 3877 invoked by uid 599); 16 Oct 2013 17:55:28 -0000 Received: from unknown (HELO smtp3.nottingham.ac.uk) (128.243.44.55) by engine01-20433-7.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 16 Oct 2013 18:55:28 +0100 Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp3.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1VWVJu-0005d1-Aa; Wed, 16 Oct 2013 18:55:42 +0100 From: Christopher Greenhalgh To: Mirage List Date: Wed, 16 Oct 2013 18:55:40 +0100 Subject: mutable store on mirage? Thread-Topic: mutable store on mirage? Thread-Index: AQHOypX4D7vl2MghCE+LzPudV5M59A== Message-ID: <4C20415C7327A849961F3B8421413725010CD72B64D9@EXCHANGE1.ad.nottingham.ac.uk> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: by iCritical at engine01-20433-7.icritical.com X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 17:55:45 -0000 Content-Length: 2566 Lines: 45 is there currently a sensible option for a mutable datastore in mirage?=20 i'd like to make an interactive web site/service and need at least the equi= valent of a persistent mutable key-value store with user-defined keys (e.g.= to take a minimal example, key =3D user ID, value =3D current user profile= information). a) I guess i could port baardskeerder - has that been done already? b) 've had a look at irminsule, but=20 b.1) at the moment i don't actually get how you would use it in this kind o= f scenario, e.g. does my user defined key (e.g. user login) map to a tag an= d a value (e.g. their current profile information) to a value? or does the = whole current key/value state (i.e. user ID/value for all current users) ma= p to a single value and the 'current state' to a single tag? or something e= lse??=20 b.2) is there currently a mirage (non-unix) backend for it? c) in a previous incarnation of mirage i started to write a mutable (strict= ly append only) key/value over that version of blkif, but ran out of time/e= nergy; is this obviously a waste of time/duplication of effort or would it = be useful/sensible? =20 d.1) is there any reason for/against persisting directly against blkif in m= irage? i,e, with not filesystem abstraction? d.2) as far as i can see the only up-to-date filesystem in mirage is the cr= unch RO fs; the fat fs is mostly there but need porting to the latest blkif= interface, and there aren't any others at the moment - is that right?! e) the mirage-unix OS has a skeleton blkif (over file) implementation but t= his is currently unimplemented; is it worth implementing and using this for= posix or do we expect to use something like dave's ocaml xen-block-driver = and xen-disk to emulate block devices from files instead even on posix targ= ets? cheers chris This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From scott.dj@gmail.com Wed Oct 16 21:09:01 2013 Received: from ppsw-mx-f.csi.cam.ac.uk ([131.111.8.149] helo=ppsw-42.csi.cam.ac.uk) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VWXOv-00040u-HA (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 16 Oct 2013 21:09:01 +0100 X-Cam-SpamScore: ss X-Cam-SpamDetails: score 2.6 from SpamAssassin-3.3.2-1532248 * 2.0 RCVD_IN_MAPS_RBL RBL: Relay in RBL, * http://www.mail-abuse.com/enduserinfo_rbl.html * [209.85.160.54 listed in rbl-plus.mail-abuse.ja.net] * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.160.54 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (scott.dj[at]gmail.com) * 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is * CUSTOM_MED * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid * 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing * list X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-pb0-f54.google.com ([209.85.160.54]:63236) by ppsw-42.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with esmtp id 1VWXOu-0004Wn-8V (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 16 Oct 2013 21:09:01 +0100 Received: by mail-pb0-f54.google.com with SMTP id ro12so1287151pbb.13 for ; Wed, 16 Oct 2013 13:08:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.170.68 with SMTP id ak4mr14786pbc.202.1381954139564; Wed, 16 Oct 2013 13:08:59 -0700 (PDT) Received: by 10.70.56.36 with HTTP; Wed, 16 Oct 2013 13:08:59 -0700 (PDT) In-Reply-To: <4C20415C7327A849961F3B8421413725010CD72B64D9@EXCHANGE1.ad.nottingham.ac.uk> References: <4C20415C7327A849961F3B8421413725010CD72B64D9@EXCHANGE1.ad.nottingham.ac.uk> Date: Wed, 16 Oct 2013 21:08:59 +0100 Message-ID: Subject: Re: mutable store on mirage? From: David Scott To: Christopher Greenhalgh Content-Type: multipart/alternative; boundary=047d7ba96da095b2dc04e8e145a0 Cc: Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 20:09:01 -0000 Content-Length: 7745 Lines: 159 --047d7ba96da095b2dc04e8e145a0 Content-Type: text/plain; charset=ISO-8859-1 Hi Chris. On Wed, Oct 16, 2013 at 6:55 PM, Christopher Greenhalgh < Chris.Greenhalgh@nottingham.ac.uk> wrote: > is there currently a sensible option for a mutable datastore in mirage? > i'd like to make an interactive web site/service and need at least the > equivalent of a persistent mutable key-value store with user-defined keys > (e.g. to take a minimal example, key = user ID, value = current user > profile information). > > a) I guess i could port baardskeerder - has that been done already? > I made an attempt a while ago, back here: https://github.com/djs55/mirage/tree/baardskeerder I didn't hook it up to blkif because the blkif wasn't very stable back then. It's worth another look now though. > b) 've had a look at irminsule, but > b.1) at the moment i don't actually get how you would use it in this kind > of scenario, e.g. does my user defined key (e.g. user login) map to a tag > and a value (e.g. their current profile information) to a value? or does > the whole current key/value state (i.e. user ID/value for all current > users) map to a single value and the 'current state' to a single tag? or > something else?? > b.2) is there currently a mirage (non-unix) backend for it? > > c) in a previous incarnation of mirage i started to write a mutable > (strictly append only) key/value over that version of blkif, but ran out of > time/energy; is this obviously a waste of time/duplication of effort or > would it be useful/sensible? > > d.1) is there any reason for/against persisting directly against blkif in > mirage? i,e, with not filesystem abstraction? > d.2) as far as i can see the only up-to-date filesystem in mirage is the > crunch RO fs; the fat fs is mostly there but need porting to the latest > blkif interface, and there aren't any others at the moment - is that right?! > I think blkif is stable enough to use now, although the interface will probably need to evolve a bit. TBH we'll only really know what the interface should be when we have a bunch of code trying to use it. I've got a branch of mirage-www which replaces the 'crunch' fs with data read from blkif in .tar format: https://github.com/mirage/mirage-www/pull/38 > e) the mirage-unix OS has a skeleton blkif (over file) implementation but > this is currently unimplemented; is it worth implementing and using this > for posix or do we expect to use something like dave's ocaml > xen-block-driver and xen-disk to emulate block devices from files instead > even on posix targets? > I'd like to see unix blkif implemented (without using the xen implementation). I've got some patches lying around which open files with O_DIRECT and perform unbuffered sector-aligned I/O. I was thinking of making a 'unix-block-driver' with this code in it, mirroring the xen implementation. It's mostly a thin veneer over Lwt_bytes, replacing Bigarray.t with Cstruct.t. In future I was thinking the mirage-platform repo could become the minimal 'boot' code plus module types for Blkif, Netif etc; and all the concrete implementations could be spun out into other repos. What do people think? Cheers, Dave --047d7ba96da095b2dc04e8e145a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Chris.

On Wed, Oct 16, 2013 at 6:55 PM, Christopher Greenhalgh <Chris.Greenhalgh@nottingham.ac.uk> wrote:
is there currently a sensible option for a mutable datasto= re in mirage?
i'd like to make an interactive web site/service and need at least the = equivalent of a persistent mutable key-value store with user-defined keys (= e.g. to take a minimal example, key =3D user ID, value =3D current user pro= file information).

a) I guess i could port baardskeerder - has that been done already?

I made an attempt a while ago, back here:


I didn't hook it up to blkif because the blkif wasn= 't very stable back then. It's worth another look now though.
=


b) 've had a look at irminsule, but
b.1) at the moment i don't actually get how you would use it in this ki= nd of scenario, e.g. does my user defined key (e.g. user login) map to a ta= g and a value (e.g. their current profile information) to a value? or does = the whole current key/value state (i.e. user ID/value for all current users= ) map to a single value and the 'current state' to a single tag? or= something else??
b.2) is there currently a mirage (non-unix) backend for it?

c) in a previous incarnation of mirage i started to write a mutable (strict= ly append only) key/value over that version of blkif, but ran out of time/e= nergy; is this obviously a waste of time/duplication of effort or would it = be useful/sensible?

d.1) is there any reason for/against persisting directly against blkif in m= irage? i,e, with not filesystem abstraction?
d.2) as far as i can see the only up-to-date filesystem in mirage is the cr= unch RO fs; the fat fs is mostly there but need porting to the latest blkif= interface, and there aren't any others at the moment - is that right?!=

I think blkif is stable enough to use now,= although the interface will probably need to evolve a bit. TBH we'll o= nly really know what the interface should be when we have a bunch of code t= rying to use it. I've got a branch of mirage-www which replaces the = 9;crunch' fs with data read from blkif in .tar format:

=A0
e) the mirage-unix OS has a skeleton blkif (over file) implementation but t= his is currently unimplemented; is it worth implementing and using this for= posix or do we expect to use something like dave's ocaml xen-block-dri= ver and xen-disk to emulate block devices from files instead even on posix = targets?

I'd like to see unix blkif implemented= (without using the xen implementation). I've got some patches lying ar= ound which open files with O_DIRECT and perform unbuffered sector-aligned I= /O. I was thinking of making a 'unix-block-driver' with this code i= n it, mirroring the xen implementation. It's mostly a thin veneer over = Lwt_bytes, replacing Bigarray.t with Cstruct.t. In future I was thinking th= e mirage-platform repo could become the minimal 'boot' code plus mo= dule types for Blkif, Netif etc; and all the concrete implementations could= be spun out into other repos.

What do people think?

Cheers,<= /div>
Dave

--047d7ba96da095b2dc04e8e145a0-- From Richard.Mortier@nottingham.ac.uk Wed Oct 16 21:16:43 2013 Received: from ppsw-mx-f.csi.cam.ac.uk ([131.111.8.149] helo=ppsw-42.csi.cam.ac.uk) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VWXWN-0004C3-0C (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 16 Oct 2013 21:16:43 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1532248 * 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from engine06-20433-6.icritical.com ([195.62.217.150]:33038) by ppsw-42.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with smtp id 1VWXWM-0006pv-8Z (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 16 Oct 2013 21:16:42 +0100 Received: (qmail 827 invoked from network); 16 Oct 2013 20:16:36 -0000 Received: from localhost (127.0.0.1) by engine06-20433-6.icritical.com with SMTP; 16 Oct 2013 20:16:36 -0000 Received: from engine06-20433-6.icritical.com ([127.0.0.1]) by localhost (engine06-20433-6.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 00321-03 for ; Wed, 16 Oct 2013 21:16:35 +0100 (BST) Received: (qmail 819 invoked by uid 599); 16 Oct 2013 20:16:35 -0000 Received: from unknown (HELO smtp3.nottingham.ac.uk) (128.243.44.55) by engine06-20433-6.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 16 Oct 2013 21:16:35 +0100 Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp3.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1VWXWJ-0001AT-R7; Wed, 16 Oct 2013 21:16:39 +0100 From: Richard Mortier To: David Scott Date: Wed, 16 Oct 2013 21:16:38 +0100 Subject: Re: mutable store on mirage? Thread-Topic: mutable store on mirage? Thread-Index: Ac7KrJ6wpotik4bdT+2QS8KhDKYEFA== Message-ID: <2A9BC77A-0999-4C6E-AC17-C35983A7A6E3@nottingham.ac.uk> References: <4C20415C7327A849961F3B8421413725010CD72B64D9@EXCHANGE1.ad.nottingham.ac.uk> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: by iCritical at engine06-20433-6.icritical.com Cc: Christopher Greenhalgh , Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 20:16:43 -0000 Content-Length: 1747 Lines: 44 On 16 Oct 2013, at 21:08, David Scott wrote: > I'd like to see unix blkif implemented (without using the xen implementat= ion). I've got some patches lying around which open files with O_DIRECT and= perform unbuffered sector-aligned I/O. I was thinking of making a 'unix-bl= ock-driver' with this code in it, mirroring the xen implementation. It's mo= stly a thin veneer over Lwt_bytes, replacing Bigarray.t with Cstruct.t. In = future I was thinking the mirage-platform repo could become the minimal 'bo= ot' code plus module types for Blkif, Netif etc; and all the concrete imple= mentations could be spun out into other repos. >=20 > What do people think? absolutely agree. thought perhaps we would want to functorise(*) over Lwt, = eg packages named mirage-blk-xen-lwt mirage-blk-posix-async mirage-blk-bsd-blah etc...? opam can handle the constraints though (i firmly expect :) (*) if i'm making up a verb there and/or using it incorrectly, i apologise.= .. :) --=20 Cheers, R. This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From thomas.gazagnaire@gmail.com Thu Oct 17 09:11:57 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VWigX-0005a3-Q5 (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Thu, 17 Oct 2013 09:11:57 +0100 X-Cam-SpamDetails: score -0.6 from SpamAssassin-3.3.2-1532689 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.212.182 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (thomas.gazagnaire[at]gmail.com) * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-wi0-f182.google.com ([209.85.212.182]:48287) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with esmtp id 1VWigX-0001qb-g1 (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Thu, 17 Oct 2013 09:11:57 +0100 Received: by mail-wi0-f182.google.com with SMTP id ez12so2052597wid.3 for ; Thu, 17 Oct 2013 01:11:56 -0700 (PDT) X-Received: by 10.180.211.206 with SMTP id ne14mr5857274wic.30.1381997516807; Thu, 17 Oct 2013 01:11:56 -0700 (PDT) Received: from [192.168.0.12] (sud35-6-83-152-60-83.fbx.proxad.net. [83.152.60.83]) by mx.google.com with ESMTPSA id b13sm13582445wic.9.2013.10.17.01.11.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 01:11:55 -0700 (PDT) Sender: Thomas Gazagnaire Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: mutable store on mirage? From: Thomas Gazagnaire In-Reply-To: Date: Thu, 17 Oct 2013 09:35:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C20415C7327A849961F3B8421413725010CD72B64D9@EXCHANGE1.ad.nottingham.ac.uk> To: David Scott X-Mailer: Apple Mail (2.1510) Cc: Christopher Greenhalgh , Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 08:11:57 -0000 Content-Length: 1935 Lines: 45 Hi, > b) 've had a look at irminsule, but > b.1) at the moment i don't actually get how you would use it in this = kind of scenario, e.g. does my user defined key (e.g. user login) map to = a tag and a value (e.g. their current profile information) to a value? = or does the whole current key/value state (i.e. user ID/value for all = current users) map to a single value and the 'current state' to a single = tag? or something else?? > b.2) is there currently a mirage (non-unix) backend for it? I'm working to make irminsule more usable at the moment, and I plan to = make a first release for the end of the month. But yes, you are right, = for now that's just a proof of concept, so I won't use it in production = (yet). > https://github.com/mirage/mirage-www/pull/38 > =20 > e) the mirage-unix OS has a skeleton blkif (over file) implementation = but this is currently unimplemented; is it worth implementing and using = this for posix or do we expect to use something like dave's ocaml = xen-block-driver and xen-disk to emulate block devices from files = instead even on posix targets? >=20 > I'd like to see unix blkif implemented (without using the xen = implementation). I've got some patches lying around which open files = with O_DIRECT and perform unbuffered sector-aligned I/O. I was thinking = of making a 'unix-block-driver' with this code in it, mirroring the xen = implementation. It's mostly a thin veneer over Lwt_bytes, replacing = Bigarray.t with Cstruct.t. In future I was thinking the mirage-platform = repo could become the minimal 'boot' code plus module types for Blkif, = Netif etc; and all the concrete implementations could be spun out into = other repos. >=20 > What do people think? I think that will be *very* useful. Then, using this to build a simple (but efficient) append-only k/v store = (string -> Cstruct.t) with an interface which looks similar on linux and = xen would be great! Thomas From konrad.wilk@oracle.com Fri Oct 18 18:19:52 2013 Received: from ppsw-42.csi.cam.ac.uk ([131.111.8.142]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VXDiK-00076S-48 (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 18 Oct 2013 18:19:52 +0100 X-Cam-SpamDetails: score -2.7 from SpamAssassin-3.3.2-1533008 * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, * medium trust * [156.151.31.81 listed in list.dnswl.dnsbl.ja.net] * -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay * domain * 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay * lines X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from userp1040.oracle.com ([156.151.31.81]:19529) by ppsw-42.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with esmtp id 1VXDiI-0008LF-9N (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 18 Oct 2013 18:19:51 +0100 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9IHJiXt026599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Oct 2013 17:19:45 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9IHJglI011566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Oct 2013 17:19:43 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9IHJfcN011572; Fri, 18 Oct 2013 17:19:41 GMT Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 18 Oct 2013 10:19:41 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id C3FC51BF6F2; Fri, 18 Oct 2013 13:19:39 -0400 (EDT) Date: Fri, 18 Oct 2013 13:19:39 -0400 From: Konrad Rzeszutek Wilk To: Lars Kurth , boris.ostrovsky@oracle.com Subject: Re: Xen Project to Sponsor one student for Gnome Womens Outreach winter round (Urgent) Message-ID: <20131018171939.GC2897@phenom.dumpdata.com> References: <525D6CB7.8070301@xen.org> <525EAF90.4080400@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <525EAF90.4080400@xen.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Ian Campbell , Anil Madhavapeddy , George Dunlap , Dario Faggioli , Ian Jackson , "xen-devel@lists.xen.org" , Anthony PERARD , Roger Pau Monne , "cl-mirage@lists.cam.ac.uk List" , "xen-api@lists.xen.org" X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:19:52 -0000 Content-Length: 1766 Lines: 57 On Wed, Oct 16, 2013 at 04:24:00PM +0100, Lars Kurth wrote: > Hi all, > > I got confirmation that this is still OK. So we will have one > student to work on a Xen project that the Advisory Boards will fund. Yeeey! > I created > http://wiki.xenproject.org/wiki/OutreachProgramForWomen/Round7 > http://wiki.xenproject.org/wiki/OutreachProgramForWomen/OPWApply > > I copied the GSoC list and prospective mentors are: > * Konrad > * George > * Anil > * Ian Campvell > * Ian Jackson > * Roger > * Dario > * Anthony > > If your name is listed above: > * review the projects in > http://wiki.xenproject.org/wiki/OutreachProgramForWomen/Round7 and > REMOVE those that are done already Done. > * REMOVE your projects fvrom the list if you are NOT willing to mentor Is there a deadline for this list to become golden? Also, we can insert projects under the http://kernelnewbies.org/OPWIntro as a "Linux and Xen" if there is a project that would be more of "in the Linux land" type. Are folks OK with that? We only have one intern slot. Right now the one that I can think of that would fit within this is: - "VCPUOP_register_vcpu_time_memory_area" - backport and fix it, make sure that glibc works, run benchamrks, etc. That would also entail some looking at rdstc, gettimeofday calls and all of that to figure out where/what holes there are with Linux PV and HVM guests in this area. - Implement the 'multi-MSI' hypercall in the Linux kernel. Jan posted an RFC patch. - Implement proper PAT "sandbox". hpa wants a software translation lookup table - similar to how guests MTRR values are looked up in the Xen. I can mentor them all - though I would appreciate some backup (Boris?) Yes/No? Lars, Thank you for taking this up while I was out! From Chris.Greenhalgh@nottingham.ac.uk Mon Oct 21 20:57:10 2013 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VYLbC-0005ZK-Ok (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 21 Oct 2013 20:57:10 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1533363 * 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from engine03-20433-8.icritical.com ([93.159.202.52]:46250) by ppsw-32.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with smtp id 1VYLbC-00074j-0C (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 21 Oct 2013 20:57:10 +0100 Received: (qmail 7282 invoked from network); 21 Oct 2013 19:56:55 -0000 Received: from localhost (127.0.0.1) by engine03-20433-8.icritical.com with SMTP; 21 Oct 2013 19:56:55 -0000 Received: from engine03-20433-8.icritical.com ([127.0.0.1]) by localhost (engine03-20433-8.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 07003-04 for ; Mon, 21 Oct 2013 20:56:54 +0100 (BST) Received: (qmail 7272 invoked by uid 599); 21 Oct 2013 19:56:54 -0000 Received: from unknown (HELO smtp3.nottingham.ac.uk) (128.243.44.55) by engine03-20433-8.icritical.com (qpsmtpd/0.28) with ESMTP; Mon, 21 Oct 2013 20:56:54 +0100 Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp3.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1VYLb8-00072Q-Iy; Mon, 21 Oct 2013 20:57:06 +0100 From: Christopher Greenhalgh To: Mirage List Date: Mon, 21 Oct 2013 20:57:06 +0100 Subject: RE: mutable store on mirage? Thread-Topic: mutable store on mirage? Thread-Index: Ac7KrJ6wpotik4bdT+2QS8KhDKYEFAD5+qE3 Message-ID: <4C20415C7327A849961F3B8421413725010CD72B64DC@EXCHANGE1.ad.nottingham.ac.uk> References: <4C20415C7327A849961F3B8421413725010CD72B64D9@EXCHANGE1.ad.nottingham.ac.uk> , <2A9BC77A-0999-4C6E-AC17-C35983A7A6E3@nottingham.ac.uk> In-Reply-To: <2A9BC77A-0999-4C6E-AC17-C35983A7A6E3@nottingham.ac.uk> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: by iCritical at engine03-20433-8.icritical.com Cc: Christopher Greenhalgh X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:57:10 -0000 Content-Length: 3855 Lines: 90 Partly as a learning exercise I have made a blkif implementation over a sin= gle file using Lwt_unix - https://github.com/cgreenhalgh/mirage-unix-simple= -blkif It has a couple of basic tests which it passes, but hasn't been exercised b= eyond that yet;=20 Neither is it abstracted over threading, but then the Blkif interface isn't= yet either...=20 i intend to try using it as a baardskeerder store next, so we'll see what h= appens. Threw up a few questions... As noted in the comment near the top of https://github.com/cgreenhalgh/mira= ge-unix-simple-blkif/blob/master/lib/blkdev.ml i don't think it will behave= precisely the same as ocaml-xen-block-driver for concurrent multi-block re= ads and writes: currently it will do each in one chunk while the xen driver= subdivides and potentially interleaves large reads and... Btw there seems to be an ambiguity in the OS.Devices.Blkif interface, speci= fically what should happen if write_page is called with an Io_page which is= actually >1 page long (e.g.from Io_page.get N)? ocaml-xen-block-driver wri= te_page seems to assume that it will be exactly one page (without checking)= but is the intended bevaviour (a) split pages and handle each page in turn= or (b) explicit error? It is also slightly unclear (to me) what the ordering semantics are intende= d to be for read_512; currently this and the xen-block-driver only actually= initiate the read when a thread attempts a (blocking) get on the returned = Lwt_sequence. This is the more obvious route as read_512 is non-blocking (i= .e. has to immediately return the sequence), but feels slightly odd. p.s. as there is no sync operation, is there a particular level of sync to = disk/durability defined in the xen block protocol? I'm also unsure if it is deliberate that Io_page.page_size isn't visible; i= had to use Io_page.round_to_page_size 1 to get page_size out... cheers chris _________________________ From: Richard Mortier [Richard.Mortier@nottingham.ac.uk] Sent: 16 October 2013 21:16 To: David Scott Cc: Christopher Greenhalgh; Mirage List Subject: Re: mutable store on mirage? On 16 Oct 2013, at 21:08, David Scott wrote: > I'd like to see unix blkif implemented (without using the xen implementat= ion). I've got some patches lying around which open files with O_DIRECT and= perform unbuffered sector-aligned I/O. I was thinking of making a 'unix-bl= ock-driver' with this code in it, mirroring the xen implementation. It's mo= stly a thin veneer over Lwt_bytes, replacing Bigarray.t with Cstruct.t. In = future I was thinking the mirage-platform repo could become the minimal 'bo= ot' code plus module types for Blkif, Netif etc; and all the concrete imple= mentations could be spun out into other repos. > > What do people think? absolutely agree. thought perhaps we would want to functorise(*) over Lwt, = eg packages named mirage-blk-xen-lwt mirage-blk-posix-async mirage-blk-bsd-blah etc...? opam can handle the constraints though (i firmly expect :) (*) if i'm making up a verb there and/or using it incorrectly, i apologise.= .. :) -- Cheers, R. This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From scott.dj@gmail.com Mon Oct 21 21:15:59 2013 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VYLtP-0006A5-A2 (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 21 Oct 2013 21:15:59 +0100 X-Cam-SpamScore: s X-Cam-SpamDetails: score 1.3 from SpamAssassin-3.3.2-1533363 * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [209.85.192.178 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (scott.dj[at]gmail.com) * 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is * CUSTOM_MED * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid * 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing * list X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-pd0-f178.google.com ([209.85.192.178]:33031) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.148]:25) with esmtp id 1VYLtO-0006tm-DU (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 21 Oct 2013 21:15:59 +0100 Received: by mail-pd0-f178.google.com with SMTP id w10so9153151pde.9 for ; Mon, 21 Oct 2013 13:15:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.170.68 with SMTP id ak4mr1216313pbc.202.1382386557075; Mon, 21 Oct 2013 13:15:57 -0700 (PDT) Received: by 10.70.56.36 with HTTP; Mon, 21 Oct 2013 13:15:57 -0700 (PDT) In-Reply-To: <4C20415C7327A849961F3B8421413725010CD72B64DC@EXCHANGE1.ad.nottingham.ac.uk> References: <4C20415C7327A849961F3B8421413725010CD72B64D9@EXCHANGE1.ad.nottingham.ac.uk> <2A9BC77A-0999-4C6E-AC17-C35983A7A6E3@nottingham.ac.uk> <4C20415C7327A849961F3B8421413725010CD72B64DC@EXCHANGE1.ad.nottingham.ac.uk> Date: Mon, 21 Oct 2013 21:15:57 +0100 Message-ID: Subject: Re: mutable store on mirage? From: David Scott To: Christopher Greenhalgh Content-Type: multipart/alternative; boundary=047d7ba96da0ad482704e945f335 Cc: Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 20:15:59 -0000 Content-Length: 10070 Lines: 260 --047d7ba96da0ad482704e945f335 Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, Thanks for taking a look at this. When I get a moment I'll check out your code and see if it makes sense to merge in some patches I've got lying around. The Blkif API is very quirky. I think we should chuck it away and put something sensible in place. Feel free to propose a new signature! :-) Cheers, Dave On Mon, Oct 21, 2013 at 8:57 PM, Christopher Greenhalgh < Chris.Greenhalgh@nottingham.ac.uk> wrote: > Partly as a learning exercise I have made a blkif implementation over a > single file using Lwt_unix - > https://github.com/cgreenhalgh/mirage-unix-simple-blkif > It has a couple of basic tests which it passes, but hasn't been exercised > beyond that yet; > Neither is it abstracted over threading, but then the Blkif interface > isn't yet either... > i intend to try using it as a baardskeerder store next, so we'll see what > happens. > > Threw up a few questions... > > As noted in the comment near the top of > https://github.com/cgreenhalgh/mirage-unix-simple-blkif/blob/master/lib/blkdev.mli don't think it will behave precisely the same as ocaml-xen-block-driver > for concurrent multi-block reads and writes: currently it will do each in > one chunk while the xen driver subdivides and potentially interleaves large > reads and... > > Btw there seems to be an ambiguity in the OS.Devices.Blkif interface, > specifically what should happen if write_page is called with an Io_page > which is actually >1 page long (e.g.from Io_page.get N)? > ocaml-xen-block-driver write_page seems to assume that it will be exactly > one page (without checking) but is the intended bevaviour (a) split pages > and handle each page in turn or (b) explicit error? > > It is also slightly unclear (to me) what the ordering semantics are > intended to be for read_512; currently this and the xen-block-driver only > actually initiate the read when a thread attempts a (blocking) get on the > returned Lwt_sequence. This is the more obvious route as read_512 is > non-blocking (i.e. has to immediately return the sequence), but feels > slightly odd. > > p.s. as there is no sync operation, is there a particular level of sync to > disk/durability defined in the xen block protocol? > > I'm also unsure if it is deliberate that Io_page.page_size isn't visible; > i had to use Io_page.round_to_page_size 1 to get page_size out... > > cheers > chris > > > _________________________ > From: Richard Mortier [Richard.Mortier@nottingham.ac.uk] > Sent: 16 October 2013 21:16 > To: David Scott > Cc: Christopher Greenhalgh; Mirage List > Subject: Re: mutable store on mirage? > > On 16 Oct 2013, at 21:08, David Scott wrote: > > > I'd like to see unix blkif implemented (without using the xen > implementation). I've got some patches lying around which open files with > O_DIRECT and perform unbuffered sector-aligned I/O. I was thinking of > making a 'unix-block-driver' with this code in it, mirroring the xen > implementation. It's mostly a thin veneer over Lwt_bytes, replacing > Bigarray.t with Cstruct.t. In future I was thinking the mirage-platform > repo could become the minimal 'boot' code plus module types for Blkif, > Netif etc; and all the concrete implementations could be spun out into > other repos. > > > > What do people think? > > absolutely agree. thought perhaps we would want to functorise(*) over Lwt, > eg packages named > > mirage-blk-xen-lwt > mirage-blk-posix-async > mirage-blk-bsd-blah > > etc...? opam can handle the constraints though (i firmly expect :) > > (*) if i'm making up a verb there and/or using it incorrectly, i > apologise... :) > > > -- > Cheers, > > R. > > > > This message and any attachment are intended solely for the addressee and > may contain confidential information. If you have received this message in > error, please send it back to me, and immediately delete it. Please do > not use, copy or disclose the information contained in this message or in > any attachment. Any views or opinions expressed by the author of this > email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer > system, you are advised to perform your own checks. Email communications > with the University of Nottingham may be monitored as permitted by UK > legislation. > > > > > > -- Dave Scott --047d7ba96da0ad482704e945f335 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Chris,

Thanks for taking a look at t= his. When I get a moment I'll check out your code and see if it makes s= ense to merge in some patches I've got lying around.

The Blkif API is very quirky. I think we should chuck it away and put = something sensible in place. Feel free to propose a new signature! :-)

Cheers,
Dave


On Mon, Oct 21, 2013 at 8:57 PM, Christo= pher Greenhalgh <Chris.Greenhalgh@nottingham.ac.uk>= wrote:
Partly as a learning exercise I have made a = blkif implementation over a single file using Lwt_unix - https:/= /github.com/cgreenhalgh/mirage-unix-simple-blkif
It has a couple of basic tests which it passes, but hasn't been exercis= ed beyond that yet;
Neither is it abstracted over threading, but then the Blkif interface isn&#= 39;t yet either...
i intend to try using it as a baardskeerder store next, so we'll see wh= at happens.

Threw up a few questions...

As noted in the comment near the top of https://github.com/cgreenhalgh/mirage-unix-simple-blkif/blob/master/lib/b= lkdev.ml i don't think it will behave precisely the same as ocaml-x= en-block-driver for concurrent multi-block reads and writes: currently it w= ill do each in one chunk while the xen driver subdivides and potentially in= terleaves large reads and...

Btw there seems to be an ambiguity in the OS.Devices.Blkif interface, speci= fically what should happen if write_page is called with an Io_page which is= actually >1 page long (e.g.from Io_page.get N)? ocaml-xen-block-driver = write_page seems to assume that it will be exactly one page (without checki= ng) but is the intended bevaviour (a) split pages and handle each page in t= urn or (b) explicit error?

It is also slightly unclear (to me) what the ordering semantics are intende= d to be for read_512; currently this and the xen-block-driver only actually= initiate the read when a thread attempts a (blocking) get on the returned = Lwt_sequence. This is the more obvious route as read_512 is non-blocking (i= .e. has to immediately return the sequence), but feels slightly odd.

p.s. as there is no sync operation, is there a particular level of sync to = disk/durability defined in the xen block protocol?

I'm also unsure if it is deliberate that Io_page.page_size isn't vi= sible; i had to use Io_page.round_to_page_size 1 to get page_size out...
cheers
chris


_________________________
From: Richard Mortier [= Richard.Mortier@nottingham.ac.uk]
Sent: 16 October 2013 21:16
To: David Scott
Cc: Christopher Greenhalgh; Mirage List
Subject: Re: mutable store on mirage?

On 16 Oct 2013, at 21:08, David Scott wrote:

> I'd like to see unix blkif implemented (without using the xen impl= ementation). I've got some patches lying around which open files with O= _DIRECT and perform unbuffered sector-aligned I/O. I was thinking of making= a 'unix-block-driver' with this code in it, mirroring the xen impl= ementation. It's mostly a thin veneer over Lwt_bytes, replacing Bigarra= y.t with Cstruct.t. In future I was thinking the mirage-platform repo could= become the minimal 'boot' code plus module types for Blkif, Netif = etc; and all the concrete implementations could be spun out into other repo= s.
>
> What do people think?

absolutely agree. thought perhaps we would want to functorise(*) over Lwt, = eg packages named

mirage-blk-xen-lwt
mirage-blk-posix-async
mirage-blk-bsd-blah

etc...? =A0opam can handle the constraints though (i firmly expect :)

(*) if i'm making up a verb there and/or using it incorrectly, i apolog= ise... :)


--
Cheers,

R.



This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in e= rror, please send it back to me, and immediately delete it. =A0 Please do n= ot use, copy or disclose the information contained in this message or in an= y attachment. =A0Any views or opinions expressed by the author of this emai= l do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment=
may still contain software viruses which could damage your computer system,= you are advised to perform your own checks. Email communications with the = University of Nottingham may be monitored as permitted by UK legislation.







--
= Dave Scott
--047d7ba96da0ad482704e945f335-- From russell.pavlicek.xen@gmail.com Tue Oct 22 15:33:57 2013 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VYd1x-0004oJ-4m (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 22 Oct 2013 15:33:57 +0100 X-Cam-SpamScore: s X-Cam-SpamDetails: score 1.9 from SpamAssassin-3.3.2-1533363 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.217.175 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (russell.pavlicek.xen[at]gmail.com) * 2.5 SUSPICIOUS_RECIPS Similar addresses in recipient list * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-lb0-f175.google.com ([209.85.217.175]:50441) by ppsw-32.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp id 1VYd1w-0007bt-0x (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 22 Oct 2013 15:33:57 +0100 Received: by mail-lb0-f175.google.com with SMTP id z5so1922572lbh.6 for ; Tue, 22 Oct 2013 07:33:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.37.130 with SMTP id y2mr16083278laj.24.1382452435706; Tue, 22 Oct 2013 07:33:55 -0700 (PDT) Sender: russell.pavlicek.xen@gmail.com Received: by 10.112.52.170 with HTTP; Tue, 22 Oct 2013 07:33:55 -0700 (PDT) Date: Tue, 22 Oct 2013 10:33:55 -0400 X-Google-Sender-Auth: aENpqwWygrbDGDNqZJ_zeeeH94U Message-ID: Subject: REMINDER: Xen Project Documentation Day is next Monday From: Russ Pavlicek To: "xen-users@lists.xen.org" , xen-devel@lists.xen.org, xen-api@lists.xen.org, xs-devel@lists.xenserver.org, cl-mirage@lists.cam.ac.uk Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 14:33:57 -0000 Content-Length: 1514 Lines: 39 Next Monday, October 28, is our next Xen Project Document Day. Xen Documentation Days are for people who care about Xen documentation and want to improve it. We introduced Documentation Days because working on documentation in parallel with like minded-people is just more fun than working alone. Also, this is the perfect way for people who are not contributing code to support the Xen Project. If you are a Xen user and had to dig to find useful information, consider improving the documentation so that the next person doesn't have to work so hard to figure out what you learned. For a list of items that need work, check out the community maintained TODO list at http://wiki.xen.org/wiki/Xen_Document_Days/TODO . Of course, you can work on anything you'd like; the TODO list provides a handy list of documents needing attention. Also, because of spam activities on the Wiki, you will need to request write access to the Wiki itself. Use the link atop the Xen Documentation Day page to request write access (see http://wiki.xenproject.org/wiki/Xen_Document_Days). If you request access this week, nothing will slow down your progress on Monday. How to join in: =========== - Join us on IRC: freenode channel #xendocs - Tell people what you intend to work on (to avoid doing something somebody else is already working on) - Fix some documentation - Help others - And above all: have fun! It all happens next Monday, so mark your calendars. See you on #xendocs! Russ Pavlicek Xen Project Evangelist From Chris.Greenhalgh@nottingham.ac.uk Wed Oct 23 16:45:33 2013 Received: from ppsw-42.csi.cam.ac.uk ([131.111.8.142]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VZ0cn-0005M0-6O (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 23 Oct 2013 16:45:33 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1533363 * 0.0 HTML_MESSAGE BODY: HTML included in message X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from engine02-20433-2.icritical.com ([195.62.217.151]:44465) by ppsw-42.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with smtp id 1VZ0cl-0006bu-7d (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 23 Oct 2013 16:45:33 +0100 Received: (qmail 29045 invoked from network); 23 Oct 2013 15:43:07 -0000 Received: from localhost (127.0.0.1) by engine02-20433-2.icritical.com with SMTP; 23 Oct 2013 15:43:07 -0000 Received: from engine02-20433-2.icritical.com ([127.0.0.1]) by localhost (engine02-20433-2.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 28597-05 for ; Wed, 23 Oct 2013 16:43:04 +0100 (BST) Received: (qmail 27466 invoked by uid 599); 23 Oct 2013 15:42:09 -0000 Received: from unknown (HELO smtp4.nottingham.ac.uk) (128.243.220.65) by engine02-20433-2.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 23 Oct 2013 16:42:09 +0100 Received: from uiwexhub01.ad.nottingham.ac.uk ([128.243.15.133]) by smtp4.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1VZ0Zd-00048t-L2 for cl-mirage@lists.cam.ac.uk; Wed, 23 Oct 2013 16:42:17 +0100 From: Christopher Greenhalgh To: David Scott Date: Wed, 23 Oct 2013 16:42:13 +0100 Subject: RE: mutable store on mirage? Thread-Topic: mutable store on mirage? Thread-Index: Ac7OmmHTUEh3RJL7SkGfmrT4cK7fBQBatQIg Message-ID: <4C20415C7327A849961F3B8421413725010CD7203AAC@EXCHANGE1.ad.nottingham.ac.uk> References: <4C20415C7327A849961F3B8421413725010CD72B64D9@EXCHANGE1.ad.nottingham.ac.uk> <2A9BC77A-0999-4C6E-AC17-C35983A7A6E3@nottingham.ac.uk> <4C20415C7327A849961F3B8421413725010CD72B64DC@EXCHANGE1.ad.nottingham.ac.uk> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_4C20415C7327A849961F3B8421413725010CD7203AACEXCHANGE1ad_" MIME-Version: 1.0 X-Virus-Scanned: by iCritical at engine02-20433-2.icritical.com Cc: Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:45:33 -0000 Content-Length: 19583 Lines: 384 --_000_4C20415C7327A849961F3B8421413725010CD7203AACEXCHANGE1ad_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't feel like I know enough about block device internals to suggest an = alternative yet. I've now made a first-cut port of baardskeerder to mirage (splitting out mi= rage & unix dependencies into sub-packages): https://github.com/cgreenhalgh/baardskeerder This has a store that runs over blkif, but currently only the basic baardsk= eerder Flog0 log option (which has little resilience and no compaction). Th= e store also does no cacheing at the moment... (needs mirage 0.9.8, i.e. i= o_page fix) I've make a very simple mirage btree fa=E7ade over this: https://github.com/cgreenhalgh/ocaml-btree This is passing basic tests on unix, but I haven't got a test harness toget= her yet to try it on Xen. The Opam packages are in: https://github.com/cgreenhalgh/opam-dev-repository unix-simple-blkdev mirage-baardskeerder ocaml-btree cheers Chris From: cl-mirage-bounces@lists.cam.ac.uk [mailto:cl-mirage-bounces@lists.cam= .ac.uk] On Behalf Of David Scott Sent: 21 October 2013 21:16 To: Christopher Greenhalgh Cc: Mirage List Subject: Re: mutable store on mirage? Hi Chris, Thanks for taking a look at this. When I get a moment I'll check out your c= ode and see if it makes sense to merge in some patches I've got lying aroun= d. The Blkif API is very quirky. I think we should chuck it away and put somet= hing sensible in place. Feel free to propose a new signature! :-) Cheers, Dave On Mon, Oct 21, 2013 at 8:57 PM, Christopher Greenhalgh > wrote: Partly as a learning exercise I have made a blkif implementation over a sin= gle file using Lwt_unix - https://github.com/cgreenhalgh/mirage-unix-simple= -blkif It has a couple of basic tests which it passes, but hasn't been exercised b= eyond that yet; Neither is it abstracted over threading, but then the Blkif interface isn't= yet either... i intend to try using it as a baardskeerder store next, so we'll see what h= appens. Threw up a few questions... As noted in the comment near the top of https://github.com/cgreenhalgh/mira= ge-unix-simple-blkif/blob/master/lib/blkdev.ml i don't think it will behave= precisely the same as ocaml-xen-block-driver for concurrent multi-block re= ads and writes: currently it will do each in one chunk while the xen driver= subdivides and potentially interleaves large reads and... Btw there seems to be an ambiguity in the OS.Devices.Blkif interface, speci= fically what should happen if write_page is called with an Io_page which is= actually >1 page long (e.g.from Io_page.get N)? ocaml-xen-block-driver wri= te_page seems to assume that it will be exactly one page (without checking)= but is the intended bevaviour (a) split pages and handle each page in turn= or (b) explicit error? It is also slightly unclear (to me) what the ordering semantics are intende= d to be for read_512; currently this and the xen-block-driver only actually= initiate the read when a thread attempts a (blocking) get on the returned = Lwt_sequence. This is the more obvious route as read_512 is non-blocking (i= .e. has to immediately return the sequence), but feels slightly odd. p.s. as there is no sync operation, is there a particular level of sync to = disk/durability defined in the xen block protocol? I'm also unsure if it is deliberate that Io_page.page_size isn't visible; i= had to use Io_page.round_to_page_size 1 to get page_size out... cheers chris _________________________ From: Richard Mortier [Richard.Mortier@nottingham.ac.uk] Sent: 16 October 2013 21:16 To: David Scott Cc: Christopher Greenhalgh; Mirage List Subject: Re: mutable store on mirage? On 16 Oct 2013, at 21:08, David Scott wrote: > I'd like to see unix blkif implemented (without using the xen implementat= ion). I've got some patches lying around which open files with O_DIRECT and= perform unbuffered sector-aligned I/O. I was thinking of making a 'unix-bl= ock-driver' with this code in it, mirroring the xen implementation. It's mo= stly a thin veneer over Lwt_bytes, replacing Bigarray.t with Cstruct.t. In = future I was thinking the mirage-platform repo could become the minimal 'bo= ot' code plus module types for Blkif, Netif etc; and all the concrete imple= mentations could be spun out into other repos. > > What do people think? absolutely agree. thought perhaps we would want to functorise(*) over Lwt, = eg packages named mirage-blk-xen-lwt mirage-blk-posix-async mirage-blk-bsd-blah etc...? opam can handle the constraints though (i firmly expect :) (*) if i'm making up a verb there and/or using it incorrectly, i apologise.= .. :) -- Cheers, R. This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in e= rror, please send it back to me, and immediately delete it. Please do not= use, copy or disclose the information contained in this message or in any = attachment. Any views or opinions expressed by the author of this email do= not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system,= you are advised to perform your own checks. Email communications with the = University of Nottingham may be monitored as permitted by UK legislation. -- Dave Scott This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in er= ror, please send it back to me, and immediately delete it. Please do not u= se, copy or disclose the information contained in this message or in any att= achment. Any views or opinions expressed by the author of this email do not= necessarily reflect the views of the University of Nottingham.=0D=0A =0D=0A This message has been checked for viruses but the contents of an attachment= =0D=0A may still contain software viruses which could damage your computer system,= you are advised to perform your own checks. Email communications with the U= niversity of Nottingham may be monitored as permitted by UK legislation.=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A --_000_4C20415C7327A849961F3B8421413725010CD7203AACEXCHANGE1ad_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I donR= 17;t feel like I know enough about block device internals to suggest an alt= ernative yet.

 <= /o:p>

I’ve now made a first-cut= port of baardskeerder to mirage (splitting out mirage & unix dependenc= ies into sub-packages):

<= a href=3D"https://github.com/cgreenhalgh/baardskeerder">https://github.com/= cgreenhalgh/baardskeerder

This has a store that runs over blkif, but currently only the basic baa= rdskeerder Flog0 log option (which has little resilience and no compaction)= . The store also does no cacheing at the moment… =A0(needs mirage 0.9= .8, i.e. io_page fix)

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

<= p class=3DMsoNormal>I’ve make a very simple mirage btree fa=E7= ade over this:

https://github.com/cgreenhalgh/= ocaml-btree

This is p= assing basic tests on unix, but I haven’t got a test harness together= yet to try it on Xen.

 

The Opam packages are = in:

https://github.com/cgreenhalgh/op= am-dev-repository

unix= -simple-blkdev

mirage-baar= dskeerder

ocaml-btree=

 

cheers

= Chris

 

 

From: cl-mirage-bounces@= lists.cam.ac.uk [mailto:cl-mirage-bounces@lists.cam.ac.uk] On Behalf Of = David Scott
Sent: 21 October 2013 21:16
To: Christo= pher Greenhalgh
Cc: Mirage List
Subject: Re: mutable st= ore on mirage?

 <= /o:p>

Hi Chris,

 

Thanks for t= aking a look at this. When I get a moment I'll check out your code and see = if it makes sense to merge in some patches I've got lying around.

 

The Blkif API is very quirky. I think we should chuck it awa= y and put something sensible in place. Feel free to propose a new signature= ! :-)

 

Cheers,

Dave

 

On Mon= , Oct 21, 2013 at 8:57 PM, Christopher Greenhalgh <Chris.Greenhalgh@nottingh= am.ac.uk> wrote:

Partly as a lear= ning exercise I have made a blkif implementation over a single file using L= wt_unix - https://github.com/cgreenhalgh/mirage-unix-simple-blki= f
It has a couple of basic tests which it passes, but hasn't been ex= ercised beyond that yet;
Neither is it abstracted over threading, but th= en the Blkif interface isn't yet either...
i intend to try using it as a= baardskeerder store next, so we'll see what happens.

Threw up a few= questions...

As noted in the comment near the top of https://github.com/cgreenhalgh/mirage-unix-simple-bl= kif/blob/master/lib/blkdev.ml i don't think it will behave precisely th= e same as ocaml-xen-block-driver for concurrent multi-block reads and write= s: currently it will do each in one chunk while the xen driver subdivides a= nd potentially interleaves large reads and...

Btw there seems to be = an ambiguity in the OS.Devices.Blkif interface, specifically what should ha= ppen if write_page is called with an Io_page which is actually >1 page l= ong (e.g.from Io_page.get N)? ocaml-xen-block-driver write_page seems to as= sume that it will be exactly one page (without checking) but is the intende= d bevaviour (a) split pages and handle each page in turn or (b) explicit er= ror?

It is also slightly unclear (to me) what the ordering semantics= are intended to be for read_512; currently this and the xen-block-driver o= nly actually initiate the read when a thread attempts a (blocking) get on t= he returned Lwt_sequence. This is the more obvious route as read_512 is non= -blocking (i.e. has to immediately return the sequence), but feels slightly= odd.

p.s. as there is no sync operation, is there a particular leve= l of sync to disk/durability defined in the xen block protocol?

I'm = also unsure if it is deliberate that Io_page.page_size isn't visible; i had= to use Io_page.round_to_page_size 1 to get page_size out...

cheers<= br>chris


_________________________
From: Richard Mortier [Richard.Mortier@nottingham= .ac.uk]
Sent: 16 October 2013 21:16
To: David Scott
Cc: Christ= opher Greenhalgh; Mirage List
Subject: Re: mutable store on mirage?=

On 16 Oct 2013, at 21:08, David Scott wrote:

> I'd like to see u= nix blkif implemented (without using the xen implementation). I've got some= patches lying around which open files with O_DIRECT and perform unbuffered= sector-aligned I/O. I was thinking of making a 'unix-block-driver' with th= is code in it, mirroring the xen implementation. It's mostly a thin veneer = over Lwt_bytes, replacing Bigarray.t with Cstruct.t. In future I was thinki= ng the mirage-platform repo could become the minimal 'boot' code plus modul= e types for Blkif, Netif etc; and all the concrete implementations could be= spun out into other repos.
>
> What do people think?

ab= solutely agree. thought perhaps we would want to functorise(*) over Lwt, eg= packages named

mirage-blk-xen-lwt
mirage-blk-posix-async
mira= ge-blk-bsd-blah

etc...?  opam can handle the constraints though= (i firmly expect :)

(*) if i'm making up a verb there and/or using = it incorrectly, i apologise... :)


--
Cheers,

R.


This message and any attachment are intended solely for the addres= see and may contain confidential information. If you have received this mes= sage in error, please send it back to me, and immediately delete it.  = Please do not use, copy or disclose the information contained in this mess= age or in any attachment.  Any views or opinions expressed by the auth= or of this email do not necessarily reflect the views of the University of = Nottingham.

This message has been checked for viruses but the conten= ts of an attachment
may still contain software viruses which could damag= e your computer system, you are advised to perform your own checks. Email c= ommunications with the University of Nottingham may be monitored as permitt= ed by UK legislation.




<= p class=3DMsoNormal>

 

--
Dave Scott


=

This message and any attachment are intended solely for the addressee an= d may contain confidential information. If you have received this message in= error, please send it back to me, and immediately delete it.   Pl= ease do not use, copy or disclose the information contained in this message = or in any attachment.  Any views or opinions expressed by the author of= this email do not necessarily reflect the views of the University of Nottin= gham.

This message has been checked for viruses but the contents of an= attachment may still contain software viruses which could damage your compu= ter system, you are advised to perform your own checks. Email communications= with the University of Nottingham may be monitored as permitted by UK legis= lation.


= = --_000_4C20415C7327A849961F3B8421413725010CD7203AACEXCHANGE1ad_-- From Chris.Greenhalgh@nottingham.ac.uk Thu Oct 24 14:43:36 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VZLCK-0002fk-6e (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Thu, 24 Oct 2013 14:43:36 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1533363 * 0.0 HTML_MESSAGE BODY: HTML included in message X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from engine01-20433-7.icritical.com ([151.236.209.33]:52323) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp id 1VZLCI-00073e-iy (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Thu, 24 Oct 2013 14:43:35 +0100 Received: (qmail 2470 invoked from network); 24 Oct 2013 13:40:12 -0000 Received: from localhost (127.0.0.1) by engine01-20433-7.icritical.com with SMTP; 24 Oct 2013 13:40:12 -0000 Received: from engine01-20433-7.icritical.com ([127.0.0.1]) by localhost (engine01-20433-7.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 02060-10 for ; Thu, 24 Oct 2013 14:40:09 +0100 (BST) Received: (qmail 2217 invoked by uid 599); 24 Oct 2013 13:39:54 -0000 Received: from unknown (HELO smtp4.nottingham.ac.uk) (128.243.220.65) by engine01-20433-7.icritical.com (qpsmtpd/0.28) with ESMTP; Thu, 24 Oct 2013 14:39:54 +0100 Received: from uiwexhub01.ad.nottingham.ac.uk ([128.243.15.133]) by smtp4.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1VZL8y-00068P-Tc for cl-mirage@lists.cam.ac.uk; Thu, 24 Oct 2013 14:40:08 +0100 From: Christopher Greenhalgh To: Mirage List Date: Thu, 24 Oct 2013 14:40:09 +0100 Subject: setting up xen networking Thread-Topic: setting up xen networking Thread-Index: Ac7Qvo5xI2lvoG9TQF6zrmRQeNZUtg== Message-ID: <4C20415C7327A849961F3B8421413725010CD7203AC0@EXCHANGE1.ad.nottingham.ac.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_4C20415C7327A849961F3B8421413725010CD7203AC0EXCHANGE1ad_" MIME-Version: 1.0 X-Virus-Scanned: by iCritical at engine01-20433-7.icritical.com X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 13:43:36 -0000 Content-Length: 6411 Lines: 134 --_000_4C20415C7327A849961F3B8421413725010CD7203AC0EXCHANGE1ad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perhaps this is a daft question, but I've not used xen before today... how do I set up the networking for a mirage xen application with xen runnin= g on by desktop ubuntu machine? from http://www.openmirage.org/wiki/xen-boot I've built the mirage-www app = for xen, as per https://help.ubuntu.com/community/Xen I have set up xen on my ubuntu= desktop (but with xl toolchain) and rebooted into xen, created a xenbr0 in= terface with bridging I can run the vm with xl create, and I see the usual output include "Netif:= add resume hook" but nothing else to do with networking. I tried "xl network-attach www" (network-list was showing nothing before fo= r the new domain) and that made a vif but still get no console info about w= hether anything is happening on the mirage network side; does something lik= e this need to be in the www.xl file? My xenbr0 is quite possible on the "wrong" IP running it this way (10.0.2.1= 5) so I tried changing www.conf to dhcp but with no output I don't know if = ; no visible action. Fool-proof directions welcome :-) Cheers Chris This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in er= ror, please send it back to me, and immediately delete it. Please do not u= se, copy or disclose the information contained in this message or in any att= achment. Any views or opinions expressed by the author of this email do not= necessarily reflect the views of the University of Nottingham.=0D=0A =0D=0A This message has been checked for viruses but the contents of an attachment= =0D=0A may still contain software viruses which could damage your computer system,= you are advised to perform your own checks. Email communications with the U= niversity of Nottingham may be monitored as permitted by UK legislation.=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A --_000_4C20415C7327A849961F3B8421413725010CD7203AC0EXCHANGE1ad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Perhaps this is = a daft question, but I’ve not used xen before today…=

how do I set up the networking for a mirage xen ap= plication with xen running on by desktop ubuntu machine?

 

from http://www.openmirage.org/wiki/xen= -boot I’ve built the mirage-www app for xen,

as per ht= tps://help.ubuntu.com/community/Xen I have set up xen on my ubuntu desk= top (but with xl toolchain) and rebooted into xen, created a xenbr0 interfa= ce with bridging

I can run the vm with = xl create, and I see the usual output include “Netif: add resume hook= ” but nothing else to do with networking.

I tried “xl network-attach www” (network-list was showi= ng nothing before for the new domain) and that made a vif but still get no = console info about whether anything is happening on the mirage network side= ; does something like this need to be in the www.= xl file?

My xenbr0 is quite possibl= e on the “wrong” IP running it this way (10.0.2.15) so I tried = changing www.conf to dhcp but with no output I don’t know if ; no vis= ible action.

Fool-proof directions welco= me :-)

Cheers

Chris

 

 


=

This message and any attachment are intended solely for the addressee an= d may contain confidential information. If you have received this message in= error, please send it back to me, and immediately delete it.   Pl= ease do not use, copy or disclose the information contained in this message = or in any attachment.  Any views or opinions expressed by the author of= this email do not necessarily reflect the views of the University of Nottin= gham.

This message has been checked for viruses but the contents of an= attachment may still contain software viruses which could damage your compu= ter system, you are advised to perform your own checks. Email communications= with the University of Nottingham may be monitored as permitted by UK legis= lation.


= = --_000_4C20415C7327A849961F3B8421413725010CD7203AC0EXCHANGE1ad_-- From anil@recoil.org Thu Oct 24 15:07:38 2013 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VZLZa-0004DM-K8 (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Thu, 24 Oct 2013 15:07:38 +0100 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1533363 X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:36218 helo=dark.recoil.org) by ppsw-32.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with smtp id 1VZLZZ-00043p-2i (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Thu, 24 Oct 2013 15:07:38 +0100 Received: (qmail 31888 invoked by uid 634); 24 Oct 2013 14:07:37 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from ed03490-ge-0-0-0.mgdfwr.lumison.net (HELO [172.22.87.35]) (212.20.242.100) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Thu, 24 Oct 2013 15:07:36 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) Subject: Re: setting up xen networking From: Anil Madhavapeddy In-Reply-To: <4C20415C7327A849961F3B8421413725010CD7203AC0@EXCHANGE1.ad.nottingham.ac.uk> Date: Thu, 24 Oct 2013 15:07:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C20415C7327A849961F3B8421413725010CD7203AC0@EXCHANGE1.ad.nottingham.ac.uk> To: Christopher Greenhalgh X-Mailer: Apple Mail (2.1812) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 14:07:38 -0000 Content-Length: 3937 Lines: 90 Not a daft question -- the networking model changed a little between = toolstacks in Xen. I've had a few other people ask me this recently, so = I'll elaborate a little more than you need. The basic goal is to end up with a bridge that connects the external = world to the Xen VM VIFs. Every new Xen VM has a virtual interface that = is added to this bridge if it's specified in the config file = (vif=3D['bridge=3Dxenbr0']). It used to be the case that xend would, at startup, rebind your external = interface to a bridged one. This involved renaming the physical = interface name, which was somewhat error prone. The modern toolstack (xl) leaves the network bridge setup to the = sysadmin to take care of. This is a little more work upfront, but worth = doing. I use this in my /etc/network/interfaces: auto xenbr0 iface xenbr0 inet dhcp bridge_ports eth0 The next problem is ensuring that your VM has a vif attached. Here's = how mirage-www builds work: - you send a pull req to mirage/mirage-www - Travis picks up the commit and checks the build: = https://github.com/mirage/mirage-www/blob/master/.travis-ci.sh - I merge - When merged, the Travis script runs again, but also commits the = resulting Xen binary to another repository: = https://github.com/mirage/mirage-www-deployment - The deployment machine that runs Xen watches this repository and = restarts the running kernel if a new one appears. If anything goes = wrong, it can roll back to the previous Git repo. It uses this xl config file; https://github.com/mirage/mirage-www-deployment/blob/master/xl.conf.in Note that mirari doesnt (yet) have support for adding VIFs to the config = files, so I tend not to use that. But I really like the = Travis/Mirage-WWW workflow and intend to use that more. We basically = use version control to track all our dependencies, and existing hosted = services to take (most of) the pain out of coordination. -a On 24 Oct 2013, at 14:40, Christopher Greenhalgh = wrote: > Perhaps this is a daft question, but I=92ve not used xen before today=85= > how do I set up the networking for a mirage xen application with xen = running on by desktop ubuntu machine? > =20 > from http://www.openmirage.org/wiki/xen-boot I=92ve built the = mirage-www app for xen, > as per https://help.ubuntu.com/community/Xen I have set up xen on my = ubuntu desktop (but with xl toolchain) and rebooted into xen, created a = xenbr0 interface with bridging > I can run the vm with xl create, and I see the usual output include = =93Netif: add resume hook=94 but nothing else to do with networking. > I tried =93xl network-attach www=94 (network-list was showing nothing = before for the new domain) and that made a vif but still get no console = info about whether anything is happening on the mirage network side; = does something like this need to be in thewww.xl file? > My xenbr0 is quite possible on the =93wrong=94 IP running it this way = (10.0.2.15) so I tried changing www.conf to dhcp but with no output I = don=92t know if ; no visible action. > Fool-proof directions welcome :-) > Cheers > Chris > =20 > =20 >=20 > This message and any attachment are intended solely for the addressee = and may contain confidential information. If you have received this = message in error, please send it back to me, and immediately delete it. = Please do not use, copy or disclose the information contained in this = message or in any attachment. Any views or opinions expressed by the = author of this email do not necessarily reflect the views of the = University of Nottingham. >=20 > This message has been checked for viruses but the contents of an = attachment may still contain software viruses which could damage your = computer system, you are advised to perform your own checks. Email = communications with the University of Nottingham may be monitored as = permitted by UK legislation. >=20 From russell.pavlicek.xen@gmail.com Mon Oct 28 04:50:14 2013 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VaemM-0005BM-2Z (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 28 Oct 2013 04:50:14 +0000 X-Cam-SpamScore: s X-Cam-SpamDetails: score 1.9 from SpamAssassin-3.3.2-1536066 * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (russell.pavlicek.xen[at]gmail.com) * 2.5 SUSPICIOUS_RECIPS Similar addresses in recipient list * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.217.169 listed in list.dnswl.dnsbl.ja.net] * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-lb0-f169.google.com ([209.85.217.169]:32857) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.148]:25) with esmtp id 1VaemK-0007rC-G2 (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 28 Oct 2013 04:50:13 +0000 Received: by mail-lb0-f169.google.com with SMTP id o14so2420997lbi.14 for ; Sun, 27 Oct 2013 21:50:12 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.146.200 with SMTP id te8mr227486lbb.32.1382935812321; Sun, 27 Oct 2013 21:50:12 -0700 (PDT) Sender: russell.pavlicek.xen@gmail.com Received: by 10.112.252.129 with HTTP; Sun, 27 Oct 2013 21:50:12 -0700 (PDT) Date: Mon, 28 Oct 2013 00:50:12 -0400 X-Google-Sender-Auth: Jwqcm9IaRlFgmWO9hsPrVCa9sD8 Message-ID: Subject: REMINDER: Today is Xen Document Day From: Russ Pavlicek To: xen-devel@lists.xen.org, "xen-users@lists.xen.org" , xen-api@lists.xen.org, xs-devel@lists.xenserver.org, cl-mirage@lists.cam.ac.uk Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 04:50:14 -0000 Content-Length: 1446 Lines: 39 Today, October 28, is Xen Project Document Day! Xen Documentation Days are for people who care about Xen documentation and want to improve it. We introduced Documentation Days because working on documentation in parallel with like minded-people is just more fun than working alone. Also, this is the perfect way for people who are not contributing code to support the Xen Project. If you are a Xen user and had to dig to find useful information, consider improving the documentation so that the next person doesn't have to work so hard to figure out what you learned. For a list of items that need work, check out the community maintained TODO list at http://wiki.xen.org/wiki/Xen_Document_Days/TODO . Of course, you can work on anything you'd like; the TODO list provides a handy list of documents needing attention. Also, because of spam activities on the Wiki, you will need to request write access to the Wiki itself. Use the link atop the Xen Documentation Day page to request write access (see http://wiki.xenproject.org/wiki/Xen_Document_Days). If you request access this week, nothing will slow down your progress on Monday. How to join in: =========== - Join us on IRC: freenode channel #xendocs - Tell people what you intend to work on (to avoid doing something somebody else is already working on) - Fix some documentation - Help others - And above all: have fun! See you on #xendocs! Russ Pavlicek Xen Project Evangelist From scott.dj@gmail.com Tue Oct 29 11:20:34 2013 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1Vb7Le-0005hr-9i (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 29 Oct 2013 11:20:34 +0000 X-Cam-SpamScore: s X-Cam-SpamDetails: score 1.3 from SpamAssassin-3.3.2-1536284 * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [209.85.192.170 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (scott.dj[at]gmail.com) * 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is * CUSTOM_MED * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid * 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing * list X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-pd0-f170.google.com ([209.85.192.170]:54321) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.148]:25) with esmtp id 1Vb7Ld-0003q4-EU (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Tue, 29 Oct 2013 11:20:34 +0000 Received: by mail-pd0-f170.google.com with SMTP id v10so8481433pde.29 for ; Tue, 29 Oct 2013 04:20:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.131.70 with SMTP id ok6mr1003721pbb.126.1383045629280; Tue, 29 Oct 2013 04:20:29 -0700 (PDT) Received: by 10.70.56.36 with HTTP; Tue, 29 Oct 2013 04:20:29 -0700 (PDT) Date: Tue, 29 Oct 2013 11:20:29 +0000 Message-ID: Subject: Mirage weekly call From: David Scott To: Mirage List Content-Type: multipart/alternative; boundary=047d7b15ade971093e04e9df67f1 X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 11:20:34 -0000 Content-Length: 1613 Lines: 45 --047d7b15ade971093e04e9df67f1 Content-Type: text/plain; charset=ISO-8859-1 Fellow Mirage hackers, please join me on the Mirage weekly call today (tuesday) at 4pm BST! 1. Please join my meeting. https://www1.gotomeeting.com/join/591890401 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. United Kingdom (toll-free): 0 808 168 0209 United Kingdom: +44 (0) 207 151 1817 United States (toll-free): 1 877 309 2070 United States: +1 (626) 521-0017 Access Code: 591-890-401 Audio PIN: Shown after joining the meeting Meeting ID: 591-890-401 -- Dave Scott --047d7b15ade971093e04e9df67f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Fellow Mirage hackers, please join me on the Mirage w= eekly call today (tuesday) at 4pm BST!

1. =A0Pleas= e join my meeting.

2. =A0Use your microphone and speakers (VoIP) - a heads= et is recommended. =A0Or, call in using your telephone.

United Kingdom (toll-free): 0 808 168 0209 United Kingdom: +44 (0) 20= 7 151 1817

United States (toll-free): 1 877 309 2070 United States= : +1 (626) 521-0017

Access Code: 591-890-401
=
Audio PIN: Shown after joining the meeting

Meeting ID: 591-890-401

--
Dave Scott
--047d7b15ade971093e04e9df67f1-- From yallop@gmail.com Wed Oct 30 10:54:27 2013 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VbTPv-0004xx-4R (Exim 4.70) (return-path ); Wed, 30 Oct 2013 10:54:27 +0000 X-Cam-SpamDetails: score 0.6 from SpamAssassin-3.3.2-1536612 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [74.125.82.176 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (yallop[at]gmail.com) * 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is * CUSTOM_MED * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid * 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing * list X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mail-we0-f176.google.com ([74.125.82.176]:63395) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.148]:25) with esmtp id 1VbTPu-00067w-EN (Exim 4.80_167-5a66dd3) (return-path ); Wed, 30 Oct 2013 10:54:27 +0000 Received: by mail-we0-f176.google.com with SMTP id w62so1087925wes.21 for ; Wed, 30 Oct 2013 03:54:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.187.132 with SMTP id fs4mr1033900wjc.82.1383130466229; Wed, 30 Oct 2013 03:54:26 -0700 (PDT) Received: by 10.216.185.65 with HTTP; Wed, 30 Oct 2013 03:54:26 -0700 (PDT) Date: Wed, 30 Oct 2013 10:54:26 +0000 Message-ID: Subject: OCaml compiler hacking session From: Jeremy Yallop To: "cl-mirage@lists.cam.ac.uk List" , cl-cprg-announce@lists.cam.ac.uk Content-Type: text/plain; charset=UTF-8 X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 10:54:27 -0000 Content-Length: 1464 Lines: 38 It's time for the third Cambridge OCaml compiler-hacking session! This time we're going to be back in the Computer Lab, where the first session was held. If you're planning to come along, it'd be helpful if you could indicate interest via Doodle: http://doodle.com/czzp7ik4r72npz6p and sign up to the mailing list to receive updates: http://lists.ocaml.org/listinfo/cam-compiler-hacking Where: Room FW11, Computer Laboratory, Madingley Road Directions to the building: http://www.cl.cam.ac.uk/directions/ Room plan: http://www.cl.cam.ac.uk/research/dtg/openroommap/static/?s=FW11&labels=1 When: 6pm, Wednesday 6th November Who: anyone interested in improving OCaml. Knowledge of OCaml programming will obviously be helpful, but prior experience of working on OCaml internals isn't necessary. What: fixing bugs, implementing new features, learning about OCaml internals Wiki: https://github.com/ocamllabs/compiler-hacking/wiki We're defining "compiler" pretty broadly, to include anything that's part of the standard distribution, which means at least the standard library, runtime, tools (ocamldep, ocamllex, ocamlyacc, etc.), camlp4, ocamlbuild, the documentation, and the compiler itself. We'll have suggestions for mini-projects for various levels of experience, but feel free to come along and work on whatever you fancy. We'll also be ordering pizza, so if you want to be counted for food you should aim to arrive by 6.30pm. From anil@recoil.org Thu Oct 31 17:02:01 2013 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1VbvdB-0000EG-8f (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Thu, 31 Oct 2013 17:02:01 +0000 X-Cam-SpamDetails: score 0.0 from SpamAssassin-3.3.2-1537009 * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:30106 helo=dark.recoil.org) by ppsw-33.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp id 1Vbvd9-00063f-hM (Exim 4.80_167-5a66dd3) for cl-mirage@lists.cam.ac.uk (return-path ); Thu, 31 Oct 2013 17:02:00 +0000 Received: (qmail 13881 invoked by uid 634); 31 Oct 2013 17:01:58 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED,NORMAL_HTTP_TO_IP X-Spam-Check-By: dark.recoil.org Received: from host81-149-212-230.in-addr.btopenworld.com (HELO [10.0.1.9]) (81.149.212.230) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Thu, 31 Oct 2013 17:01:58 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) Subject: Re: RX error (microkernel in EC2) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 31 Oct 2013 17:01:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11A052D6-F076-4B60-9EA1-93A4E07C4732@recoil.org> To: William Le Ferrand X-Mailer: Apple Mail (2.1812) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: cl-mirage , David Scott X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 17:02:01 -0000 Content-Length: 4256 Lines: 153 I've been unable to replicate this -- I just built the latest releases = with mirage-www, and started a Xen instance here: http://ec2-54-205-12-128.compute-1.amazonaws.com It all boots and serves traffic fine in us-east-1. Anything special = about your setup that might cause the DHCP failure? -anil On 10 Oct 2013, at 22:17, William Le Ferrand wrote: > Hi Anil, did you had the chance to take a look at the DHCP problem? = thanks >=20 >=20 > On Thu, Sep 19, 2013 at 8:28 AM, William Le Ferrand = wrote: > ok great. fyi I'm doing consulting work for someone who is storing & = indexing > 8 Tb/day in AWS and looking to scale to 250 Tb/day. It's full = scala, but I'd love to benchmark a mirage-based solution on my spare = time and to push them in this direction if the figures make sense >=20 >=20 > On Thu, Sep 19, 2013 at 6:59 AM, Anil Madhavapeddy = wrote: > DHCP should work too (and has worked in the past, so this is no doubt = a minor issue, despite being difficult to debug). >=20 > -anil >=20 > On 19 Sep 2013, at 14:56, William Le Ferrand = wrote: >=20 >> I used the ec2.sh script, but I think that I was on the wrong track = anyway as local IP should be retrieved from the instance using "GET = http://169.254.169.254/latest/meta-data/local-ipv4" rather than DHCP, = shouldn't it? That's why I inquired about the status of client functions = in cohttp >>=20 >>=20 >> On Thu, Sep 19, 2013 at 3:57 AM, Anil Madhavapeddy = wrote: >> I'll take a look at this -- which script did you use to wrap up the = EC2 kernel for upload William? (just curious if you've been using the = AWS OCaml bindings for this, or doing it manually) >>=20 >> -anil >>=20 >> On 18 Sep 2013, at 23:57, William Le Ferrand = wrote: >>=20 >>> Yes, I tried that but the error only occurs in EC2; it's raised = somewhere in the DHCP module it seems .. >>>=20 >>>=20 >>> On Wed, Sep 18, 2013 at 2:12 PM, David Scott = wrote: >>> Hi, >>>=20 >>> I usually start by recompiling the app as a Unix process (using = "mirage-unix" rather than "mirage-xen"). Assuming the bug manifests = there (probably: I suspect the String.sub problem is coming from the = http-level rather than the xen driver-level) then you can use regular = debugging tools, set OCAMLRUNPARAM=3Db etc. >>>=20 >>> Debugging in-situ on EC2 is currently a matter of inserting printf's = and reading the code-- not ideal. >>>=20 >>> HTH >>> Dave >>>=20 >>>=20 >>> On Wed, Sep 18, 2013 at 9:45 PM, William Le Ferrand = wrote: >>> hello everyone >>>=20 >>> I'm running the simplest cohttp application possible in EC2, the = instance boots but quickly complains :=20 >>>=20 >>>=20 >>>=20 >>> MAC: 0e:32:89:f8:03:7b >>> sg:true gso_tcpv4:true rx_copy:true rx_flip:false smart_poll:false >>> Manager: plug 0 >>> Manager: plug done, to listener >>> Manager: Interface 0 to DHCP >>> DHCP: waiting for first offer >>> Manager: init done >>> DHCP: start discovery >>> Sending DHCP broadcast len 552 >>> DHCP: start discovery >>> Sending DHCP broadcast len 552 >>> DHCP: input ciaddr 0.0.0.0 yiaddr 172.31.23.46 siaddr 0.0.0.0 giaddr = 0.0.0.0 chaddr 2=EF=BF=BD=EF=BF=BD { sname file=20 >>> DHCP: offer received: 172.31.23.46 >>> Sending DHCP broadcast len 552 >>> RX exn Invalid_argument("String.sub") >>>=20 >>>=20 >>> Am I doing something wrong somewhere and what would be a good = strategy to debug this?=20 >>>=20 >>> Thanks >>>=20 >>> william=20 >>>=20 >>> --=20 >>> William Le Ferrand >>>=20 >>> Mobile : (+1) (415) 683-1484 >>> Web : http://williamleferrand.github.com/ >>>=20 >>>=20 >>>=20 >>> --=20 >>> Dave Scott >>>=20 >>>=20 >>>=20 >>> --=20 >>> William Le Ferrand >>>=20 >>> Mobile : (+1) (415) 683-1484 >>> Web : http://williamleferrand.github.com/ >>=20 >>=20 >>=20 >>=20 >> --=20 >> William Le Ferrand >>=20 >> Mobile : (+1) (415) 683-1484 >> Web : http://williamleferrand.github.com/ >=20 >=20 >=20 >=20 > --=20 > William Le Ferrand >=20 > Mobile : (+1) (415) 683-1484 > Web : http://williamleferrand.github.com/ >=20 >=20 >=20 > --=20 > William Le Ferrand >=20 > Mobile : (+1) (415) 683-1484 > Web : http://williamleferrand.github.com/