From jdd Sat May 27 14:35:43 2006 To: techx@arl Subject: techX: Source file copyright and header info All: I have added a link to this page http://www.arl.wustl.edu/projects/techX/design/design.html that gives the ARL Copyright notice and source file header information that we would like to maintain in all our source files. Here are some guidelines for using the copyright notice: 1. If we use an unmodified source file from Intel or Radisys our copyright notice should not be added. 2. If we use a source file from Intel or Radisys and modify it we should include our copyright notice and clearly mark where we made changes to the file. Any copyright or other notices that were present in the original file should be kept in the file. 3. Any file that we create from scratch should contain our copyright notice. We can talk about this more on Tuesday. John From jdd Sun May 28 15:07:55 2006 To: bw6@cs.wustl.edu Subject: Re: ME Location of Rx and Tx Cc: pcrowley@arl.wustl.edu Ben, That makes sense. Maybe what I am remembering is that it always seemed strange to me that Rx never seemed to be put in ME 0:0 in the sample apps. That seemed like a natural choice to me since it will not be using a NN ring for input. Thanks, John > > There is no limitation that I am aware of. At least with the 2400 and > 2350 systems I have worked on, I have had no problem migrating > functionality to different MEs. Perhaps if there are certain > configurations that use next neighbor rings or something, that might limit > you, but that is just speculation. > > --Ben > > On Sun, 28 May 2006, John DeHart wrote: > > > > > Ben and/or Patrick, > > > > I have a vague recollection that there was some > > strange rule about Rx or Tx blocks not being > > able to be in certain MicroEngines. Does that > > ring any bells for either of you? Its possible > > that I am completely off on this. It is a very > > vague recollection. > > > > Thanks, > > John > > > From jdd Thu Jun 1 23:24:22 2006 To: dzar@wustl.edu, jdd@arl.wustl.edu Subject: Re: Reminder: ARL Staff Mtg Status Cc: dzar@cse.wustl.edu, fredk@arl.wustl.edu, jp@arl.wustl.edu, jst@arl.wustl.edu, kenw@arl.wustl.edu, lockwood@arl.wustl.edu, pcrowley@cse.wustl.edu My status update: 1. techX: Demo plans: Nothing new. Since we have committed to doing a demo in November, we should start planning with that goal in mind. System Design: Intel's Architecture Tool: Nothing new IXA SDK 4.2: Still need to rebuild XScale stuff to try out 4.2. Spent quite a bit of time with Jing and Brandon redefining how the Parse, Lookup and Hdr Format blocks will fit together. We pushed all the IP header processing into the Parse block. The Hdr Format block will deal with the Ethernet and Substrate headers only. Spent quite a bit of time with Fred working out issues related to control and especially handling of "slow path" packets to be sent to the control processor. I need to make a major pass through the design slides to clean things up and make everything consistent. QM/Scheduler: I don't think we will be ready to review the QM/Scheduler design on Tuesday. I think Sailesh was still too busy with paper writing and paper reviewing to get much done on his part. Amy has made good progress but there is still a fair bit of work to do before we are ready to present it one last time before they start implementing it. Dispatch Loop and Stubs: I have started working on dispatch loop macros for use with our blocks that use Next Neighbor rings. Almost all of the examples in the sample apps are for scratch rings. Also they are almost all for one specific block, the all encompassing "pkt_process" block. Lookup Block: I have redefined some aspects of the Lookup block. It will do some limited processing of the lookup result and only pass on to Hdr Format what it needs. I have documented the "trick" that Jon suggested for encoding the Protocol field overlapped with another field in the lookup key. I think it makes sense to overlap it with the TCP_Flags instead of one of the Port fields. Sample App : Nothing new. 2. Cleanup: Nothing new here. I've been spending a little bit of time starting to get rid of some of the old equipment that has piled up in our storerooms. I also have feelers out to three companies to see if we can sell the old Fore ATM switch equipment. This continues and will continue for quite a while. We have a lot of old junk. 3. FPX Burning: Nothing new. I received the bitfile from Phillip. I have not tried it yet. 4. Eric and the Stats module: Nothing new. Eric has started testing his bitfile in hardware. He has some intermittent results but he thinks it works. He is not sure if the problems he has had were just pilot error or not. There hasn't been much time where he and I were both free and there was ONL time free for us to test. 5. ONL: Charlie and Jyoti now have access to an NSP with 7 GE Line Cards and some hosts connected to the GE switch in B402. TO DO List: 1. Working on re-doing my To Do list. Still needs some work. TO DO List: Priority | (Hi-Lo) | ( 1-10) | Tasks 1. techX Diversified Router System Try IXA SDK 4.2 to see if we can download a bitfile to Radisys boards. Continue working with Intel IXA SDK 4.2 Architecture Tool to refine system definition. Lookup Block Begin using SLAM for TCAM simulations. 2. ONL 2.1 Systems Software control of UPSs 2.2 GE switches: investigate chassis based switches. investigate configurations to support new NPU blades and hosts. 3. FPX/RAD Circuit Add control cells for Read Queue/VOQ Quanta and Thresholds (still on hold) 4. Cleanup 5. ARL Systems 6. Miscellaneous From jdd Thu Jun 1 23:34:28 2006 To: amf4@arl, dzar@cse, sailesh@arl Subject: Buffer Descriptor Cc: h Dave, Amy and Sailesh, We need to decide finally which fields we are using in the Buffer descriptor for Size and Next. It is either (Buffer_Size and Buffer_Next) or (Packet_Size and Packet_Next). Any preferences, ideas or suggestions on which ones to use? JOhn From jdd Fri Jun 2 23:38:50 2006 To: techX@arl Subject: techX: Slide updates All: I have updated my design slides for LC, Lookup, CRF and IPv4MR. The main areas of changes are: changes to Internal Frame format updates to definition of data between blocks cleaning out old out-of-date slides. I have also added a new set for the Packet Formats. As always, here is the link to the page with links to all the design slides: http://www.arl.wustl.edu/projects/techX/design/design.html John From jdd Sun Oct 22 17:00:00 2006 To: dwilkin738@charter.net Subject: Re: go cards Doug, Wow. Nothing worse, than inconclusive medical conclusions. You know we are all thinking good thoughts for you. Please let me know if you need anything. An extra night of darts practice wouldn't hurt me any or, an dinner/evening out with Langston and me will certainly take your mind off EVERYTHING else. We are here for you. John From jdd Sat Jan 13 11:47:06 2007 To: fredk@arl.wustl.edu, jdd@arl.wustl.edu, jst@arl.wustl.edu Subject: Re: metanet abstractions Cc: jl1@arl.wustl.edu > I am trying to write the IPv4 control code so that it is general enough to > provide a framework for the I3 side and metanets in general. So to make that > happen I need to better understand the target abstractions in the current > iteration of the design. > > The ultimate questions: did we decide to use a unique local UDP port number > for each meta-net interface? > > -- Reason for question: > > More to the point, the internal meta-net header sent to the GPEs (control > software/slow path). The format as articulated in > New_Planetlab_IPv4_MR_HF_Block_Design_Review.ppt > > # I think the type field should really be the following, right? > # | Magic (4-bit) | Type (28-bits) | Yes it is like this in her most recent slides. The "Magic" 4 bits are all 0. > > Generic meta-net internal header > | Type (32-bit) | > | len (16-bit) | Rx UDP Port (16-bit) | > | Type Dependent Data | > > The type dependent data will include the fwdkey (result of the lookup) when > available > fwdkey: > | TX UDP DPort (16-bit) | TX UDP SPort (16-bit) | > | TX IP Dst Addr (32-bit) | > > Now, as the substrate does not currently support the notion of a > meta-interface the meta-net control software needs to implement this > abstraction. If the metarouter uses one local UDP port number for each meta > interface then the above header works just fine. But given that all > meta-routers will compete for the same port space this may not be realistic. I thought the Rx UDP Port was the incoming Meta Interface and the TX UDP Sport was the outgoing Meta Interface. But I realize that in the last couple of days the question was raised again about whether we NEEDED multiple Tx UDP Sports with planetlab and that changing to using multiple would cause code changes that there was reluctance to do on our current short schedule. My recollection was that we were all going to bow down to use what ever PlanetLab and its control needed even if we were not completely happy with it. John > > An alternative is to export a single local UDP port number of a meta-router. > Then assuming tunnels between routing peers, a meta-interface is uniquely > defined by the IP address and UDP port number of the peer. But then the above > internal meta-net header is not sufficient to identify the receiving > meta-interface: I will also need the tunnel's source IP address. > > Maybe this has already been decided, if so please let me know. > > As a side issue, when configuration tables are filled in to define metanet > instances substrate software needs to fill in default meta-port numbers etc. > For example, the control (local delivery) default port number and qid must be > added to a substrate table (to be used for the QM). Likewise the meta-net > when its gives a packet to the QM it specifies a port number which I assume is > the meta-port number (an integer starting at 1), right? If so then there will > need to be some cooperation between the substrate and metanet on port number > assignments. Or maybe I misunderstood what Jing was saying yesterday. > From jdd Mon Feb 19 23:24:19 2007 To: brandon.heller@gmail.com, jdd@arl.wustl.edu Subject: Re: techx: Tuesday mtg Brandon, I've been doing some work tonight on expanding Jon's slides. Perhaps I'll start off on Tuesday and we'll see where we go from there. My current slides are on the design web page: http://www.arl.wustl.edu/projects/techX/design/design.html list as: ONL NP Router. John > I've been focusing on the packet generator rather than combined blocks, > because the block design really depends on the way copies are made. The > main issue is that for 10 copies, even if each one takes a little bit of > time, the ordered thread execution model causes the copying thread to exceed > its latency budget, and all other threads to stall. Ordered threads make > sense where the processing time variation is low between packets, and > exceptions are rare. If we expect to create more copies than packets we > receive, it may make sense to move to an unordered model with a reorder > buffer, or move the copy operation off the fast path, or limit the number of > copies and add MEs, or just accept the issue for small packet sizes. > > Another issue is fairness; if we have lots of copies being made, and not > enough output bandwidth, where do we start to drop packets? Should > copied/plugin packets be strictly lower-priority than pass-through ones? > > As for combining parse + lookup, we only need to redo the lookup block in C, > and modify it to use all 32 mailboxes, by forming the TCAM mailbox from both > the thread context and the ME. The ordered thread dispatch loops scale > nicely across microengines, with no code changes required. > > Do you have any new slides? > > -Brandon > > > On 2/19/07, John DeHart wrote: > > > > > > All: > > > > We will meet on Tuesday, 9:30 B509C. > > Brandon will tell us about combining blocks like Parse, Lookup, etc. > > We may also venture into more details of the design of the ONL Router. > > > > John > > > > ------=_Part_40349_18977391.1171926581979 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > I've been focusing on the packet generator rather than combined blocks, because the block design really depends on the way copies are made.  The main issue is that for 10 copies, even if each one takes a little bit of time, the ordered thread execution model causes the copying thread to exceed its latency budget, and all other threads to stall.  Ordered threads make sense where the processing time variation is low between packets, and exceptions are rare.  If we expect to create more copies than packets we receive, it may make sense to move to an unordered model with a reorder buffer, or move the copy operation off the fast path, or limit the number of copies and add MEs, or just accept the issue for small packet sizes.  >

Another issue is fairness; if we have lots of copies being made, and not enough output bandwidth, where do we start to drop packets?  Should copied/plugin packets be strictly lower-priority than pass-through ones? >

As for combining parse + lookup, we only need to redo the lookup block in C, and modify it to use all 32 mailboxes, by forming the TCAM mailbox from both the thread context and the ME.  The ordered thread dispatch loops scale nicely across microengines, with no code changes required. >

Do you have any new slides?

-Brandon


On 2/19/07, John DeHart <jdd@arl.wustl.edu> wrote: >

All:

We will meet on Tuesday, 9:30 B509C.
Brandon will tell us about combining blocks like Parse, Lookup, etc. >
We may also venture into more details of the design of the ONL Router.

John

> > ------=_Part_40349_18977391.1171926581979-- > From jdd Tue May 20 21:11:44 2008 To: fredk@arl, jst@arl, kenw@arl, wiseman@wustl.edu Subject: Wednesday AM I have a dentist appt in the morning. I should be in by late morning. john