AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Maxim.Kozlovsky@lsi.com>,<Brian.Stark@lsi.com>,<Andy.Sharp@lsi.com>,<Bill.Fisher@lsi.com>,<Jobi.Ariyamannil@lsi.com>,<Rendell.Fong@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	861DA0537719934884B3D30A2666FECC94302CF7@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 23 Sep 2009 09:29:33 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Kozlovsky, Maxim" <Maxim.Kozlovsky@lsi.com>
Cc: "Stark, Brian" <Brian.Stark@lsi.com>, "Sharp, Andy"
 <Andy.Sharp@lsi.com>, "Fisher, Bill" <Bill.Fisher@lsi.com>, "Ariyamannil,
 Jobi" <Jobi.Ariyamannil@lsi.com>, "Fong, Rendell" <Rendell.Fong@lsi.com>
Subject: Re: TuxStor schedule v1
Message-ID: <20090923092933.7c0c33bb@ripper.onstor.net>
In-Reply-To: <861DA0537719934884B3D30A2666FECC94302CF7@cosmail02.lsi.com>
References: <E1EC65251D4B3D46BBC0AAA3C0629222A90B8239@cosmail02.lsi.com>
	<861DA0537719934884B3D30A2666FECC94302CF7@cosmail02.lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 22 Sep 2009 17:39:10 -0600 "Kozlovsky, Maxim"
<Maxim.Kozlovsky@lsi.com> wrote:

> By the way, it looks like the code in the tuxrx branch does not build
> at all, neither the kernel nor the user space. I hope somebody is
> spending their quality development time on fixing that?

Your quality time is just as quality as anyone elses, right?

Last I tried, the kernel built for me.  We aren't trying to build the
user space at this time, at least not from the main build
infrastructure.  But feel free to pitch in wherever the mood moves you.

> ________________________________
> From: Kozlovsky, Maxim
> Sent: Tuesday, September 22, 2009 4:23 PM
> To: Stark, Brian; Sharp, Andy; Fisher, Bill; Ariyamannil, Jobi; Fong,
> Rendell Subject: RE: TuxStor schedule v1
> 
> Hello,
> 
> What exactly do you mean by nfsperftest without networking? To my
> limited knowledge no such thing exists, or you might mean something
> else under that name.
> 
> The virtual servers being long pole can be mitigated by structuring
> the development so the initial deliverable is being able to bring a
> single virtual server with a single interface without aggregation or
> vlan or jumbo frames support up and down, without actual support for
> multiple virtual networking stacks, without any extras like protocol
> statistics, don't even need interface delete or modify to work. This
> will allow testing the NFS CIFS NDMP DMIP code without waiting for
> the completion of the rest of the virtual server work. The
> performance testing will need full support for multiple interfaces
> and aggregation.
> 
> Here are my changes so far, I may have more later:
> 
> 23: need to have two separate items for TXRX and FP TPL code
> 
> Change 31: FS code compile/link - 1 week
> 
> Change 34, 35 (local and dmip mirroring) compile link - collapse into
> single item, set duration to 1 week.
> 
> Change 32 (NDMP) compile link - set duration to 1week
> 
> Add: SCSI/ISPFC compile/link - 1 week
> 
> (Hopefully this will go faster but I am rounding up).
> 
> Under FS threads:
> 
> 29, 30 (implement and test) - remove
> 
> FS and ACPU polling threads and wakeup mechanism - 1 week
> 
> Interrupt handler for qlogic - 2 days (?)
> 
> State machines and FS threads - 1 week
> 
> Non-failing/Non-blocking memory manager - 1 week
> 
> Debugger and core dump support for FS threads - 1 week
> 
> Watchdog support for FS and ACPU threads - 3 days (?)
> 
> 42 - RMC test automation - remove
> 
> Max
> 
> 
> ________________________________
> From: Stark, Brian
> Sent: Tuesday, September 22, 2009 3:42 PM
> To: Sharp, Andy; Kozlovsky, Maxim; Fisher, Bill; Ariyamannil, Jobi;
> Fong, Rendell Subject: TuxStor schedule v1
> 
> I've updated the TuxStor schedule based on the feedback from
> yesterday's meeting.  I've attached the Project file and a pdf and
> would like to get feedback on this by the end of the week.  The key
> dates are getting to task 36 Dev Unit tests, which then drives task
> 39 Phase 1 Integration.  After this, we are then ready for QA.
> 
> By building in holiday times and also making nfsperftest a
> pre-requisite for entering QA for Phase 1, the date is pushed out to
> the middle of June.  This is a little too close for comfort, and I'd
> like to see if we can pull it back in to May.  The long pole appears
> to be the virtual server work, so maybe nfsperftest without
> networking can start before virtual server work is completed.  This
> is just a suggestion, and keep in mind that my primary goal here is
> to create an accurate schedule that we can deliver on.
> 
> Take a look at tasks and durations in particular.  As a reminder I'd
> like to get tasks down to 1-2 week intervals, so add more detail to
> tasks that are currently longer.
> 
> After I receive feedback, I'll work up another version and then we
> can meet early next week.
> 
> 
> Thanks,
> Brian
> 
> 
> 
